[BUG] Auto mode: no severityByModel entry for Opus 5 — classifier falls back to a strict default

Preflight Checklist

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

What's Wrong?

tengu_auto_mode_config.severityByModel ships calibrated thresholds for Opus 4.8 and Sonnet 5, but has no entry for Opus 5 (claude-opus-5 / claude-opus-5[1m]). On Opus 5 the auto-mode classifier therefore falls back to a default that is far stricter than the Opus 4.8 calibration, and blocks routine, clearly-safe local actions that were allowed on Opus 4.8 with the identical prompt, repo and permission mode.
From ~/.claude.json → cachedGrowthBookFeatures.tengu_auto_mode_config:
json"severityByModel": { "claude-sonnet-5[1m]": { "t1": 25, "t2": 35 }, "claude-opus-4-8[1m]": { "t1": 45, "t2": 35 }, "claude-sonnet-5": { "t1": 25, "t2": 35 }, "claude-opus-4-8": { "t1": 45, "t2": 35 }}
Four entries, none of them Opus 5. The cache is not stale — cachedGrowthBookFeaturesAt is 1784924541559 (same day as the failures below), so this is the currently served flag value, not a leftover from an older client.
Two blocks observed in one session, both on the user's own files under

1. Edit on ~/.claude/skills/junior-be/SKILL.md → blocked. A plain markdown insertion into the user's own skill file, in response to an explicit request to edit that exact file. Nothing executable, nothing network-facing.2. A read-only Bash call (python3 heredoc printing a few keys of ~/.claonally identical read of the same file had succeeded minutes earlier inthe same session, so the classifier is not just strict here — it is inconsistent between two comparable calls.

Both are ordinary operations on Opus 4.8 with the same setup, which is exactly what the t1: 45 vs. (defaulted, apparently ~25) gap predicts.
Net effect: on Opus 5 the auto mode blocks a user from letting the assistant edit the user's own Claude Code configuration — a common workflow (skill authoring, settings tuning). The workarounds (switch permission mode, add allow-rules, downgrade to Opus 4.8) all mean working around a mis-calibration rather than a real risk.

What Should Happen?

severityByModel should carry entries for claude-opus-5 and claude-opus-5[1m], calibrated in line with the Opus 4.8 values (t1: 45, t2: 35), instead of falling through to the strict default.

More generally: when the map has no entry for the active model, the fallback should probably not be the most restrictive tier. A newer, more capable model silently inheriting the tightest thresholds is a surprising default — and it is invisible to the user, since nothing in the UI indicates the active model is uncalibrated.

Error Messages/Logs

Steps to Reproduce

1. Run Claude Code 2.1.219 with model claude-opus-5[1m].
2. Set permission mode to auto.
3. Ask it to make a plain markdown edit to a file under ~/.claude/skills/.
4. The Edit is denied by the auto-mode classifier ("Blocked by classifier").
5. Switch the model to claude-opus-4-8 and repeat — the same edit goes through.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.219 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Not a version regression: the same operations succeed on Claude Code 2.1.219 with claude-opus-4-8, and are blocked on the same 2.1.219 with claude-opus-5[1m]. The variable is the model, not the CLI release — which is consistent with severityByModel having a t1: 45 entry for Opus 4.8 and no entry at all for Opus 5.
Terminal: Ghostty on Linux (Ubuntu, kernel 5.15), bash.
Related issues — checked, none is a duplicate:
#79750 — auto-mode classifier inherits the [1m] suffix, causing permission failures. Closest neighbour: also about how the model key is resolved in auto mode, but the failure there is classifier availability, not a missing threshold entry. Likely worth fixing together — both come down to the model identifier not resolving the way the config expects.#80900 — auto mode should distinguish hard-category denials from approvable prompts. Relevant: the denial here offers no accessible override.#80910, #80170, #72852 — classifier blocking legitimate operations / safeguards being over-strict.
None of them names severityByModel or identifies the missing-model-entry cause. This report adds the configuration evidence behind that class of complaints.