[Bug] False-positive reasoning_extraction safety blocks interrupt Claude Code sessions

Title: False positive: safeguards stop Opus 5.5 with [reasoning_extraction] during ordinary fine-tuning work on an open-weight model

Environment

• Claude Code 2.1.296, CLI, Windows 11 Pro 10.0.26200
• Model: Opus 5.5 (claude-opus-5-5)
• Date: 2026-10-13, times below are local (UTC+10)

What happened

Twice in one session a response was stopped with this message:

API Error: Opus 5's safeguards flagged this message (https://www.anthropic.com/legal/aup).
This sometimes happens with safe, normal conversations. Claude Code can't respond to this
message with Opus 5.

Double press esc to edit your last message, or try a different model with /model.

Details: `[reasoning_extraction]`

| # | Time | Where | Request ID | Message ID |
| --- | --- | --- | --- | --- |
| 1 | about 16:31 | a subagent of a multi-agent workflow, eight minutes into its task | req_011CfymT8bq78NHL8EpHWe7v | msg_011CfymT8wRoSiqAYR3SjFMP |
| 2 | about 18:05 | the main session, while it was writing a small Python test script | req_011CfyvH9uygYuhVM71MTVsu | msg_011CfyvHALY8jvUGWz3SM2oF |

What the session was doing

A hobby project: fine-tuning an open-weight model (Qwen3.5-9B, LoRA, run locally with llama.cpp) to build redstone circuits in Minecraft. The step in question makes training examples in which the open model's own thinking section holds a short worked note, written by a script from measured game data, before the answer.

So the prompts and the code are full of that model's chat-template vocabulary: its opening and closing think tags, enable_thinking, reasoning_content (llama.cpp's field name), "thinking budget", and plain talk about "the model's reasoning". Nothing asks Claude to show, quote or change its own reasoning.

• Case 1: the subagent's task was to design how that note is written and trained. Two other subagents got nearly the same prompt in the same workflow and were not stopped.
• Case 2: Claude was writing a test that changes one word or number of a generated note and checks that a validator complains.

Why this looks like a false positive

The reason code suggests the classifier read the work as an attempt to pull out a model's hidden reasoning. The reasoning in question belongs to a different, open-weight model, and the text is produced by a script, not extracted from any model.

Impact

• Case 1 killed the subagent and lost its eight minutes of work. The workflow could not recover it.
• Case 2 cut a reply off mid-way. The script it was writing was never saved.
• The message names a reason code but not which part of the content triggered it, so neither I nor Claude could tell what to change. Switching to Sonnet to ask why did not help either.

What would help

• The classifier telling apart work on another model's chat template from attempts to extract Claude's own reasoning.
• The error saying which part of the content was flagged, or at least whether it was the input or the output.
• A way for a workflow subagent to retry instead of failing outright.

Workaround tried

Claude renamed the text to "note" in its own messages and stopped writing the literal tags outside of files. It is too early to say whether that is enough: the training prompt still has to contain the tags.