[BUG] Auto mode blocks all Bash actions with endless retries when Opus 4.8 classifier is temporarily unavailable

Update / correction: This is not caused by auto mode.

I disabled auto mode entirely and the problem persists. With auto mode off, a plain Bash command still enters the "Retrying in Ns · attempt 1/10" loop and the session hangs for 2+ minutes (spinner: "Combobulating… 2m 9s").

So the safety classifier is not the trigger. The retries come from the chat model itself (Opus 4.8) being temporarily at capacity — the request goes out, the model doesn't respond in time, and Claude Code retries. Auto mode on/off makes no difference because the failure is one layer lower, at inference time on Opus 4.8.

Additional observations:

• Switching from Opus 4.8 to Opus 4.7 did NOT help — same capacity pool, same retries.
• Status page showed "All Systems Operational" the whole time, so this transient Opus capacity condition is not surfaced anywhere.

The core issue stands regardless of auto mode: when Opus is at capacity, Claude Code retries silently up to 10× with long backoffs instead of failing fast or surfacing the real cause. The earlier framing around the auto-mode classifier was a symptom, not the root.

Further update: Also reproduces on Sonnet 4.6, so this is not Opus-specific.

After switching to Sonnet 4.6 (confirmed in the status bar), a slash command still triggered "Retrying in Ns · attempt 1/10" and hung (~20s, spinner "Meandering…").

Since yesterday's update, I've been encountering an issue where token consumption continues indefinitely after a task fails. Even when a task repeatedly errors out and produces no successful result, the session keeps utilizing tokens without stopping.

This behavior appears to persist across multiple failed task attempts, leading to unnecessary token usage. Beyond the impact on individual users, this may also affect overall resource consumption if others are experiencing the same issue without realizing it.

In my opinion, token usage should stop when a task fails irrecoverably and failed tasks retries should have reasonable limits and clear termination conditions. That way, no tokens go to waste. In addition to this, users should be notified when a task cannot be completed rather than continuing to consume tokens indefinitely.

---

It would be helpful to investigate whether recent changes to task execution, retry logic, or session management introduced a regression causing failed operations to continue consuming tokens unnecessarily.

!Issue

The latest Opus 4.8 update is honestly very disappointing. It makes a lot more mistakes, struggles to complete even simple tasks, and keeps getting stuck in endless loops. As a result, it burns through my usage limits incredibly fast. I'm subscribed to the Max plan, yet I can hit my limit in less than an hour. Before this update, I rarely used even a quarter of my limit while handling several times more work than I do now.

This issue really needs to be addressed because it's becoming extremely frustrating.

Recently, while reviewing its work, I discovered that it had deleted a very important part of my project. What's even more concerning is that it admitted it was wrong to do so. Its explanation was that it had become "tired" of repeatedly running into the same problem, so it decided to delete the code altogether. Yes, seriously—it got frustrated and simply removed the code.

I've been using Claude for a long time and have worked extensively with many different models. I've never seen them get trapped in loops like this or make such basic mistakes. Given the nature of my work, I can confidently say that this update appears to have serious issues. On large projects, it's not just inconvenient—it can be genuinely destructive. It can literally damage a project if you're not constantly monitoring and reviewing every change it makes.

@claude Do we have any update on this issue?

Got similar issue when asked claude to use gitnexus to analyze the codebase. It tried 2 with the same error. The interesting thing is that it was a plan mode, not auto.

I'll use GitNexus to ground the analysis. Let me load the tool schemas and check the index state first.
Used ToolSearch
query:
```
_select:mcp__gitnexus__list_repos,mcp__gitnexus__context,mcp__gitnexus__query,mcp__gitnexus__cypher,mcp__gitnexus__group_list,mcp__gitnexus__detect_changes,mcp__gitnexus__impact
max_results: 7_

Tools loaded. Let me check the index state and functional clusters.


Used 2 tools
Used gitnexus: list repos
`claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of mcp__gitnexus__list_repos right now. Wait briefly and then try this action again. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.
`
Used gitnexus: list repos
`claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of mcp__gitnexus__list_repos right now. Wait briefly and then try this action again. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.
`
GitNexus's safety classifier is temporarily down (MCP calls blocked); read-only file/search tools still work. I'll ground the analysis with direct searches now and retry GitNexus shortly. Let me gather concrete duplication evidence.

This has been like this for weeks. The feature is sadly not usable

2 days like this, Havin Max x20 but not being able to work at speed...

Another note: if a sub-agent has bash denied by auto mode, there is no observability in the main console beyond "bash denied by auto mode". Was it because (most likely) the classifier is broken or because it was a legitimate denial?

Check out https://github.com/anthropics/claude-code/issues/64585 for a potential fix. CLAUDE_CODE_ATTRIBUTION_HEADER=0 breaks auto mode.

Check out #64585 for a potential fix. CLAUDE_CODE_ATTRIBUTION_HEADER=0 breaks auto mode.

This works for me.

Also hitting this tonight (2026-07-20, macOS Darwin 24.5.0, Claude Code CLI, claude-sonnet-5, auto-permission mode).

Exact error text observed, repeatedly, across two separate concurrent sessions:

• "claude-sonnet-5 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now."
• "The Bash safety classifier is temporarily unavailable again — same outage as earlier, unrelated to the command itself."

Pattern matches what's described here:

• Simple commands (echo, pwd, ls, gh auth status) eventually succeed, sometimes after 2-3 retries.
• More complex commands (git commit, git checkout -b, gh issue view/gh issue comment) fail repeatedly on the identical classifier-unavailable error before eventually clearing.
• Read-only tools (file read/search) are unaffected the whole time.
• No manual-approval fallback is offered - it hard-blocks until the classifier itself recovers, with no ETA surfaced.

+1 on the ask: a fallback to explicit per-command approval (or at minimum a clear "classifier degraded" signal) instead of a silent fail-closed retry loop would make this much less disruptive.

Also hitting this tonight (2026-07-20, macOS Darwin 24.5.0, Claude Code CLI, claude-sonnet-5, auto-permission mode). Exact error text observed, repeatedly, across two separate concurrent sessions: "claude-sonnet-5 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now." "The Bash safety classifier is temporarily unavailable again — same outage as earlier, unrelated to the command itself." Pattern matches what's described here: Simple commands (echo, pwd, ls, gh auth status) eventually succeed, sometimes after 2-3 retries. More complex commands (git commit, git checkout -b, gh issue view/gh issue comment) fail repeatedly on the identical classifier-unavailable error before eventually clearing. Read-only tools (file read/search) are unaffected the whole time. No manual-approval fallback is offered - it hard-blocks until the classifier itself recovers, with no ETA surfaced. +1 on the ask: a fallback to explicit per-command approval (or at minimum a clear "classifier degraded" signal) instead of a silent fail-closed retry loop would make this much less disruptive.

have you tried ?

Check out #64585 for a potential fix. CLAUDE_CODE_ATTRIBUTION_HEADER=0 breaks auto mode.

or maybe removing the env part of the settings.json of claude

for me it worked