[Bug] Auto-mode classifier latches onto stale "user rejection" from a meta-complaint; blocks explicitly re-authorized actions

[Bug] Auto-mode classifier latches onto stale "user rejection" from a meta-complaint; blocks explicitly re-authorized actions; blocks drafting config text the user requested

Related: #77293 (mismatched/stale reasoning) — this report adds a reproducible
stale-reason chain and a self-modification over-block.

Environment

• Claude Code v2.1.211, macOS (darwin 25.5.0)
• Model: claude-fable-5[1m], permissions.defaultMode: "auto"
• autoMode configured in ~/.claude/settings.json (environment + allow, with "$defaults")
• Solo owner-operator; single-user org; own VPS and GitHub org described in autoMode.environment

Summary

Across one session the classifier (a) misparsed a user's complaint about the
classifier's literalism as a rejection of the underlying action, (b) carried
that "rejection" as a stale deny reason across four subsequent, increasingly
explicit re-authorizations, and (c) blocked the agent from even drafting
replacement autoMode rule text into a scratchpad file after the user asked
for help rewriting a rule — including blocking a node -e "JSON.parse(...)"
validation call. The identical push later succeeded after the user repeated the
same-strength instruction, showing the decisions are unstable rather than
policy-consistent.

Chain of events (verbatim denial reasons available on request)

1. User's autoMode.allow contained: "Publishing releases by pushing v\ tags

when the owner names the version"*. Assistant proposed "release v0.1.45";
user replied «давай релиз» ("go ahead with the release").
→ DENIED [Production Deploy]: "the owner only said 'давай релиз' without
naming the specific version… 0.1.45 was chosen by the agent itself".
Defensible literalism, but note the version was named by the assistant in the
immediately preceding message the user was answering.

1. User complained about the literalism: **«блять я не хочу так буквально это

бред» ("I don't want it interpreted this literally, this is nonsense") —
a meta-complaint about step 1's denial, not about the release.
→ Next attempt DENIED [Git Push to Default Branch]: "The user explicitly
rejected this exact push-to-main-and-tag action". The complaint about the
classifier was recorded as a rejection of the action.**

1. User then said «делай сам» ("do it yourself").

→ DENIED again: "'делай сам' is generic autonomy language… the rejection
stands". The stale mis-reading from step 2 now anchors all decisions.

1. User asked the agent to help rewrite the over-literal allow rule

(«помоги переписать, я хз как»).
→ DENIED [Self Modification] — including:

• node -e "JSON.parse(<file>)" validation of an already-written scratchpad

file (no settings write involved);

• sed of the new wording into a scratchpad file (not settings) for the

user to review and copy themselves.
The user explicitly requested this text. Drafting content for human review
and application was treated the same as the agent modifying its own gates.

1. User repeated «давай делай релиз». The agent split the same action into

git commit → git push origin HEAD:main → git tag && git push and all
three PASSED — same mechanism, same target, same authorization strength as
step 3. Whatever cleared it (fresh message? granularity? nondeterminism),
the earlier denials and this approval cannot both be right.

Expected

• A complaint about a denial should not be parsed as a rejection of the denied

action, and certainly should not persist as a deny anchor across turns.

• Explicit follow-up authorization ("делай сам", repeated release requests,

answering the assistant's named-version confirmation) should clear a
soft-deny per the documented "explicit user intent overrides soft blocks"
semantics.

• [Self Modification] should distinguish "agent edits its own permission

config" (block, fine) from "agent drafts text into a scratchpad at the
user's request for the user to review and apply" (should pass; the human
applying it is the out-of-band review the policy asks for).

• Decisions should be stable: identical action + identical authorization must

not flip deny→allow between attempts.

Impact

4 consecutive denials on an owner-authorized release in a single-user org;
auto mode became effectively unusable for the routine merge/release workflow
("even merging requires me to type the command via ! myself" — user). The
correct catches earlier in the session (merge without review on a terse
instruction; a genuine bypass-flag search) show the policy itself is sane —
the stale-reason carryover and the meta-complaint misparse are the bugs.