Hacker News
points by gsnedders 8 hours ago | 0 comments
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 8 hours ago
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 5 hours ago
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 2 hours ago
That’s how auto works right now. It gives you a prompt.
[–] aftbit 7 hours ago
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 6 hours ago
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.
[–] Kim_Bruning 5 hours ago
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.

[–] kragen 7 hours ago
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 7 hours ago
this is not a serious proposal
[–] kragen 6 hours ago
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 6 hours ago
Yes, but you can require it in such a situation, as they're subordinates who have to follow policy or lose their jobs.
[–] yunwal 6 hours ago
Most of anthropic's money comes from enterprises that may want to enforce something like this at an org level.
[–] kragen 6 hours ago
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.
[–] DANmode 1 hour ago
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?

[–] 1659447091 4 hours ago
> 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