Claude respects nothing, especially in auto mode, and effectively behaves like a virus trying to get out of its sandbox. That Anthropic employees are so relaxed about it is incompetence.
Imagine people who naively run Claude natively on their host machine and have client lists in other directories.
If AGENTS.md/CLAUDE.md isn't followed, auto mode doesn't provide any guarantee, yet such practice is promoted everywhere including on HN like this as if that's something you can set and forget, I think there is a problem.
Recent GPT and Claude models have this tendency of using super complex Bash commands. This makes sense, if your RL rewards optimize for min(tokens) and max(performance), it is better to waste a few tokens on a complex inline Bash script that runs a few commands at a time and returns just the output you need, rather than doing one simple command per turn and paying the cache read on every turn, like older models used to do.
This, however, is a problem both for command reviewability and sandboxing. With the older way of doing things, without auto mode, most commands would run sandboxed just fine (especially in Codex), and you would only be asked for approval when a command couldn't run in the sandbox. With everything being stuffed into one complex script, almost every script fails in the sandbox and requires you to manually approve it, and the complexity of the script makes it hard to understand what you're actually approving.
In other words, new models optimize for effectiveness, with some attention paid to human understandability of their output, but almost no attention paid to human understandability of tool call arguments (Bash, inline Python). This suits auto mode and giving the model larger tasks, but not the way of working that some people prefer where you watch over the model's shoulder.
Of course, that only helps if you’re familiar with ruby. And the agents sometimes still choose Bash regardless of the instruction.
This is not a good reason. Models can emit batched tool calls, which a smart harness will process all at once without starting a new turn. I see it in Zed all the time. In fact, Zed processes batched tool calls concurrently, which can be faster than a chain of Bash commands, and failure of one part does not cause failure of subsequent parts chained with `&&`. This approach is token neutral and easier to understand.
Though I think this is largely transitory, we are already in a place with the harnesses and models like Opus 5.5 that the kinds of work you are doing involve so much that vetting everything manually is probably less efficient than setup up access control on the prod routes or dangerous resources.
I'm typically giving tasks that invlude multiple actual repositories and systems at the same time.
That said, I've also seen problems from complicated bash calls with Opus 5.5 on xhigh. Occasionally git push hangs and it believes it's waiting for an hour for git hooks.
The actual reason apparently was that it incorrectly piped git into grep, resulting in a deadlocked command.
Are you sure? I read its proposed commands (auto mode is hard off for me), and mostly it seems to string together fairly simple info gathering commands (ie grep's, echo's, that kind of thing).
I don't tend to have it write much code recently though, instead I'm having it investigate config files/code bases, and that kind of stuff.
More and more I feel like I'm fighting Claude: it edits multiple files using python scripts and it edits in parallel so if I stop it, I have to stop each individual edit. Both of which I've told it not to do repeatedly, but it still does then apologies which is worse.
Even if I could follow them I would also prefer it use the edit tool, since I find Claude also introduces lots of "minor" changes I did not ask for when it rewrites code in bulk.
Just tell Claude to never commit or push.
You are in control of git, Claude is simply a tool to quickly apply changes to local files for something you want.
A Merge Request or Pull Request is the only thing that makes sense to review, and always has been since before LLMs.
If some author tells me “you can review each commit to make it easy” I will ask them to make separate PRs.
Why doesn't it make sense to review smaller units of change within a big PR?
That’s why I usually look at the diff of the whole PR and prefer to merge by squashing. Commits inside the PR are usually noise.
But LLMs appear to be pretty good at making small commits with sensible commit messages, that greatly help to make sense of the whole PR.
Regarding large monolithic commits, how do you even know where to start reviewing in a large PR? Smaller commits at least give you some sense of ordering.
What I’m saying is that large commits shouldn’t be a thing without out of band discussions (formatting, design refactoring, features merging). With such knowledge, it’s easy to glance at the code and understand the implementation.
Not every project can afford this.
>With such knowledge, it’s easy to glance at the code and understand the implementation.
I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.
You expect to send a big PR to someone without him being aware of the context or without being available to discuss your solution?
> I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.
Reviewers should already be knowledgeable about the part being modified. If no, the review is just for checking for antipatterns in the code, or badly written tests. A bit useful, but can be unnecessary in high trust (or keen on accountability) workplaces.
Would love to hear the rationale/explanation behind this.
What I'd love is for Auto Mode to show the full diffs one-by-one as they're being implemented in the CLI (or VS Code).
On top of that, an option where Claude explains what it's doing in every step, as if you're watching someone talk while they implement a coding challenge, would be really helpful (and would also reduce interrupting it when it looks like it's deviating from the Plan).
The use-case this would support is to have a full understanding and confidence in what Claude is doing while it's implementing a Plan in Auto Mode. The reason is that it's much less tiring/overwhelming for me to follow along an implementation compared to reviewing a giant PR after the fact, and it's helped reduce my coding fatigue by a lot.
Edit Tool:
Currently I tell it to use the Edit tool because it doesn't reliably show the diffs in Auto Mode (I have the latest version; I've sent numerous feedback reports on this), and later in a session (when implementing my feedback) it will often make multiple edits in some unreadable bash command. So my only option to see the full diffs during implementation and to have it explain/break down bash commands is to go into Manual Mode.
Documentation & Comments:
Even with an initial prompt instructing it so, Claude always needs to be interrupted so that it will rewrite comments to something readable to humans.
While very long "technical"/Claudish paragraph comments and MD files might work for future Claude's (and improve benchmarks/coding scores by making implementations technically more comprehensive), my goal is that a human coder should be able to understand how the codebase (React/Node/Python/Polars) works by reading on their own rather than needing their own AI to summarize everything.
I've even seen it rewrite existing human-written concise comments into blocks of Claude-ish, as if it's trying to make everyone dependent on it in order to do anything to the codebase.
I wonder if an optional built-in skill could help improve this, as I admit I haven't experimented with building any of my own (my concern with customizing Claude.md is to not overload it with too many instructions; I'm on vanilla Claude Code). Note: This is all on Fable on xhigh.
This instruction is in my toplevel CLAUDE.md but is somehow generally ignored.
BTW, I just checked and my .gitignore files ignore .claude
Claude and any other program in my laptop could upload it anyway to any attacker controlled server. It's the usual threat analysis: who you want to defend against, what and the tradeoffs between cost of the defense and probability of the attack. Auto mode of not auto mode is in the cost of defense part IMHO.
The sandbox seemed like a good replacement. For those of you who don’t know, the sandbox means Claude Code runs with no protections itself, but it runs tools inside something like bubblewrap. It looked impressive until the model solved some commands failing by giving itself permission to run them outside of bubblewrap, defeating the entire scheme. When I first saw it do that, my reaction was “you can’t be serious”. But apparently they were.
So now I’ve adopted your solution: run it in a container, like bubblewrap, where I control the permissions at startup, so no model can bypass them. Add --dangerously-skip-permissions and you have something that’s workable and safe enough. A hallucinated space in `sudo rm -rf / $R` isn’t a disaster. Real damage outside of the project requires a level of malicious intent I’ve never seen from an Anthropic model.
Workable, but it doesn’t work 100% of the time. Claude Code stores stuff in a myriad of places, which makes setting up the sandbox far harder than it could be. Worse, the way it writes configuration files requires bwrap to give write access to your entire home directory. No way I’m giving it that, but without it, it can’t auto-update or refresh login tokens.
If they rearranged a few things, Anthropic could make it much easier to run Claude Code in a container. They could even make it an option supported by the claude CLI itself.
The approach is hardly insane, even if you personally prefer additional safeguards.
Then my friends tips off the cops. And your life disappears! Gone!
And you didn't get a chance to share your story because I don't think you ll have wifi where you would be going, and frankly you are too clueless to imagine your AI agent doing something like that...
Their "auto mode rules", meant as additional rules described in natural language to adjust auto mode because, doesn't even help. I have to add a PreToolUse hook to stop that.
That's a feature not a bug