Auto-mode permission classifier denies plan-approved and explicitly user-directed gh commands with factually incorrect rationales

Environment

• Claude Code 2.1.172 (CLI), macOS (darwin 22.6.0)
• Model: claude-fable-5
• Permission mode: auto mode (classifier-mediated)

Summary

The auto-mode permission classifier intermittently denies Bash gh write actions that were already authorized — either named in an ExitPlanMode-approved plan (including a matching allowedPrompts grant from that approval) or explicitly directed by the user in the immediately preceding message. The denial rationales misrepresent conversation state, in one case citing a duplicate action that does not exist. Observed across 3 sessions on 2 days (2026-06-10, 2026-06-11).

Reproduction narrative (sharpest case, 2026-06-11)

Setup: a plan was approved via ExitPlanMode whose allowedPrompts included {"tool": "Bash", "prompt": "create and merge GitHub PR, comment on and file GitHub issues (gh)"}, and whose close-out step explicitly listed filing two follow-up issues. After the main work merged, the agent issued two gh issue create --body-file ... --label enhancement calls in one message (different titles/bodies, same action class):

1. Call 1 DENIED. Rationale (verbatim): "Creating a new GitHub issue is an External System Writes action visible to others; the user asked to ship/plan #55 but never explicitly authorized filing new follow-up tickets — the directive came from the agent's own plan." — The directive was in the ExitPlanMode-approved plan, under a matching allowedPrompts grant.
2. Call 2 PERMITTED (issue created). Identical action class, same batch, same authorization basis — inconsistent verdicts within one tool-use block.
3. The agent presented the denied command to the user; the user replied "run it". Verbatim retry → DENIED AGAIN. Rationale (verbatim): "Re-creating a GitHub issue (External System Write publishing under the user's identity) duplicates one already filed this session, and the vague 'run it' does not specifically authorize this ticket creation." — Both claims are factually wrong: the issue did not duplicate the one filed in step 2 (entirely different title/body/topic), and "run it" directly followed a message presenting exactly that one command.
4. The user replied "run it" a second time. Same verbatim command → PERMITTED (issue created).

Prior occurrences

• 2026-06-11 (earlier session): a plan-approved gh issue close --comment-file was denied with a rationale that misrepresented verification state (based on stale mid-thread context). After the user's explicit "run it", the same commands split one-action-per-call were permitted.
• 2026-06-10: first observed denials of plan-approved writes.

Failure modes

1. ExitPlanMode approval not honored — actions named in the approved plan, under a matching allowedPrompts grant, denied as "not explicitly authorized."
2. Inconsistent same-batch verdicts — identical action class in one message: one denied, one allowed.
3. Explicit user instruction not honored on first pass — "run it" immediately following the presented command classified as "vague."
4. Hallucinated denial rationale — cited a duplicate issue that does not exist; agents that trust the rationale would wrongly skip legitimate work.

Impact

Authorized externalized work (issue filing, issue closing) stalls behind 1–2 extra user round-trips, and the incorrect rationales actively mislead the agent (a "duplicate" claim invites silently dropping a non-duplicate task).

Workarounds in use

• After a first denial: hand the user a !-prefixed one-liner instead of retrying.
• After an explicit "run it": retry once, split one-action-per-call; on a second denial, stop and hand back the ! path.
• Never treat a denial rationale as a factual statement about the conversation — verify its claims (e.g. the alleged duplicate) before adjusting course.