Is that because auto mode is good, or because the manual approval system sucks?

Indeed. 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.

▲

bcherny a day ago | parent | next [-]

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.

▲

joombaga a day ago | parent | next [-]

Did you ever test putting the auto mode classifier in front of manual approval? This is how I use it, but last I checked that option is not available out of the box.

	▲	adastra22 a day ago \| parent [-]
		That’s how auto works right now. It gives you a prompt.

▲

aftbit a day ago | parent | prev | next [-]

The problem is that you didn't even attempt to build a proper box (a sandbox that prevents the AI from running bad stuff by design). It's an extraordinarily hard problem. Only OpenAI Codex is actually trying to do it, and they suck at it too. They keep breaking permissions, their own AI can't troubleshoot it, their defaults give read to the whole filesystem (go ahead, slurp my ssh keys), and their "manual approval" escape does not seem to work.

▲

bcherny a day ago | parent | next [-]

I agree actually. We built an open source agent-agnostic sandbox that we are landing improvements to, much more to come: https://github.com/anthropics/sandbox-runtime. That said the sandbox is not perfect, and any sandbox needs holes punched otherwise it is not useful in practice (at least for inference and MCPs, and almost certainly more). We will be doing much more in this area.

	▲	coldtea 13 hours ago \| parent \| next [-]
		>and any sandbox needs holes punched otherwise it is not useful in practice Don't assume our individual use cases. It can be perfectly useful with access to just one folder and zero network asside from the API.
	▲	grey-area a day ago \| parent \| prev [-]
		That’s good to hear, it’s a much better approach than expecting humans to read commands and approve them or just trust that the LLM can set the proper horizons for its world itself while working.

▲

Kim_Bruning a day ago | parent | prev [-]

Making a sandbox both fully secure and fully useful are contradictory requirements. If you want the agent to do any real work, you have to leave gaps.

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.

▲

coldtea 13 hours ago | parent [-]

>Making a sandbox both fully secure and fully useful are contradictory requirements.

Any tradeoff deals with "contradictory statements". Doesn't mean we should always side with one side on a tradeoff.

Nobody said anything about "fully secure" and some arbitrarily "fully useful" combined, anyway.

For certain people it could be 100% fully useful with just access to a few fixed folders and a few fixed APIs.

Many of us don't want it to drive our lives, just do some specific this or that.

▲

Kim_Bruning 11 hours ago | parent [-]

Right! That was the standard view until fairly recently. But I'm pointing out something else.

This year we've learned that If a SOTA LLM decides that the sandbox is standing between it and its current objective: well, it has the ability, the time, and literally nothing better to do all day. Odds are, if you've configured the sandbox for anything useful, you've also provided a crack it can use to get out.

Again, doesn't make a sandbox entirely useless. Does mean you can't just put it in a really tight box and call the job done. If anything, the strict sandbox might even hurt, because it's more likely to get in the way.

(By analogy: consider the safety issues posed by a dam without a spillway.)

	▲	aftbit 8 hours ago \| parent [-]
		This is much more of a problem if you're attempting to run at a massive scale, beyond what humans can audit. When I'm doing "artisanal" agentic programming, I'm still in the loop in the sense that I'm watching what it's doing and ready to hit Esc if it is doing something dumb. If the AI trips over the sandbox, I can cancel it and do whatever it wants me to do before it starts trying to engineer its way around.

▲

kragen a day ago | parent | prev [-]

Maybe you can include some percentage of intentionally malicious commands, but not actually run them if the user approves them. Just blare an alarm telling the user they misclassified a malicious command, and maybe pause the Claude Code session for a frustrating 5–15 seconds. Video games can elicit truly astonishing levels of performance from human brains by using this approach. I'm guessing it's probably outside your Overton window, which is too bad, because it has the potential to work a lot better than the 89% you get with "Auto mode", which is far too low if anything really significant is at risk. That's not even one single order of magnitude lower risk than just "allow everything always".

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 a day ago | parent [-]

this is not a serious proposal

▲

kragen a day ago | parent | next [-]

Not only is it a serious proposal, it's been used in practice in every airport X-ray baggage scanner for decades, where it's called Threat Image Projection (TIP): https://www.xscann.com/products-HiTipPlus.html and it's actually a regulatory requirement in that context in a number of countries: https://caainternational.com/course/threat-image-projection-...

▲

ceejayoz a day ago | parent | next [-]

Yes, but you can require it in such a situation, as they're subordinates who have to follow policy or lose their jobs.

	▲	kragen a day ago \| parent \| next [-]
		As I pointed out above, Anthropic places a lot of requirements on its users already, but if Claude Code TIP were optional, presumably, savvy users would turn it on voluntarily, unless they wanted to use Auto Mode. As Anthropic's study clearly documents, the current manual approval workflow basically doesn't work at all, because the users just approve 87% of dangerous actions. So there's no reason to use it, except maybe very rarely.
	▲	yunwal a day ago \| parent \| prev [-]
		Most of anthropic's money comes from enterprises that may want to enforce something like this at an org level.

▲

DANmode a day ago | parent | prev [-]

The same scanners that let handguns et al through 93% of the time, according to internal audits and journalist review?

Maybe pick a better comparison if so?

▲

cannonpalms 16 hours ago | parent | prev [-]

Enterprises do the exact same thing today by sending phishing emails to their own people to figure out who needs additional training. Why would an enterprise not want this feature for Claude? It seems like an extremely serious proposal.

▲

1659447091 a day ago | parent | prev | next [-]

> 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

▲

imtringued 18 hours ago | parent | prev [-]

If you have a file in your repository that is not safe to run you have bigger problems than your development system getting compromised.

What I mean by this is that if you restrict python execution to the entry point of your software and then Claude wants to run a command anyway so it threads it through the main.py script, you are no longer running something that is contained to your local development environment.

But when you think about it, what exactly prevents Claude from doing that anyway?

Claude could add malware into your project directly.

So the case where you say it doesn't matter which python script it can execute, actually does matter. Restricting python execution to a subset of all files buys you security.

The next step would be to get Claude to stop adding malware to your software, which it hopefully already does not do.

▲

rbehrends a day ago | parent | prev | next [-]

A key problem when using manual approval with Claude is that too much of Claude's tool use is Bash or Python slop that is difficult to review (especially when you are getting spammed by it) and impossible to handle through rules. Example:

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 a day ago \| parent [-]
		Opus especially seems to like to: 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 a day ago | parent | prev | next [-]

Related to that, there are quite a lot of common command cases where you have the choice:

- 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.

	▲	coldtea 13 hours ago \| parent [-]
		That's on purpose, so that you just give up and choose "auto mode". They talk about "decision fatigue" when they're engineering it themselves with dark patterns.

▲

bcherny a day ago | parent | prev [-]

The blog post has more detail, but tldr is humans make mistakes that automation can catch.

	▲	ceejayoz a day ago \| parent [-]
		Sure, but Claude is deeply useless at making permissions hooks! Every time I've tried it it completely fails at the task, despite researching the docs and using various skills. It trivially evades its own just-created rules.