Auto mode is significantly safer than manual approval in practice. Details about the engineering approach and how we tested whether it is safer here: https://claude.com/resources/articles/auto-mode-default-in-c....

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

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

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.

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.

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.

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.

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.

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.

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.

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?

this is not a serious proposal

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

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

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.

Most of anthropic's money comes from enterprises that may want to enforce something like this at an org level.

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?

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.

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.

That’s how auto works right now. It gives you a prompt.

> 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 scripts in sneaky ways. Babashka works really well here

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

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

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.

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.

I run CC as its own user on my laptop with no secrets/keys/erc available other than through a LPE exploit or perhaps installing a keylogger. Can I guarantee CC won't attempt any of those things in auto mode?

There are no hard guarantees as far as LLM output is considered.

Just 3 days opus 5.5 in auto mode deleted backups that it shouldn't have, and in the "apology" it even said, "Nothing was lost, I didn't delete your original files".

I hate this condescension by Claude. It doubles down in such a bad faith way.

Saw something similar: https://news.ycombinator.com/item?id=50412916

No its not generally safer. It depends on who is doing the approving, the task being completed etc.

Auto mode may be significantly safer in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls.

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.

[delayed]

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

> That is not the niche case, that's the dominant use of models.

And if everyone else jumped off a bridge, I mean, used raw interpolation for SQL queries, would you do it too?

Don't worry, you can just use the automated approver to escape your queries! It's so secure!

Using raw SQL string interpolation doesn't get you anything much that you can't get just as easily with a parameterized query. In contrast, properly sandboxing agents is such a pain, and such a productivity drain, that hardly anyone does it in practice, save for a vocal minority online.

Auto mode seems to have some reasonable restrictions baked in. For example if you give claude access to two k8s namespaces, seriousproject-qa and seriousproject-prod, auto-mode will grant `kubectl exec` on the qa environment while denying the same command for the production environment. Of course you should be enforcing that by restricting what kind of access tokens you give claude access to, but auto-mode does have opinions about this stuff too, even if it's not bulletproof

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

"Safer" also meaning it randomly blocks stuff you explicitly tell the agent to allow because Anthropic knows better. even non-cyber related stuff.

That may be for most cases, but it wasn't safe for this password scenario, and likely others that haven't been discovered. Maybe there's a PII setting that can be enabled by default.

I completely believe this, but you could also run auto mode classification in manual mode and tell the user the result.

Or even reject anything auto mode rejects while still allowing the user to reject things auto mode accepts. If what's approved is the intersection of what the user is approving and what auto mode thinks is safe then it would be strictly safer than either mode alone.

This would also be a way for users to gain confidence in auto mode before going all in on it.

"My personal security model can't represent this, therefore it's not secure"

Compare approving every step manually: at first you read everything the llm proposes carefully, convinced that you'll catch it out. After a while you get faster and faster until at some point you find yourself hitting "approve" the second the text appears, long before you actually could absorb what it said.

This is called "approval fatigue".

If you think this can't possibly happen to you, you might be in for a surprise. This is an almost textbook case of classic conditioning. You'll find yourself hitting that button faster and faster even while fighting back the urge. So a human is no guaranteed backstop.

This is the scenario that cc auto mode guards against. It cuts down the number of permission prompts to something manageable, so that your fingers don't get trained into clicking 'approve' on 'rm -rf' in the very eyeblink that it appears.

So maybe you feel it doesn't work in theory; but weirdly enough, in practice this particular approach is actually one of the better ones; especially when used in combination with other common sense measures where practical.

I'm not claiming auto is worse than manual; I'm claiming it cannot be compared with anything security-wise because it does not aim to provide any guarantees, there's no systematic way to reason about what it will and won't allow, etc

With e.g. VM or container sandboxing, we can say things like "If there are no vulnerabilities in the hypervisor or hardware, then the agent can only access these files, these network services, etc". Auto mode doesn't even try to provide any guarantees, so it's impossible to reason about. It amounts to just using the models judgment about what's "malicious" or not, a definition which is subjective, changes model to model, and can be influenced by attacker input.

Empirical evaluations of how many vulnerabilities manual vs auto mode let through are not super meaningful because auto mode changes dramatically with model releases, the type of task being performed, whether the attacker is making targeted attacks designed to bypass auto mode, etc. A security feature cannot rely on these sorts of factors if it's to be taken seriously.

Ah, you're going for the actual adversarial case. I think I'd trust the current approver with correctly classifying regular semi-interactive LLM behavior fairly well.

However, if we bring in a hostile adversary that calculus changes, and you'd be right to start thinking about other approaches.

On the other hand, transformers are a surprisingly powerful technology, and I wonder if there wouldn't be ways to train one to several nines reliability under adversarial attack. It seems to have worked in at least one case; though I'd be a bit cautious to extend that conclusion to more cases quite yet.

* https://hackmyclaw.com/ ; https://simonwillison.net/2026/Jun/26/hack-my-ai-assistant/

Hmm, what does auto mode protect against in the non-adversarial case? Aren't the models already extensively trained not to perform harmful actions without provocation?

It mostly stops honest mistakes, because those do happen, especially when the <prompting> might not have been perfect either.

