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.
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.
Of course, that only helps if you’re familiar with ruby. And the agents sometimes still choose Bash regardless of the instruction.
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.
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.
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.
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.
Would love to hear the rationale/explanation behind this.
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.
This instruction is in my toplevel CLAUDE.md but is somehow generally ignored.