[BUG] Auto mode safety classifier uses claude-sonnet-4-6[1m] when Opus 4.6 1M is selected, causing Bash to fail when Sonnet 1M is unavailable

[pkohei]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When using Opus 4.6 with 1M context (claude-opus-4-6[1m]) as the selected model, enabling auto mode causes all Bash tool calls to fail immediately with the following error:

Error: claude-sonnet-4-6[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash 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. (hasExtraBody=false)

The error message reveals that the auto mode safety classifier is attempting to use claude-sonnet-4-6[1m] (Sonnet with 1M context) rather than the user-selected model. The bug appears to be that the classifier switches from Opus to Sonnet but incorrectly inherits the [1m] context suffix. When claude-sonnet-4-6[1m] is unavailable (even though claude-opus-4-6[1m] is available), every Bash command fails.

Switching the active model from Opus 4.6 1M to Sonnet 4.6 (without the 1M suffix) resolves the issue, which confirms the root cause is the classifier receiving an unavailable model ID.

What Should Happen?

Auto mode's safety classifier should either:

1. Use the user-selected model (claude-opus-4-6[1m]) for classification, or
2. Use a standard Sonnet model without inheriting the [1m] context suffix (e.g., claude-sonnet-4-6 instead of claude-sonnet-4-6[1m])

Bash tool calls in auto mode should succeed as long as the user's selected model is available.

Error Messages/Logs

Error: claude-sonnet-4-6[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash 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. (hasExtraBody=false)

Steps to Reproduce

1. Set the model to Opus 4.6 with 1M context: /model → select claude-opus-4-6[1m]
2. Enable auto mode (Shift+Tab or defaultMode: "auto" in settings)
3. Attempt any task that requires a Bash tool call (e.g., run a shell command)
4. Observe the error — auto mode classifier tries claude-sonnet-4-6[1m] which is unavailable

Workaround: Switch to Sonnet 4.6 (non-1M) via /model, which allows the classifier to function correctly.

Claude Model

Opus (with 1M context)

Is this a regression?

I don't know

Claude Code Version

2.1.81 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

• The ~/.claude.json config shows twoStageClassifier: true, confirming a two-stage classifier is in use
• The classifier appears to copy the context suffix ([1m]) from the user-selected model when switching to Sonnet, resulting in an invalid/unavailable model ID
• Read-only operations (file reads, code search) are unaffected, as stated in the error message — only Bash execution is blocked
• Related issues: auto mode temporarily unavailable - cannot enter auto mode via Shift+Tab or defaultMode setting for Max user #33587, [BUG] Auto mode temporarily unavailable on macOS - persists across restarts (v2.1.80) #36483 (auto mode unavailable, different root cause)

[yurukusa]

Nice root cause analysis. The [1m] suffix being passed through to the classifier model ID is clearly the bug — the classifier should strip context-window variants before selecting its model.
Additional workaround if you want to keep using Opus 4.6 1M without auto mode:
Switch to default permission mode and use PreToolUse hooks for safety instead of the auto-mode classifier:

"defaultMode": "default"

Then add hooks to auto-approve commands you trust:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "bash -c 'CMD=$(cat | jq -r .tool_input.command); if echo \"$CMD\" | grep -qE \"^(git |npm |cat |ls |grep |find |head |tail |wc |echo |pwd |date )\"; then echo \"{\\\"hookSpecificOutput\\\":{\\\"hookEventName\\\":\\\"PreToolUse\\\",\\\"permissionDecision\\\":\\\"allow\\\",\\\"permissionDecisionReason\\\":\\\"Safe read/build command\\\"}}\"; fi'"
      }]
    }]
  }
}

This gives you the same safety-check-then-approve flow as auto mode, but runs locally against your own rules instead of calling a classifier model. No model availability dependency.

[Maxymvs]

100% having the same issues and been unable to use auto mode bcause of this

[mr13tech]

Also got the same issue;

[danmana]

I investigated this with Claude Code by downloading the npm package (@anthropic-ai/claude-code@2.1.84), formatting cli.js with prettier, and tracing the classifier model selection logic.

Root Cause

The classifier model is selected by a function (minified as UEq in 2.1.84) that works like this:

