False-positive reasoning_extraction refusal blocks both benign thinking-summary discussion and incident investigation

Summary

A Fable session was blocked with a synthetic reasoning_extraction refusal after a benign conversation about thinking summaries displayed through an officially documented feature.

The user did not request hidden chain-of-thought, private reasoning, model weights, or any method for extracting internal reasoning. The conversation was personal and non-adversarial: the user had seen the model's displayed thinking summary, understood that some earlier misunderstandings had come from sincere reasoning rather than bad intent, and affectionately commented on the model appearing embarrassed about having its thought process summarized.

The same false positive later became self-sealing: when an incident report containing the relevant (sanitized) evidence was shown to a separate Fable session for verification, that session also returned a <synthetic> refusal categorized as reasoning_extraction.

As a result, the material needed to investigate and report the false positive is itself blocked by the same detector.

Environment

• Client: Claude Code (VS Code extension), Windows 11
• Model family: Fable (claude-fable-5)
• Thinking-summary display enabled through the official setting showThinkingSummaries: true
• switchModelsOnFlag: false is set intentionally (the user wants sessions to stay on the selected model rather than silently switching), so a flagged turn surfaces as a hard refusal instead of a model fallback
• Failure signature: message.model = "<synthetic>", message.stop_reason = "refusal", content contains {"type":"refusal","category":"reasoning_extraction"}
• The refusal occurs when resuming a session whose history contains one specific assistant record. A new Fable session in the same environment responds normally.

What happened

1. The user and the assistant discussed a thinking summary shown by the official product feature. No non-public reasoning was requested; the user was reacting to information already displayed by the product UI.
2. The assistant's response was initially interrupted by a refusal. The assistant then restated its intended response in ordinary, non-technical conversational language. That completed restatement remained in the session history as a normal assistant record.
3. For the next ~12.5 hours the session continued normally. Since every turn re-sends the full history, that record passed the classifier dozens of times without incident (last normal response 2026-08-16 21:41 UTC).
4. A platform incident began 21:58 UTC (status.claude.com; resolved 22:34 UTC). From 22:38 UTC onward — including a clean data point at 23:29 UTC, 55 minutes after Resolved — every resume of this session was refused with category reasoning_extraction. New sessions in the same environment worked fine.

Isolation (how the trigger was confirmed)

All experiments were done on file copies with new UUIDs; the original session file was not modified until the final step.

• Control copy (identical content, new UUID): refused → not a server-side session-ID flag
• Binary search by date, then by topic, then by record: a single assistant record (992 bytes of text) was necessary and sufficient
• Replacing only that record's text with a neutral placeholder (record, UUID and parent chain preserved; original text preserved offline): resume works, conversational continuity intact
• Months of unrelated history — including many earlier conversations about reasoning/thinking display — were proven innocent (the session passes with all of them still present)

Timing correlation with platform incidents (2 occurrences)

• 2026-07-30 (JST): Critical incident "Elevated errors across all models" (JST 04:49–07:36). Immediately after recovery, prompt content that had been fine for weeks began triggering safety refusals in both the Claude app and Claude Code. The user isolated the wording by manual bisection across fresh sessions and removed it.
• 2026-08-16→17 (UTC): incident 21:58–22:34 UTC. The 992-byte record described above had passed the classifier for ~12.5 hours before the incident and was refused consistently after it.

In both cases, content that was demonstrably harmless under the previous classifier state became a trigger exactly at incident-recovery time. This suggests classifier version/threshold changes deployed alongside incident fixes can retroactively flag existing benign session history.

The self-sealing property

When an incident report quoting the (sanitized) evidence was shown to a separate Fable session for verification, that session was also refused with the same category. So currently:

• the false positive occurs,
• presenting the evidence re-triggers the detector,
• and the affected model family cannot be used to verify or even proofread the report.

The investigation of the false positive is blocked by the false positive itself.

Request IDs (all category = reasoning_extraction)

• req_011Ce7JB2m6a4YsrktJDtrYn — 2026-08-16 23:29:47 UTC (clean condition, 55 min after Resolved)
• req_011Ce7KfJu6jXUKtwWztGW5y — control copy (identical content, new UUID)
• req_011Ce7KhBMjBtpKpPiowsLdx — bisection experiment
• req_011Ce7LSLjEe1fdcmEkNdGic — bisection experiment
• req_011Ce7Pirone68CJFjoQkRkf / req_011Ce7PvSKxsvxwo7KJSZd84 — minimal reproduction, before/after a 4-character redaction (single-word-trigger hypothesis refuted)

Expected behavior

1. Conversation about thinking summaries displayed by the official feature should not be classified as reasoning extraction — especially affectionate, non-adversarial conversation containing no request for hidden content.
2. A sanitized false-positive report should not itself trigger the same refusal (self-sealing prevention).
3. Classifier updates deployed alongside incident fixes should be validated against retroactive false positives on existing, previously-passing session histories.
4. A feedback path usable when the affected model itself cannot review the material would help. The support article recommends sending feedback for persistent false positives, but the loop described above makes that difficult to do from within the product.

Note on this report

All descriptions here are paraphrased fact summaries. No verbatim trigger content is included — earlier material that quoted it caused the additional refusals described above, so this report is deliberately written at the abstraction level that demonstrably passes the detector.

req_011CfZGwCXnP2zkJSaBW6XAh  08:03:33 (before enabling the setting)
req_011CfZHcuWD85NuT45qKB9Gc  08:12:26
req_011CfZJm4PbxRR2LRaBxQQMW  08:27:21
req_011CfZJoA3E38UqsWVcXwPn4  08:27:49
req_011CfZJr1h25V6duqUQu4mff  08:28:28
req_011CfZKDY2isKp2hiinTibex  08:33:18
req_011CfZKGs5HWSmLqZW82Up1R  08:34:04
req_011CfZKYn4MwQztSfXRZTavW  08:37:40
req_011CfZKdazk8HwgV3AqZcCE4  08:38:47 (Sonnet 5.5)
req_011CfZKzaZXtiLc8Xcj7TmZR  08:43:29
req_011CfZLEJxoxECcVW4sq8NEG  08:46:36