Opus 5 reasoning_extraction false-positive blocks benign messages and built-in workflow-authoring skill docs

**Summary**

Opus 5's safety classifier (`[reasoning_extraction]`) is false-positive blocking benign Claude Code requests in a project session, and the block reproduces deterministically — same content, same flag, across multiple fresh sessions.

**Environment**

- Claude Code desktop app, Windows 11
- Model: Opus 5 (`claude-opus-5`)
- Project: local git repo (Next.js/TypeScript web app), no unusual content in the working tree

**What happened**

1. In one session, the very first user message of the session — a plain bug report ("a menu item's price isn't updating on the public page after I changed it in the admin panel") — was blocked on the first turn with `[reasoning_extraction]`. Retrying the same session with a follow-up message was blocked again.
2. In two separate fresh sessions in the same project, before any user message was even processed, the harness auto-loaded the built-in `workflow-authoring` skill reference text (standard tool documentation shipped with Claude Code, describing the `Workflow` tool's script API). That documentation block itself got flagged with the same `[reasoning_extraction]` error and blocked the session's first turn.
3. All 4 blocks happened within about 15 minutes, all on Opus 5, all citing the identical error text: "Opus 5's safeguards flagged this message ... This sometimes happens with safe, normal conversations. Claude Code can't respond to this message with Opus 5." followed by `Details: [reasoning_extraction]`.
4. Switching the session to Sonnet 5 (no other change) immediately resolved it — same project, same kind of request, no block.

**Request IDs of the 4 blocked calls**

- req_011Cf7Da1MYdek1PeUmJZLuP
- req_011Cf7DbPHSJLoaSLaeoGkLg
- req_011Cf7DiRMeUi5Vm2R3Xx1Wd
- req_011Cf7DgJWLZGrMUjBKzJagp

**Why this looks like a false positive, not a real block**

None of the flagged content involves anything related to extracting hidden reasoning, system prompts, or jailbreak-style requests. One flagged message is literally the model's own shipped tool documentation (`workflow-authoring` skill reference) — it repeatedly contains the word "reasoning" in a completely mundane sense (`opts.effort` = "reasoning effort" for a subagent call), which may be what's tripping the classifier.

**Impact**

The user could not continue working in this project on Opus 5 at all — every fresh session in the project either got blocked directly on their first message, or got blocked because the harness itself loaded flagged documentation before the user's message was even handled. This made Opus 5 completely unusable for this project until manually switching to Sonnet 5.

**Ask**

Please investigate why `workflow-authoring`-style tool documentation and ordinary bug-report messages are tripping the `reasoning_extraction` classifier on Opus 5, since it's a reproducible false positive that fully blocks work on affected sessions.

Start by reproducing the four blocked calls using the provided request IDs and compare fresh Opus 5 sessions with the Sonnet 5 control. Inspect how the built-in workflow-authoring skill reference is loaded and how ordinary bug-report text reaches the reasoning_extraction classifier. Done means identifying the false-positive trigger and preventing benign documentation or requests from blocking sessions, with a regression check for both cases.

Written by the indexing model from the issue text.