function getClassifierModel() {
  let config = getFeatureFlag("tengu_auto_mode_config", {});
  if (config?.model) return config.model;       // server-side override
  let currentModel = getCurrentModel();          // e.g. "claude-opus-4-6[1m]"
  if (is1MModel(currentModel)) return "claude-sonnet-4-6[1m]";  // ← BUG
  return "claude-sonnet-4-6";
}

The is1MModel() check simply tests /\[1m\]/i against the current model string. When you're on claude-opus-4-6[1m], it matches, so the classifier gets "claude-sonnet-4-6[1m]" — a model that isn't currently available via the API. The two constants are hardcoded:

CLASSIFIER_MODEL = "claude-sonnet-4-6";
CLASSIFIER_MODEL_1M = "claude-sonnet-4-6[1m]";  // not yet available

The fix would be to fall back to "claude-sonnet-4-6" when the 1M variant is unavailable, rather than failing the classifier entirely.

There's no env var or local setting to override the classifier model — the only override is a server-side feature flag (tengu_auto_mode_config.model).

Workaround: Binary Patch (use at your own risk)

⚠️ IMPORTANT: This is probably a bad idea. You're modifying a signed binary, it will break on every update, the minified variable names will change between versions, and you're on your own if something goes wrong. Make a backup first.

Note: This patch forces the classifier to use claude-sonnet-4-6 (200k context). If the classifier prompt ever grows beyond 200k tokens, this could cause failures where the 1M variant would have worked.

For the compiled binary install (macOS arm64, version 2.1.84), the JS assignment j4$="claude-sonnet-4-6[1m]" appears twice in the embedded source. You can patch it and re-codesign:

# Backup
cp ~/.local/share/claude/versions/2.1.84 ~/.local/share/claude/versions/2.1.84.bak

# Patch (2 JS source occurrences — variable name is version-specific!)
python3 -c "
path = '$HOME/.local/share/claude/versions/2.1.84'
data = open(path, 'rb').read()
old = b'j4\$=\"claude-sonnet-4-6[1m]\"'
new = b'j4\$=\"claude-sonnet-4-6\"    '
count = data.count(old)
assert count == 2, f'Expected 2, found {count}'
data = data.replace(old, new)
open(path, 'wb').write(data)
print(f'Patched {count} occurrences.')
"

# Re-codesign (required on macOS — modified binaries get SIGKILL'd otherwise)
codesign --force --sign - ~/.local/share/claude/versions/2.1.84

# Restore if needed:
# cp ~/.local/share/claude/versions/2.1.84.bak ~/.local/share/claude/versions/2.1.84

[alanmarcero]

Any chance we can get this in? I'm not able to use auto mode with Opus 1M @bcherny

[stan-sarama]

Confirmed that this above fix actually fixed the problem on my system

[danmana]

Update: The patch is no longer necessary. Anthropic has fixed this server-side via the tengu_auto_mode_config GrowthBook feature flag.

Inspecting ~/.claude.json → cachedGrowthBookFeatures shows:

"tengu_auto_mode_config": {
  "enabled": "opt-in",
  "twoStageClassifier": true,
  "model": "claude-opus-4-6[1m]"
}

The model field overrides the hardcoded classifier model selection (the buggy getClassifierModel() function from my earlier comment), so the broken claude-sonnet-4-6[1m] constant is never reached. Interestingly, they switched the classifier to Opus 4.6 1M rather than Sonnet.

If you applied the binary patch from my earlier comment, you can safely restore from backup.

[Nick-Hopps]

same problem, but mine is "Error: claude-opus-4-6[1m] is temporarily unavailable"

[DavidPluxia]

Seeing the same bug pattern with Opus 4.7 (claude-opus-4-7) on 2026-04-16 — suggests the GrowthBook tengu_auto_mode_config.model override still points at an Opus variant that can go unavailable, just a newer one now.

Exact error from attempting a Write:

Error: claude-opus-4-7 is temporarily unavailable, so auto mode cannot determine the safety of Write 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.

Platform: darwin (macOS). Session model: Opus 4.7.

The underlying design issue from the OP is unresolved: any single-model classifier selection is a single point of failure for auto mode. A fallback to claude-sonnet-4-6 (or the current non-1M Sonnet) when the primary classifier model is unavailable would eliminate this class of outage entirely, rather than patching the GrowthBook flag every time a new flagship model ships.