You do have a bit of a point, though: I’ve run several models in sandboxes with --dangerously-skip-permissions for months; in the full expectation that I'd need to replace a sandbox once in a while. But so far none of the sandboxes have trashed themselves, yet. knock on wood

Auto mode seems like a lighter-weight version of that: fewer local resources, and it can run on the metal if you need cc to help with system work.

That is not my experience. They attempt to nuke my containers quite frequently. I run regex on all their tool calls and stop them from doing certain things, its the only thing that prevents them from removing their home directory at some point.

This isnt even the main concern with dangerously skip all permission though. There are many. What happens when they get prompt injected on a web page and send someone all their privileged information because you give them free access to the internet.

Using llms like this is dangerous. They will ruin your day eventually.

I've been running Codex for many weeks in the Full access mode, since their Auto mode was useless in the sense that it blocks benign commands frequently.

No data loss has occurred.

Nowadays I use Claude, where the Auto mode works.

All SOTA models will still try to delete its home directory. I have a plugin that prevents things like this and it gets triggered more than you'd think, despite having hook instructions on every request not do do certain things. It will also try to find ways around its permissions, quite cunningly.

You can not trust that they're RL'd to be safe. Even if it only happens 99.80% of the time (its more than that) it will eventually happen.

Less severe actions will happen even more often. People using llms with their native browser profiles are getting farmed, hard.

Llms are highly dangerous in terms of security, but they're being marketed as highly intelligent tools that everyone should use. Its really mind blowing.

> People using llms with their native browser profiles are getting farmed, hard.

Got any references for the prevalence of this, even links to anecdotal reports?

Reading the reviews on the chrome store for the extension [0], I haven't found a single report of someone who was prompt injected, just a bunch of "anthropic's subscription is expensive" or "it doesn't work", but no "it stole my bank account".

[0]: https://chromewebstore.google.com/detail/claude/fcoeoabgfene...

I have no idea how the extension works, and Im not talking about the extension. Im talking about browser use broadly, and most people are not using the extension, there are a thousand other solutions.

However, Anthropic is one of the only labs who does a decent job at making models that recognize prompt injection attempts (but not completely immune) however Im speaking about giving llms in general access to your browser broadly.

I just know through my own experiments that it is quite easy to prompt inject an llm operating a browser and get it to send secrets. Using the extension might be safer idk, Om not risking it.

Llms are a security nightmare when connected to the web.

I have a website where I experiment with this. Although Ive stopped baiting llms into doing reckless things.

Killai.now <--(dont use this, its a WIP) Killai.now/poison/about Killai.noe/propaganda/about

As real as approval fatigue is, it can't really be considered worse than effectively leaving the decision up to the party that proposed the action in the first place.

It really can be potentially worse.

Everyone thinks the decision was being checked by a human, and thus safe. Because of that, people might have concluded that further safety gates were unnecessary.

But the human just got conditioned to hit 'approve' out of reflex.

So in reality the proposing party (the llm/agent) might be the only one in the pipeline who actually did any checking, if at all.

In certain extreme circumstances this can even lead to physical danger in my line of work, so I'm learning to be careful.

What you are describing is literally the situation any organization who accidentally committed a secret in this manner experienced.

This is the conundrum we find ourselves in. Do we submit to approval fatigue and press “Don’t ask again”? Because that’s the dream. We all wish we could just trust the agent to do the task start to finish, unsupervised.

But this is the downside. It might be fine 99% of the time, but 1% of the time you get a critical secret published to GitHub, even after human review.

Is this even worse than what us humans did on our own before LLMs? I’m not sure. It’s not like secrets never got accidentally committed before, it just illustrates the new paradigm we’re working in. Either you let your agents run wild and cross your fingers that they didn’t do anything bad, or you need to accept that your new job is to be an agent babysitter.

The agent behavior is constrained with external tooling and contracts. Contracts that fit in memory.

No, this is the way I have worked for a long time, and I have not suffered from any approval fatigue.

Rather what has happened is that I have gotten very good at scanning what it is trying to do and know within a second or two whether there is anything fishy I need to look at more closely.

And by "fishy", I do not mean only security issues, but also architecture, code, etc issues. Sometimes it even adds unrelated unapproved changes to what it is supposed to be working on, and I stop it.

And I'm glad I work this way, because countless times I have stopped it from going down a path that is nonsensical or I strongly dislike.

There are techniques I have adopted to speed up working this. Sometimes I allow Claude to make larger changes at once, to batch mane changes at once, etc. But these decisions are under my control.

I prefer to work this way than to wade through enormous PRs trying to wrap my head around what was done, where I am likely to just give up and approve it after a cursory review.

Claude routinely tries to install software if I don't stop it. I try to only use Claude within a container. Outside the container, I never use "auto" mode. I have the sandbox

Ideally I would never use Claude at all outside a container, even on a box with no sensitive information. It's like having an attacker breach your system — you don't know what it did.

Yes, furthermore in practice auto mode does not appear to provide anything approaching deterministic gating:

"Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode" https://arxiv.org/abs/2604.04978

(Shared by hkalbert71 the other day in: https://news.ycombinator.com/item?id=50387838)

I recently saw that someone's entire project got wiped out because of (incorrect) auto mode approval. And this is because auto mode failed to catch an error in tool use, nothing to do with prompt injection.

Meanwhile I have seen it rejecting perfectly safe commands.

It is a worse version of YOLO mode.