alt Hacker NewsIndeed. The article only compares the status quo manual system versus the auto system — and doesn’t consider ways that the manual could be improved.
As it says:
> 5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice
Claude Code never should have prompted to always allow Bash(python:*) or Bash(node:*) — that’s clearly a bad idea, and Anthropic know that (given the references in the article!).
Of course, Bash(python a.py) still isn’t safe if you also allow Write(a.py), because you may as well allow Bash(python:*) at that point, and that’s often practically what people want (“I want to both make edits to the source and then run the test suite”). So maybe the whole permission system is broken to start with — and the actual answer is leaning more heavily on fine-grained sandboxing.
You also, as the article rightfully points out, run into permission fatigue and users blindly hitting allow.
I do still wish you could do more with hooks — outside of auto, I might want to allow a given command via a hook if Claude Code has read access to given file, but there’s no way to query if a given path allows/denies read/write.
Replies
> I do still wish you could do more with hooks I might want to allow a given command via a hook [...] given path allows/denies read/write
You can make a script for the PreToolUse hook that can do that. I use a command gate script that parses input for doing that exactly, allowing/denying actions based on tool use + paths -- it started out as a hook to prevent claude from polluting my clojure projects/filesystem with python in sneaky ways. Babashka works really well here
Will look into exposing that in hooks.
Ultimately, the threat model here is: human has to approve a lot of commands, so gets tired and accidentally approves a command they shouldn’t have. We spent a significant amount of effort to build a richer permission system, allow configuration at multiple levels, use static analysis to detect dangerous and safe commands, monitor the model to detect and block prompt injection at the inference layer, etc. Some of these components we rewrote and red teamed dozens of times. Our conclusion was that despite all of this work, in practice the threat model is that human attention is limited and that that a different approach performs an order of magnitude better in practice.