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.
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.
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.
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.
Would love to hear the rationale/explanation behind this.
This instruction is in my toplevel CLAUDE.md but is somehow generally ignored.