[–] bulder 7 hours ago
[–] smallnamespace 6 hours ago
That is not the niche case, that's the dominant use of models.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
[–] RHSeeger 6 hours ago
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
[–] zahlman 1 hour ago
And if everyone else jumped off a bridge, I mean, used raw interpolation for SQL queries, would you do it too?
[–] wongarsu 5 hours ago
However I do share your desire for a better manual mode. Auto-mode is both sometimes surprisingly lax, and sometimes too restrictive. Maybe manual mode should inject a reminder "keep your commands as simple one-liners", the same way plan mode injects a reminder that you are in plan mode and don't want any code changes
[–] ceejayoz 8 hours ago
[–] gsnedders 8 hours ago
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.
[–] bcherny 8 hours ago
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.
[–] joombaga 5 hours ago
[–] adastra22 2 hours ago
[–] aftbit 7 hours ago
[–] bcherny 6 hours ago
[–] Kim_Bruning 5 hours ago
With SOTA agents that’s a real bind, because they’re very likely to find those gaps. Whether they exploit them, close them, or leave them alone then becomes a prompting challenge yet again.
I don't think this means don't sandbox at all. You can prevent a lot of small and medium accidents by locking down or gating access to hidden files, ssh, sudo, etc.
But your sandbox can never be the whole story.
[–] kragen 7 hours ago
Speaking of really significant things being at risk, it's pretty infuriating that the web-chat Incognito mode can't write and test code locally, and neither the non-Incognito web-chat nor the local Claude Code client can be shielded from the knowledge of my email address and my geolocation. (Even the Incognito mode knows my geolocation.) This gives users no alternative but to put privacy-sensitive information at the disposal of Claude Code, which is far too unreliable to be entrusted with it. It's tempting to attribute this to Anthropic's corporate DNA valuing users' interests at a very low level, but conceivably it's just an oversight, and if I mention it here, it will be corrected in a month or two?
Currently, my assessment is that Claude Code, and in particular the Opus 5.5 model, is head and shoulders above the competition in software development capabilities. Nothing else is even close. But I've seen several small signs like this which suggest that Anthropic, as a company, is maliciously misaligned. So, if Grok, Qwen, GLM, or Astra starts to come anywhere close to being competitive, I'll switch as soon as I can. I imagine that most of your users feel the same way.
[–] wonnage 6 hours ago
[–] kragen 6 hours ago
[–] ceejayoz 6 hours ago
[–] DANmode 1 hour ago
Maybe pick a better comparison if so?
[–] 1659447091 4 hours ago
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
[–] rbehrends 6 hours ago
sed -n 1,30p src/vm/wren_vm.c && sed -n 310,350p src/vm/wren_vm.c && sed -n 560,600p src/vm/wren_vm.c && sed -n 740,775p src/vm/wren_vm.c && sed -n 40,70p src/vm/wren_common.h && cat util/wren_to_c_string.py | head -80 && ls test/random doc/site doc/site/modules doc/site/modules/random 2>/dev/null; cat projects/premake/premake5.lua | head -80; cat util/generate_projects.py
After ten or more of these, you're going to get hit by permission fatigue, and then, yes, manual review becomes too error-prone to use safely.
The irony is that Claude is regularly ignoring its existing Read/Write/Edit tools that could make everything more readable.
Other models/harnesses have their own problems, but Claude Code is one of the worst for manual approval.
You can get manual approval to work reasonably well if you give the model a reasonable set of tools (I have literally written my own MCP servers to cover gaps in existing harnesses) where you can then write rules for the vast majority of safe cases.
For example, I have a stdio MCP server that allows models to inspect crates under ~/.cargo/registry/src (paired with the existing query-crates MCP server). It provides read-only operations limited to crate data, so I can pretty safely auto-approve everything in there. With the right setup, including a sandbox, you only ever have to manually approve something once in a while and usually with delimited scope, avoiding permission fatigue.
[–] fwip 58 minutes ago
1) edit a file with sed, 2) try to write it with its regular tool 3) get blocked because sed changed the file 4) read the file with tool 5) edit with sed again.
Would be nice if it felt like real people were developing Claude Code, instead of chasing after another half-baked idea Claude came up with.
[–] greatgib 5 hours ago
- Yes, but only one time, you will have to manually approve next time
- Enable auto mode and stop worrying
- No
Nothing to save this command or part of it to the manual approve list. So will be requested again 100x times.
Many of the problems when it comes to the manual approval feel like they stem from the expectation of using auto mode in the first place. After all, what's the point of improving the manual approval and safety matching if auto mode is the end all be all, and what's the point of training the model to output commands in a manner that can be parsed by a human if auto mode is always meant to be used? It's very rare for me to not see "command could not be statically analyzed", because the model keeps outputting bash golf.