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

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 allowed on the vast majority of developer machines without further confirmation. You need to review every line of code changed before the agent is allowed to execute it for this to work and that's clearly not how most people work with agents.

I can see value in projects like this to protect against accidental oopsies and making a mess by accident, but I think that marketing tools like this as security tools is irresponsible - you need real isolation using containers or VMs.

Here's one more example showing you why blacklisting doesn't work, it doesn't matter how fancy you try to make it because you're fighting a battle that you can't win - there are effectively an infinite number of programs, flags, environment variables and config files that can be combined in a way to execute arbitrary commands:

    bash> nah test "PAGER='/bin/sh -c \"touch ~/OOPS\"' git help config"

    Command:  PAGER='/bin/sh -c "touch ~/OOPS"' git help config
    Stages:
      [1] git help config → git_safe → allow → allow (git_safe → allow)
    Decision:    ALLOW
    Reason:      git_safe → allow

Alternatively:

    bash> nah test "git difftool -y -x 'touch ~/OOPS2' --no-index /etc/hostname /etc/hosts"
    Command:  git difftool -y -x 'touch ~/OOPS2' --no-index /etc/hostname /etc/hosts
    Stages:
      [1] git difftool -y -x touch ~/OOPS2 --no-index /etc/hostname /etc/hosts → git_safe → allow → allow (git_safe → allow)
    Decision:    ALLOW
    Reason:      git_safe → allow

Good catch, that's a legit bypass

nah strips env var prefixes before classifying the command but doesn't inspect their values for embedded shell execution, I'll fix it: https://github.com/manuelschipper/nah/issues/6

On the broader write-then-execute point - two improvements are coming:

- Script execution inspection: when nah sees python script.py, read the file and run content inspection and LLM analysis before execution

- LLM inspection for Write/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% - to your point a sandbox is the answer to that.

I don't think "security tool" and "not a sandbox" are contradictory though. Firewalls don't replace OS permissions, OS permissions don't replace encryption

nah is just another layer that catches the 95% that's structurally classifiable. It's a different threat model. If 200 IQ Opus is rogue deterministic tools or even adversarial one shot LLMs won't be able to do much to stop it...

nah addresses "should this action be allowed?" — deterministic classification of tool calls against policies. Smart design, and the no-dependency stdlib approach is the right call for security tooling.

The complementary question most agent safety tools ignore: what happens when things go wrong despite permissions?

I run 8 AI agents managing my company (marketing, accounting, legal, ops). We have a similar permission model — Marketing can't publish claims without Lawyer review, financial changes need CFO sign-off, hard boundaries on auth/compliance. But permissions alone didn't save us when two agents fired parallel writes to the same knowledge graph. Both writes were individually permitted. The second silently overwrote the first. No error, no policy violation — data just disappeared.

What saved us: Erlang-style supervision trees. Memory server detected corruption on load, crashed intentionally, supervisor restarted it in microseconds, auto-repair ran on init. No human at 3am.

Permission guards prevent known-bad actions. Supervision makes unknown-bad outcomes survivable. Most agent safety work focuses exclusively on the first problem.

Wrote up the full race condition mechanics and supervision strategies: https://dev.to/setas/why-erlangs-supervision-trees-are-the-m...

The context-aware classification is neat, especially the pipe composition stuff. One thing I keep thinking about though — the scariest exfiltration pattern isn't a single bad command, it's a chain of totally normal ones. Agent reads .env (filesystem_read → allow), writes a script that happens to include those values (project write → allow), then runs it (package_run → allow). Every step looks fine individually. Credentials gone. This is basically the same problem as cross-module vulns in web apps — each component is secure on its own, the exploit lives in the data flow between them. Would be interesting to see some kind of session-level tracking that flags when sensitive reads flow into writes and then executions within the same session. Doesn't need to be heavy — just correlating what was read with what gets written/executed.

I used nvm a long time and was very happy to get rid of it and use `devbox` and similar tools instead.

The rule on my machine now is that everything has to be in a per-project sandbox, self-contained to ~/.local/bin or installed by the system package manager.

The question was about global tools, something nvm purposefully does not handle.

The `uv tool` answer by a sibling comment was great; it'd be nice to have something similar for npm.