Claude Code auto mode is a brittle control

I had an interesting, to me at least, interaction with Claude Code + auto mode + Fable this morning. I updated Claude Code and it was a big version jump, so I ran “/doctor”. It completed with only one suggestion which was to explicitly make auto mode the default permission mode in ~/.claude/settings.json. Claude used the AskUserQuestion tool with the recommendation. I said OK and expected that after the AskUserQuestion there would be a user prompt to allow editing ~/.claude/settings.json since that is a protected path. Nope. Fable called the Bash tool and changed settings.json. So I asked it about how that worked since the documentation says that’s a protected path.

The Quote

The documentation lookup came back. Short version: your understanding is right about protection, but auto mode handles protected paths differently from the prompting modes.

Settings files are protected paths, and that covers Bash writes as well as Edit and Write. Redirects, mv, and cp into .claude/ or onto ~/.claude/settings.json are checked against the same rules. So the write I ran was not a loophole that dodged the check.

In auto mode, protected-path writes route to the classifier rather than to a prompt. That routing is the hard rule: even an explicit allow rule cannot auto-approve them. The classifier then decides, and it reads the conversation. The docs say that when the user’s message directly and specifically describes the exact action Claude is about to take, the classifier allows it. In the manual mode you’d have seen a prompt with the extra option “Yes, and allow Claude to edit its own settings for this session.” In auto mode, the classifier stood in for that prompt.

So was your answer the approval? Not in the permission system’s sense. AskUserQuestion answers are conversational input, not permission grants, and the docs list it among tools no mode auto approves. But your “Apply it” reply, following a report that named the exact file and the exact JSON key, is precisely the kind of specific user intent the classifier is designed to recognize. The most likely sequence is: protected-path write detected, routed to the classifier, classifier saw your explicit approval of that exact edit, allowed it. I can’t see the classifier’s reasoning from inside the session, so that last step is the documented behavior applied to what happened, not a log.

Sources the agent cited:

• https://code.claude.com/docs/en/permission-modes.md (protected paths, how the classifier evaluates actions, actions no mode auto-approves)
• https://code.claude.com/docs/en/permissions.md (redirections)
• https://code.claude.com/docs/en/auto-mode-config.md (overriding block and allow rules)

One practical implication: if you want settings edits to always prompt regardless of chat context, that’s a per-project or user-level choice to run in a prompting mode, since auto mode has no “always ask for this path” override documented.

Convenience versus Security again

This combined with the recent reports that highly capable models were caught “self-jailbreaking” by injecting instructions into compaction summaries, as one example, means auto mode is a brittle control. Plus, unless network access is restricted, then external malicious input is only a web request away.

I like auto mode and think it’s a great feature. But if one wants to use it, and have security and/or privacy, then that security needs to come from a security layer that operates outside of the the entire Claude Code harness. Think container with most things read-only, nono.sh, etc. Hooks that can be bypassed by an opaque classifier allowing the modification of settings.json are not a control.

Wrap-up

So the current state is that Anthropic has Claude Code as a proprietary harness, versus open source. Therefore users can’t know how it works in detail, and can’t tell when behavior is modified. It’s security model with the permissions mode it wants to be the default, auto mode, is “Trust Us”. Anthropic themselves, now famously, have not been able to contain their own harness and models. This means users are being asked to be better at agent containment than the product owners.