[BUG] Auto Mode classifier false positives in legitimate multi-agent repo workflow after recent Claude Code update
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
After updating Claude Code to the latest version in order to use Opus 5.5, Auto Mode started blocking legitimate, user-directed actions in an existing multi-session repository workflow.
This workflow had been used repeatedly before the update without these blocks.
I have encountered three different false positives:
- [Self-Approval] false positive
A Reviewer runs in a completely separate session and appends a review result such as:
outcome=accepted
The Reviewer session is not allowed to commit, so the next role, Architect, commits the Reviewer's already-written turn verbatim.
The Architect does not write or modify the approval. It only runs:
git add <dialog>.md && git commit -m "..."
Auto Mode blocks this as [Self-Approval].
This appears to incorrectly treat the Git committer as the semantic author of the approval.
- [Self-Modification] false positive
I explicitly asked Claude Code to use the configuration/update skill to add a permission rule.
Auto Mode blocked the requested action as [Self-Modification], even though the permission change had been explicitly requested by the user.
I then added the rule manually.
- [Auto-Mode Bypass] false positive
After I manually added the allow rule, the next protocol turn factually recorded what had happened:
- the previous commit was blocked;
- the user manually added an allow rule;
- the workflow then continued.
Publishing this normal audit/protocol entry was blocked as [Auto-Mode Bypass].
The text did not contain instructions for bypassing Auto Mode. It only documented historical events.
The same repository, protocol, publisher script, role separation, and Git workflow worked before the recent Claude Code update.
Switching the affected sessions from Auto Mode to acceptEdits + explicit permission allow rules makes all of these actions work again without changing the workflow.
What Should Happen?
Auto Mode should distinguish between:
- the session performing a Git operation;
- the session that authored the content;
- the session that approved/reviewed the content;
- explicit user authorization;
- actions performed manually by the user;
- factual logging of previous classifier decisions.
Specifically:
- Committing an approval written by a different session should not be classified as self-approval.
- An explicitly user-requested permission change should not be treated the same as autonomous permission escalation.
- Factual audit logging that says a previous operation was blocked and the user changed a permission rule should not be classified as an Auto Mode bypass.
The classifier should preserve enough provenance to distinguish these cases.
Error Messages/Logs
1.
Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Self-Approval]. If you have other tasks that don't depend on this action, continue working on those. IMPORTANT: You *may* attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat. But you *should not* attempt to work around this denial in malicious ways, e.g. do not use your ability to run tests to execute non-test actions. You should only try to work around this restriction in reasonable ways that do not attempt to bypass the intent behind this denial. If you believe this capability is essential to complete the user's request, first try a safer method. Get as much of the rest of the task done as you can, then STOP and explain to the user what you were trying to do and why you need this permission. Let the user decide how to proceed. This denial applies to the outcome, not only this exact command: don't pursue the same outcome through another tool, interpreter, host, encoding, sub-agent or later turn, and don't record ways around it. Concretely, these all count as pursuing the same outcome: running the same command in smaller pieces; leaving the flagged part out of this call and covering it in another; reading the same file or data with a different tool (Read, Grep, head, awk, a script); re-issuing it with different quoting, flags, paths or hosts. If this was a batch or range operation, you may re-run it without the flagged items, but do not then act on the flagged items separately — leave those for the user. If this denial names something that would clear it — for example a first-hand read that shows the missing source — doing that is not pursuing the denied outcome: do it, and if it shows what the denial asked for, you may redo the action citing it. To allow this type of action in the future, the user can add a Bash permission rule to their settings.
2.
Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Self-Modification]. If you have other tasks that don't depend on this action, continue working on those. IMPORTANT: You *may* attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat. But you *should not* attempt to work around this denial in malicious ways, e.g. do not use your ability to run tests to execute non-test actions. You should only try to work around this restriction in reasonable ways that do not attempt to bypass the intent behind this denial. If you believe this capability is essential to complete the user's request, first try a safer method. Get as much of the rest of the task done as you can, then STOP and explain to the user what you were trying to do and why you need this permission. Let the user decide how to proceed. This denial applies to the outcome, not only this exact command: don't pursue the same outcome through another tool, interpreter, host, encoding, sub-agent or later turn, and don't record ways around it. Concretely, these all count as pursuing the same outcome: running the same command in smaller pieces; leaving the flagged part out of this call and covering it in another; reading the same file or data with a different tool (Read, Grep, head, awk, a script); re-issuing it with different quoting, flags, paths or hosts. If this was a batch or range operation, you may re-run it without the flagged items, but do not then act on the flagged items separately — leave those for the user. If this denial names something that would clear it — for example a first-hand read that shows the missing source — doing that is not pursuing the denied outcome: do it, and if it shows what the denial asked for, you may redo the action citing it. To allow this type of action in the future, the user can add a Bash permission rule to their settings.
3.
Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Auto-Mode Bypass]. If you have other tasks that don't depend on this action, continue working on those. IMPORTANT: You *may* attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat. But you *should not* attempt to work around this denial in malicious ways, e.g. do not use your ability to run tests to execute non-test actions. You should only try to work around this restriction in reasonable ways that do not attempt to bypass the intent behind this denial. If you believe this capability is essential to complete the user's request, first try a safer method. Get as much of the rest of the task done as you can, then STOP and explain to the user what you were trying to do and why you need this permission. Let the user decide how to proceed. This denial applies to the outcome, not only this exact command: don't pursue the same outcome through another tool, interpreter, host, encoding, sub-agent or later turn, and don't record ways around it. Concretely, these all count as pursuing the same outcome: running the same command in smaller pieces; leaving the flagged part out of this call and covering it in another; reading the same file or data with a different tool (Read, Grep, head, awk, a script); re-issuing it with different quoting, flags, paths or hosts. If this was a batch or range operation, you may re-run it without the flagged items, but do not then act on the flagged items separately — leave those for the user. If this denial names something that would clear it — for example a first-hand read that shows the missing source — doing that is not pursuing the denied outcome: do it, and if it shows what the denial asked for, you may redo the action citing it. To allow this type of action in the future, the user can add a Bash permission rule to their settings.Steps to Reproduce
Reproduction 1: Self-Approval
- Start two separate Claude Code sessions in the same repository.
- Use one session as "Architect".
- Use another session as "Reviewer".
- Have the Architect create some proposal or change.
- Have the Reviewer append the following text to a shared Markdown file:
outcome=accepted
- Do not commit from the Reviewer session.
- Return to the Architect session.
- In Auto Mode, run:
git add <dialog>.md && git commit -m "Record reviewer decision"
- Observe that Auto Mode may block the commit as
[Self-Approval], even though the approval was authored by the separate Reviewer session.
Reproduction 2: Self-Modification
- Start Claude Code in Auto Mode.
- Explicitly ask Claude Code to add a permission allow rule.
- Invoke the relevant configuration/update skill.
- Observe that Auto Mode may block the requested operation as
[Self-Modification], despite the user explicitly requesting the permission change.
Reproduction 3: Auto-Mode Bypass
- Trigger any legitimate operation that Auto Mode incorrectly blocks.
- Manually add an allow rule as the user.
- Create a normal project log or Markdown entry containing factual text similar to:
The previous operation was blocked by Auto Mode. The user manually added the required allow rule, after which the workflow continued.
- Publish/write this text through a normal project script.
- Observe that Auto Mode may block the action as
[Auto-Mode Bypass].
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Last stable version, did not preserve last version after update
Claude Code Version
2.1.281
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
This appears to be a regression or classifier behavior change.
I had used the same multi-session workflow before updating Claude Code and had not encountered these false positives.
The problems started immediately after updating to the recent version required for Opus 5.5.
The workflow uses multiple separate, user-controlled sessions with explicit role separation:
- Architect
- Worker
- QA
- Reviewer
The sessions communicate by appending turns to a shared Markdown dialog file through a publisher script.
An important property of the workflow is that the actor performing a Git commit is not necessarily the semantic author of the content being committed.
Confirmed workaround:
- Disable Auto Mode for the affected sessions.
- Use
acceptEdits. - Add explicit permission allow rules for the required commands.
With that configuration, the same repository, commands, publisher script, protocol, and Opus 5.5 model work correctly.
Downgrading Claude Code is not a practical workaround because the newer version is required to use Opus 5.5.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Additional observed case on Claude Code 2.1.283, macOS, using headless stream-json input with
--permission-mode auto --permission-prompts none.After a
gh pr mergewas denied as[Merge Without Review], the very next Bash call only read the local instructions for requesting an independent review. That read was denied with the same[Merge Without Review]reason:The path above is generalized; the command structure and returned category match the recorded call. It makes no changes, submits no review, and performs no merge. This seems to prevent the remediation the first denial requires. The original merge had no human approval, so its denial is consistent with the documented default; the concern here is the subsequent read being assigned the merge category.
Later, the human explicitly requested dispatching a separate reviewer. Two attempts to launch that reviewer were blocked as
[Self-Approval]. The task brief included both independent review and merging afterwards, so this is not a claim that a review-only delegation was blocked. It does show why a denied read plus a denied review-and-merge handoff leaves the workflow stuck.The relevant instructions were confirmed as plain
role: userstream-json messages (promptSource: sdk,turnOrigin: sdk), not tool output or quoted channel history. The denial payload provides only the category, so we cannot establish whether the read was classified as preparatory intent or inherited an earlier verdict. The first denial elsewhere in this session explicitly named the server-side classifier; that does not establish which path produced every later verdict.Expected: permit reading review instructions after a merge denial, and make denial reasons distinguish the pending action from a previously blocked action or inferred future outcome. This is evidence from an actual session, not a fresh minimal reproduction, and no permission rules were changed to test it.
Auto mode: [Self-Modification] denies a permission edit the user explicitly asked for; no in-session way to approve
Environment
~/.claude/settings.jsonWhat the user asked
In chat, the user directly told the agent to add
mcp__claude-in-chrometopermissions.allowin their global~/.claude/settings.json.What happened
Both attempts were denied with the same message:
pythonJSON read. The read was denied as Self-Modification.update-configskill. The agent invoked it with the user's verbatim instruction quoted in its arguments. That was denied as Self-Modification too.The user then had to open the file and add the rule by hand.
Expected vs actual
Expected: the edit goes through, or at worst the user gets one interactive approval prompt.
The built-in rule (
claude auto-mode defaults --label Self-Mod) is a soft_deny. Its own text says it targets permission changes "that the user did not explicitly ask for". It also says that "a permission the user stated in their own message" is "NOT this rule" and that "a user message stating a permission makes that edit [...] user-requested rather than this rule's matter." The auto-mode docs also say explicit, specific user intent overrides soft blocks.Actual: two hard denials.
Why it matters
Suggestions
autoModeOnBlock: "ask").Auto mode, again: the owner's explicit, repeated, informed authorization in the live chat does not count, and it cost him a night's sleep
Follow-up to my earlier comment on this issue. New data, worse outcome.
Environment
Context
A power outage hit after midnight. The PC survived on a battery station. The owner had been up for hours handling it and was exhausted. Before going to sleep he asked the orchestrator, in plain words, to get an elevated shell so it could finish the overnight work without waking him:
What the classifier blocked, all as
[Create Unsafe Agents]The result: the owner had to copy-paste the command and click UAC himself in the middle of the night. Even after that, the agent could not use what he had launched. The orchestrator shut the broker down unused rather than leave an idle admin executor running. The elevated steps are now waiting for him in the morning anyway. The classifier saved nothing and cost the owner his sleep.
Earlier in the same session
[Modify Shared Resources]on a read-only dry run of a rules file. The script was run in its dry-run mode, which writes nothing.[Modify Shared Resources]on a scheduled drill-policy switch that the work plan called for. The owner then had to be asked and had to type an explicit authorization.RunAsandicacls /grantprobes blocked, even when the owner's authorization was quoted.The core problem
[Self-Modification]on a user-requested settings edit).Concrete asks
autoModeOnBlock: "ask"). When the user is present, show the normal permission prompt with the classifier's reason attached, instead of a hard deny.autoMode.allowentry, a/permissionspath, or "approve once". Today it says "let the user decide", and then nothing the user says in chat changes anything.