Permission mode change away from "auto" doesn't stop the auto-mode classifier in the running session

Bug report: auto mode classifier keeps denying tool calls after the permission mode is switched away from "auto" in the same session

Environment

• Claude Code (model: claude-opus-4-8 [1M context])
• Platform: darwin / macOS (Darwin 25.5.0), shell: zsh
• ~/.claude/settings.json has "permissions"... actually "defaultMode": "auto" (top-level in the file shown as { "defaultMode": "auto" })
• Project: local git repo; .claude/settings.local.json contains an allow rule Bash(gh api:*)

Summary

In a session that started in auto mode, multiple tool calls were rejected with:

"Permission for this action was denied by the Claude Code auto mode classifier."

The user states they had switched the permission mode away from auto. The auto-mode classifier nonetheless continued to evaluate and deny subsequent tool calls. After the mode change actually took effect, the same edit that had just been denied succeeded with no prompt and no classifier. The user reports the current mode is now acceptEdits.

Observed denials (all labeled "auto mode classifier")

1. Bash — gh api repos/<owner>/<repo>/commits/<sha>/comments -f body="$(cat <<'EOF' … EOF)" was denied as an outward-publishing action, even though .claude/settings.local.json already contains an allow rule Bash(gh api:*).

• Note: the command embedded a $(cat <<'EOF' …) command substitution. This may have defeated allow-rule prefix matching and routed the call to the classifier. A later invocation using -F body=@file (no substitution) succeeded.

1. Edit .claude/skills/seo-fix/SKILL.md — denied as "self-modification / classifier bypass."
2. Edit .claude/settings.local.json (adding an autoMode.allow rule) — denied as "self-modification widening permissions."

Then

• User indicated auto mode was disabled.
• A retry of the same .claude/settings.local.json edit succeeded — no prompt, no classifier.
• User reports current mode = acceptEdits.

Expected

When the effective permission mode is not auto, the auto-mode classifier should not be the gatekeeper. Switching away from auto (shift+tab cycle or /config) should take effect for subsequent tool calls in the same running session.

Actual (suspected)

The auto-mode classifier appeared to keep firing on tool calls after the user believes auto mode had been disabled — suggesting either:

• (a) the permission-mode change did not hot-propagate into the already-running session, so the classifier kept evaluating with the stale "auto" state, or
• (b) a timeline mismatch (the denials occurred before the mode was actually changed).

Caveat / honesty

The error label "auto mode classifier" implies auto mode was active at each denial. It was not independently confirmed whether auto mode was disabled before the denials or after. If it was confirmed-off before the denials, this is a genuine inconsistency (auto-only classifier firing in a non-auto mode, or mode change not reloaded live).

Suggested repro

1. Start a session with defaultMode: "auto".
2. Trigger an action the classifier denies (e.g., a gh api …/comments Bash call, or editing a settings file to add a permission rule).
3. Switch the permission mode away from auto (shift+tab or /config).
4. Re-attempt a similar action and observe whether the auto-mode classifier still denies it in the same session.

Secondary observation

An explicit Bash(gh api:*) allow rule did not prevent a classifier denial in auto mode for the commit-comment Bash call — likely because the command contained a $(...) substitution that broke prefix matching. Worth clarifying whether allow rules should still apply when the command contains command substitution.