Auto-escalation to retired claude-opus-4-8 on false-positive risk classification breaks turn / creates unrecoverable loop

Description

After today's update to 2.1.219, an internal auto-escalation mechanism is force-switching my session model to claude-opus-4-8 whenever it perceives a security/risk-related topic in the conversation — even on false positives. The problem is that claude-opus-4-8 appears to no longer be reachable now that claude-opus-5 has succeeded it, so every escalation just breaks the turn.

I inspected ~/.claude.json and found these (presumably server-synced) flags enabled:

"tengu_velvet_hammer_opus_4_8": true,
"tengu_auto_mode_classifier_queue": true,
"tengu_auto_mode_config": {
  "enabled": "enabled",
  "twoStageClassifier": true,
  "severityByModel": {
    "claude-opus-4-8": { "t1": 45, "t2": 35 },
    "claude-sonnet-5": { "t1": 25, "t2": 35 }
  }
}

This looks like a risk classifier that escalates the active model to claude-opus-4-8 once a turn's risk score crosses a threshold — overriding my configured default model (sonnet in settings.json). As far as I can tell, opus-4-8 was specifically chosen as the escalation target because it was noticeably less strict about security-related false positives than opus-5, sonnet-5, or fable-5, which all seem to apply the same or a stricter classifier. In my experience since today's update, opus-4-8 no longer works when this escalation fires post-Opus-5, which means there is effectively no model left in the lineup that's lenient enough to process content the classifier false-flags — every other available model applies the same restriction, so the escalation just fails instead of landing anywhere usable.

Why I'm stuck

My Claude Code auto-memory (~/.claude/projects/.../memory/) has legitimate entries about CTF competitions (I do authorized security research/CTF work). Now, any turn that touches or even references that memory content gets classified as risky, triggers the escalation to the dead opus-4-8, and the turn fails. Worse, this also happens unpredictably on turns that are working on content completely unrelated to and unconnected from any of that — ordinary, safe requests still occasionally get misclassified and hit the same escalation.

I tried asking Claude to clean up / delete the memory entries that seem to be causing these false positives, but simply asking it to identify and remove them re-triggers the same escalation to the dead opus-4-8 — so the cleanup request itself fails the same way. I'm stuck in a loop: the only way to fix the false-positive-flagged content requires the model to process a request about it, and that request is exactly what gets blocked, every time.

Expected behavior

• I understand the false-positive rate on this risk classifier may be inherently high, and I'm not necessarily asking for the classifier itself to be more lenient. But even so, there should always be at least one working model left available to handle content that gets flagged as a security-risk false positive — right now the escalation target (claude-opus-4-8) no longer works for me, and the result is a full hard block with no model at all able to process the turn. A false positive should degrade to a usable (even restricted) model, not a dead end.
• Legitimate CTF/security-research discussion (already a supported use case per Claude Code's own system instructions, which explicitly allow "authorized security testing, defensive security, CTF challenges") should not be misclassified as high-risk on ordinary turns.
• There should be a way to disable or reset this escalation behavior client-side (currently, editing the tengu_* flags in ~/.claude.json doesn't help since they appear to be re-synced from the backend).

Environment

• Claude Code version: 2.1.219 (updated today)
• Plan: Claude Max 20x
• OS: Linux (Arch)