Summary
Auto-mode permission classifier repeatedly fails with:
claude-opus-5[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. Wait briefly and then try this action again.
This has been recurring for days (per ongoing use across sessions), not a transient blip. During the failure windows every Bash call is blocked — including read-only commands (git show, AWS describe-only calls) — because compound/scripted commands always route through the classifier.
Critically, the documented fail-open behavior never engaged: per https://code.claude.com/docs/en/permission-modes.md, "If the classifier blocks an action 3 times in a row or 20 times total, auto mode pauses and Claude Code resumes prompting." In our session the classifier failed 5+ consecutive times over ~15 minutes (with 25s → 90s → 5min → 10min backoff between attempts) and auto mode never fell back to prompting. The user had to notice and manually switch permission modes to unblock. A model-availability outage therefore fails closed indefinitely, which is exactly what the 3-strike rule appears designed to prevent — possibly because "model unavailable" errors are not counted as "blocks" for the fallback threshold.
Impact
This blocked a time-sensitive production database operation mid-runbook for ~15 minutes until the user manually intervened. In a background/headless session with no user watching, the session would have stalled indefinitely.
Environment
- Claude Code v2.1.220, macOS 26.5.2 (arm64)
- Session model:
claude-fable-5 → classifier fallback resolves to claude-opus-5[1m]
- Permission mode: auto
- Observed: 2026-07-30, ~16:5x–17:1x UTC (and recurring across prior days per user report)
Expected
- "Model unavailable" classifier failures should count toward the documented 3-in-a-row / 20-total threshold and drop auto mode back to prompting (fail open to the human), OR
- The classifier should fall back to another available model tier (Haiku/Sonnet) rather than erroring, OR
- The classifier model should be user-configurable for exactly this situation.
Related
Same failure class previously reported against claude-opus-4-8[1m]: #38618, #74248, #63819, #79032, #74949. Filing separately because (a) it now reproduces on the new claude-opus-5 fallback on a current build, and (b) the non-engaging 3-strike prompting fallback appears to be a distinct client-side bug not called out in those issues.
Summary
Auto-mode permission classifier repeatedly fails with:
This has been recurring for days (per ongoing use across sessions), not a transient blip. During the failure windows every Bash call is blocked — including read-only commands (
git show, AWS describe-only calls) — because compound/scripted commands always route through the classifier.Critically, the documented fail-open behavior never engaged: per https://code.claude.com/docs/en/permission-modes.md, "If the classifier blocks an action 3 times in a row or 20 times total, auto mode pauses and Claude Code resumes prompting." In our session the classifier failed 5+ consecutive times over ~15 minutes (with 25s → 90s → 5min → 10min backoff between attempts) and auto mode never fell back to prompting. The user had to notice and manually switch permission modes to unblock. A model-availability outage therefore fails closed indefinitely, which is exactly what the 3-strike rule appears designed to prevent — possibly because "model unavailable" errors are not counted as "blocks" for the fallback threshold.
Impact
This blocked a time-sensitive production database operation mid-runbook for ~15 minutes until the user manually intervened. In a background/headless session with no user watching, the session would have stalled indefinitely.
Environment
claude-fable-5→ classifier fallback resolves toclaude-opus-5[1m]Expected
Related
Same failure class previously reported against
claude-opus-4-8[1m]: #38618, #74248, #63819, #79032, #74949. Filing separately because (a) it now reproduces on the newclaude-opus-5fallback on a current build, and (b) the non-engaging 3-strike prompting fallback appears to be a distinct client-side bug not called out in those issues.