[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

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.

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

Also got the same issue;

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

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

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

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.

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

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.

literally unusable. how can my opus burn through tokens if it gets blocked every single turn?

The opus-4-6 and opus-4-7 unavailable errors should be fixed in Claude Code v2.1.112.

Reproduced on Claude Code v2.1.112 — the version @shawnm-anthropic stated should fix this — so the regression is not fully resolved.

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

Then on the next turn, a Bash call for claude --version was also blocked with the same claude-opus-4-7 is temporarily unavailable message — only when I retried did Bash succeed.

• Claude Code: 2.1.112
• Session model: Opus 4.7 (claude-opus-4-7[1m], 1M context shown in environment)
• Platform: darwin (macOS 25.3.0)
• Auto mode: enabled
• Tools blocked: Edit, then Bash on the immediate retry

Notably, the previously-working text in the OP and earlier comments was about claude-sonnet-4-6[1m] / claude-opus-4-6[1m]. Here the classifier model name in the error message is the plain claude-opus-4-7 (no [1m] suffix), which suggests the GrowthBook tengu_auto_mode_config.model flag has been bumped to claude-opus-4-7, but that target itself becomes intermittently unavailable and there is still no fallback path.

The architectural concern from earlier comments stands: pinning the safety classifier to a single flagship model means every transient capacity issue on that model takes auto mode offline globally. A graceful fallback (e.g., claude-opus-4-7 → claude-sonnet-4-6 → static allow-list for safe verbs) would prevent the next recurrence the next time a flagship model has a hiccup.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.