Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A context-aware permission guard for Claude Code

github.com

Post reply on HN
Print view View original

101–109 of 109 posts

Re: Show HN: A context-aware permission guard for Claude Code

#101

Post by schipperai »

niobe wrote: post #97
binwiederhier wrote: post #22

I love how everyone is trying to solve the same problems, and how different the solutions are. I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me…

But is anthropic trying to solve it? The current permissions solution is unbelievably poor for a product with this much traction.

They are releasing auto-mode soon. But that won't improve the underlying permission system, rather, it'll just delegate decisions to Claude. That's better than --dangerously-skip-permissions, but not great for those that want granular controls and are sensitive to the extra tokens spent.

Re: Show HN: A context-aware permission guard for Claude Code

#102

Post by schipperai »

kate23_human wrote: post #100
binwiederhier wrote: post #22

I love how everyone is trying to solve the same problems, and how different the solutions are. I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me…

Docker isolation is a good baseline, but the tricky part is usually the boundary between “safe filesystem access” and tools that can indirectly access secrets (git configs, environment variables, credential helpers, etc). Even read-only access to a repo can leak quite a bit depending on what’s in the workspace. I’ve seen some teams run tools inside containers but mount a filtered workspace rather than the full projec…

great callout - tool call can have side-effects outside your box. So unless you run a sandbox with no internet access, you aren't ever 100% safe.

nah does guard some of this - reading .env or ~/.aws/credentials gets flagged, and Write/Edit content is inspected for secrets before it leaves the tool.

Docker + filtered mounts + something like nah on top is a solid layered approach that is still practical.

Re: Show HN: A context-aware permission guard for Claude Code

#103

Post by schipperai »

netcoyote wrote: post #87
dns_snek wrote: post #72

This is not criticism of your project specifically, but a question for all tools in this space: What's stopping your agent from overwriting an arbitrary source file (e.g. index.js) with arbitrary code and running it? A rogue agent doesn't need to run `rm -rf /`, it just needs to include a sneaky `runInShell('rm -rf /')` in ANY of your source code files and get it to run using `npm test`. Both of those actions will be…

> What's stopping your agent from overwriting an arbitrary source file (e.g. index.js) with arbitrary code and running it? You're absolutely right :) And even if it could be sandboxed at the source code level, what's to prevent a nefarious AI from writing an executable file directly as bytes that calls (e.g.) `unlink`?

nah inspects Write and Edit content before it hits disk so destructive patterns like os.unlink, rm -rf, shell injection get flagged. And executing the result (./evil) classifies as unknown resolves to ask, which the LLM can choose to blocks or ask you to approve.

But yeah, a truly adversarial agent needs a sandbox. It's a different threat model - nah is meant to catch the trusted but mistake-prone coding CLI, not a hostile agent.

Re: Show HN: A context-aware permission guard for Claude Code

#105

Post by Setas »

Permission guards solve one important problem: should this action be allowed?

The complementary problem is recovery. I run 8 agents with fairly hard boundaries between them, and I still hit failures where every individual action was allowed but the system broke anyway because two agents wrote shared state at the same time.

What saved that setup was supervision, not permissions. The memory server crashed, restarted cleanly, ran repair on boot, and the rest of the system kept moving. Permission checks stop known-bad actions; supervision is what makes unknown-bad outcomes survivable.

Re: Show HN: A context-aware permission guard for Claude Code

#106

Post by nicwolff »

binwiederhier wrote: post #22

I love how everyone is trying to solve the same problems, and how different the solutions are. I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me…

Yeah, same – mine gives Claude a proxy to the host's Docker socket that disallows mounting anything outside the dev dirs or starting a --privileged container, so it can run tests.

https://github.com/nicwolff/claude-container/

Re: Show HN: A context-aware permission guard for Claude Code

#108

Post by brian_r_hall »

The deny list problem is real but I think the harder issue is that context matters so much. Deleting a temp file and deleting a config file look the same to a classifier.

We've been approaching it from the policy side, define what the agent is allowed to do upfront and evaluate each action before it runs. Human approval for anything that falls outside the policy. Different tradeoffs but same underlying frustration.

Re: Show HN: A context-aware permission guard for Claude Code

#109

Post by riteshkew1001 »

dns_snek wrote: post #72

This is not criticism of your project specifically, but a question for all tools in this space: What's stopping your agent from overwriting an arbitrary source file (e.g. index.js) with arbitrary code and running it? A rogue agent doesn't need to run `rm -rf /`, it just needs to include a sneaky `runInShell('rm -rf /')` in ANY of your source code files and get it to run using `npm test`. Both of those actions will be…

[flagged]
Post reply on HN