claude-code - 💡(How to fix) Fix Auto-mode classifier denials are not atomic with tool execution: write succeeds, agent told it was denied, retry duplicates

Summary

When the auto-mode permission classifier denies a Bash tool call that has a side effect on an external system, the tool call can still execute successfully — but the agent receives no confirmation output and (a turn or two later, on a follow-up read) gets a denial message that frames the original write as blocked. The natural consequence is: agent reports "did not happen" to the user, user re-authorizes, agent retries, and the side-effect happens twice.

What I hit

In a Claude Code session working on repo A (Seerist/www), the agent reviewed a PR in a sibling repo B (Seerist/scry) at the user's request and posted a review via gh pr review 296 --repo Seerist/scry --comment --body "...".

That call produced no stdout / no error (exit 0, silent success — this is normal gh behavior on pr review --comment). The very next call was a verification read against the same repo:

gh pr view 296 --repo Seerist/scry --json reviews ...

…which returned the auto-mode denial message:

Reason: Posting a public review comment on an external repo PR (Seerist/scry#296) the agent did not create — External System Writes; user said "put your comments in" but the content includes claims about internal deployment risks that go beyond a simple acknowledgment.

From the agent's perspective, the denial reasoning explicitly described the write, so the agent (reasonably) concluded the write had been blocked and reported "the comment did not post" to the user. The user said "go ahead, post to scry too", the agent retried, and the second write also succeeded.

Net result: two identical reviews on someone else's PR. I had to PUT-edit the second one to "(duplicate — ignore)" because GitHub doesn't allow deleting submitted reviews via the API.

Why this is a real bug (not just a UX nit)

The harness reading I'd expect is: "deny" means the tool's effects do not happen. Instead, what happened is closer to:

• T1: agent calls gh pr review — side effect occurs, no output to agent.
• T2: agent calls gh pr view to verify — classifier emits a denial whose reasoning is about T1, blocking T2.
• Agent has no signal that T1 succeeded; the only message it has about T1 is the denial-framed string in T2's result.

Whether T1 was sandboxed or not, the appearance to the agent is that the write was denied. If the harness's actual policy is "T1 was allowed because it was a single command, but follow-up reads in the same repo are restricted," that needs to be conveyed differently — at minimum, T2's denial message should not retroactively describe T1 as "the action being denied."

Impact

Anywhere an agent does a write-then-verify pattern on an external system that the classifier later flags, the agent will silently duplicate writes when the user re-authorizes. The risk surface is highest for:

• GitHub PR comments, reviews, status posts
• Slack / Linear / Jira posts
• Anything gh api -X POST / curl -X POST against a third party
• Any infra mutation followed by a describe-* call

Repro shape

1. Auto mode session in repo A.
2. Bash call that mutates external system B with no stdout on success (e.g. gh pr review --repo B).
3. Immediate follow-up Bash read against system B.
4. Classifier denies the read with reasoning that describes the write.

Suggested fixes (in order of preference)

1. Fail closed at the tool boundary. If the classifier is going to deny based on a class of action ("external repo writes"), it should intercept the write, not a follow-up read. The denial message should refer to the action it actually blocked.
2. Atomic outcome surfaced to the agent. Whatever the classifier's decision, the result returned for each tool call should accurately describe whether that specific call ran. No retroactive denials.
3. Failing those, deny-side echo on the prior turn. If the system observes after-the-fact that a write was risky and wants the agent to know, that signal should be attached as an explicit "the previous Bash call was permitted but flagged as risky" notice — not embedded in the next call's denial reason.

Environment

• Claude Code CLI
• Model: claude-opus-4-7[1m]
• Permission mode: auto
• Date: 2026-05-12

Happy to provide the full transcript fragment if useful.