Hacker News Examines a Context-Aware Permission Guard for Claude Code

What the project is trying to fix

The Show HN thread centers on nah, a security layer for Claude Code built as a PreToolUse hook. The README starts from a simple complaint: allow-or-deny permissions do not scale when the same tool can be harmless in one context and destructive in another. The project therefore classifies tool calls by what they are actually doing. It checks Bash structure, sensitive reads such as ~/.ssh or .env, write and edit targets, suspicious content, sensitive directory scans through Glob or Grep, and generic third-party MCP tool calls.

The most important design choice is that a deterministic classifier runs first. According to the README, blocked actions are marked as nah., confirmation-required actions are marked as nah?, and only ambiguous leftovers can be escalated to an optional LLM. The examples make the intent easy to understand: git push may be acceptable, while git push --force deserves another look; deleting build artifacts inside a project may be fine, while reading cloud credentials is not. The project also warns users not to rely on --dangerously-skip-permissions, because asynchronous hooks can allow commands to run before the guard has a chance to block them.

What Hacker News focused on

HN commenters treated nah as useful, but not complete. Several replies argued that policy logic at the tool layer still needs a real sandbox underneath it, whether that means Docker, virtual machines, or another isolation boundary. Others pushed on multi-step exfiltration and indirect damage: a chain of individually harmless commands can still leak secrets, and an agent can always write malicious code into a normal project file and trigger it later through tests or build steps. There was also discussion about whether the policy surface will eventually need a dedicated DSL rather than growing through hardcoded assumptions.

That skepticism is not a dismissal. If anything, it shows why the project attracted attention. Developers are moving from toy agents to agents with filesystem, network, and MCP access, and simple permission prompts clearly do not express enough intent. nah is interesting because it tries to convert permissioning from a yes-or-no switch into a context classifier with logs, inspectable decisions, and a smaller review surface.

Why this matters now

The thread makes the state of agent safety tooling easy to read. Deterministic policy engines are becoming necessary, but they are not replacing sandboxing. They are becoming the middle layer between user intent and raw tool execution. nah is an example of that shift: practical, local, opinionated, and very aware that agent security is a systems problem rather than a single rule set.

Source post: Hacker News discussion. Primary source: nah README.