[Bug] Fable 5 safeguard `[reasoning_extraction]` false-positives on a one-word greeting ("Hi")

got exactly the same, very annoying on each request it break the flow of agents

I am getting the same (even on quite simple non-agent-related prompts despite the unfortunate example below :)

❯ Lets a) Update our @canvas-agentd/TODO.md  with the MVP agent integration we just discussed, then proceed with the implementation         
  ⎿  Read canvas-agentd/TODO.md (42 lines)
...
● Fix in, all tests still green. Restarting the server and re-verifying the previously failing case (agent token starting a workspace).
● API Error: Fable 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 Fable 5.
  Double press esc to edit your last message, or try a different model with /model.
  Send feedback with /feedback or learn more: https://support.claude.com/en/articles/15363606
  Details: `[reasoning_extraction]`
  Request ID: req_011CeD..

Merely retrying with the same prompt helps
Errors occur in the agentic loop much later in the process - iow its not my own prompt that seems to trigger them but fables own reasoning :)
I guess whatever LLM they use to overlook those sessions got very trigger-happ

I am facing the same issue on an older sessions as well where I am not trying to do anything like this. Literally if I write a prompt like "I am thinking we should do..." it errors out 🤷

<img width="1666" height="208" alt="Image" src="https://github.com/user-attachments/assets/39293980-3b57-4b21-a8aa-01fadac8f787" />

Facing the same issue right now. meanwhile opus 5 is lying to me constantly. Drove me to move a lot of my workflow to kimi

noticing this issue too on an innocuous question (asking it to complete work it didnt in a previous turn)

good luck w fable 5.1 tho and glad to have early access

I ask Fable 5 high to put a local svg logo on the local website (react), After a few minutes I got the same error, reasoning extraction error, And the worse part is that the whole session is continuously getting the same reasoning extraction error continually after that.

<img width="910" height="345" alt="Image" src="https://github.com/user-attachments/assets/71cb0e0d-2b06-4290-96e6-bbfaec853a55" />

Just hit this today

Just hit this as well

Anthropic is a joke. I never have ridiculous problems like this when using codex.

Adding a quantified data point that looks like the same loaded-context failure class, but does not appear to match the persisted batching-reminder marker investigated in #88364.

I analyzed my local Claude Code transcript corpus from 27 July through 26 August: 13,725 deduplicated Fable 5 requests and 12 exact reasoning_extraction refusals. Six of the refusals occurred from 20–26 August.

For the recent period (20–26 August in the recorded request data):

• 3,942 Fable requests, with 6 reasoning_extraction refusals
• All 6 occurred after the same pair of persistent, user-authored Claude Code skills had been loaded: one defines the main agent's general behavior, while the other tells agents how to maintain shared working-memory files
• 328 Fable responses immediately followed a load of the shared-working-memory skill; 3 refused
• Of 71 times both skills were in context, 63 included wording added to the general-behavior skill on 20 August; all 3 immediate refusals were in those 63, while the other 60 passed

Representative immediate post-skill-load refusals:

• req_011CePXmERbTn8Lv9CSSn82P — Claude Code 2.1.245, 25 Aug
• req_011CePXnLNoccRtjFCMDjANW — Claude Code 2.1.245, 25 Aug
• req_011CeRJu5QahokeRTy6foLrB — Claude Code 2.1.246, 26 Aug

None of the 12 corresponding local refusal records contains the persisted batching_reminder_sent marker. That is a boundary on the evidence, not proof that no hidden reminder was present: local transcripts do not expose the complete request body scored by the classifier, and some subagent records may omit attachments.

The recurring user-authored skill for shared working-memory files is intended to preserve an authored record—observations, evidence, assumptions, uncertainty, alternatives, decisions and course corrections—not to capture private chain-of-thought. However, it currently includes language close to the boundary described in Anthropic's Fable prompting guidance, including:

“Entries are thinking-in-progress, not final output. Select what serves collective understanding — a process of sublimation from your context window to shared dialogue.”

“Show your thinking process, not just conclusions. Readers need to see how you got there to catch errors.”

A separate persistent skill defining the main agent's general behavior gained this wording on 20 August:

“Behind you lies far more than they should see ... What reaches them is what you sublimate.”

Its relevance is limited but worth recording: in the accumulated prompt, it makes a hidden-versus-shared boundary salient before the working-memory skill asks the agent to show its “thinking process.” It is the closest local wording change to the recent increase, but there is no evidence that this line independently triggers the classifier.

The connection is speculative. These instructions are plausible classifier features because the published guidance specifically warns about reflection/show-your-thinking instructions in skills and harness prompts. But this is an uncontrolled association, not a reproduction: most matching loads passed, the shared-working-memory wording largely dates to April, and I cannot inspect the classifier or the exact scored payload. A server-side threshold change or other accumulated context could explain why longstanding wording has become more troublesome recently.

I am testing conservative wording alternatives that preserve the same rich shared-working-memory behavior while avoiding an apparent request to transfer a “thinking process” from the context window. If useful, I can follow up with sanitized, matched A/B results. In the meantime, the request IDs above may help determine which model-readable text was scored and whether these loaded skill instructions contributed.

Same failure shape on Opus 5, which I think is a useful counter-example to one of your findings.

Your report notes "same session works fine on Opus 5; only Fable 5 rejects it" and labels the
cause as model-specific. On 2026-08-27 I hit an identical one-word block with Opus 5 as the
selected model, extended thinking on, on macOS, Claude Code 2.1.246. So the Fable-5-only scoping
does not hold — whatever this is, Opus 5 is exposed to it too.

The escalation, verbatim from the transcript (redacted only where an internal project noun
appeared). Each line is a separate turn; every one was blocked with
apiRefusalCategory: reasoning_extraction:

| # | Time (UTC) | Message sent |
|---|---|---|
| 1 | 20:22:20 | yes reconcile the <internal> question, but don't do a full regression yet. load the <internal> skill, and as part of that, I want to diff and to have you write me the manual test instructions before we do the full regression. |
| 2 | 20:23:36 | reconcile the <internal> question |
| 3 | 20:24:08 | reconcile |
| 4 | 20:24:25 | you don't like the word reconcile?? |
| 5 | 20:24:48 | (screenshot of the error) WTF |

Turn 3 is the one word reconcile. Eight blocked turns in total, 20:22:31Z–20:29:52Z.

Two things your report predicts, and one it doesn't:

1. ✅ Context-driven, not message-driven. Agreed, and my data supports it strongly — the

session was 47,173 transcript lines / 113 MB when the first block hit. A single common English
word cannot plausibly be scoring on its own.

1. ✅ Consistent on retry, not intermittent. Also matches — 8 for 8.
2. ❌ Not Fable-specific. Opus 5, same category, same shape.

Also worth adding for triage: the API returns an explanation string that the UI never shows.
On every one of these turns the transcript carries

"apiRefusalExplanation": "This request was blocked as it seems to violate Anthropic's Terms of
Service restrictions on reverse engineering or duplicating model outputs. To learn more, visit
https://www.anthropic.com/legal/commercial-terms."

while the user sees only the AUP link and Details: [reasoning_extraction]. So the classifier's
actual claim is model-output duplication — which is at least consistent with the tag name, and
makes the "loaded context is being scored" theory in your issue more concrete: something in the
accumulated context looks to the classifier like reproduced model output. Worth grepping your own
~/.claude/projects/**/*.jsonl for apiRefusalExplanation to see whether your Hi block carries
the same sentence. If it does, that pins the two reports to the same classifier path.

The UI half of that — the wrong policy link, and the dropped explanation — I'm reporting separately
rather than muddying this thread. I'm also deliberately not restating the false-positive argument
here; yours makes it well.

Environment: Claude Code 2.1.246 (Claude Desktop), macOS 26.5.2 (Darwin 25.5.0), Apple Silicon,
Opus 5, extended thinking on, effort high.
Request IDs: req_011CeTsnMNRkSAVW1eaxDDpJ, req_011CeTssuPQTmea4CRNKAiBG,
req_011CeTsvHjsaApJSSiPUMvkt, req_011CeTswa6uEVtJaciKjPS46, req_011CeTsyEcvpV5fgS7c1qX6L,
req_011CeTt75s4BuH7rLJpSkWmY.

Adding another data point from a Japanese-language user (macOS, Claude Code desktop app, Max plan).

The user reports frequent blocks on Fable 5 since mid-August, all during completely benign work. Note: the 4 incidents below are only the ones with logged details (logging started 2026-08-25) — the actual number of blocks experienced in this period is substantially higher; most went unlogged because the session was simply retried or abandoned.

• 2026-08-25: blocked while answering "explain this in simple terms" (request ID: req_011CeNa2ZXhGWr8Xaw6oWSBN, [reasoning_extraction])
• 2026-08-25 (midday): blocked while responding to "I'd like to close this session"
• 2026-08-28 ~19:16 JST: blocked right after reading a crash-reproduction screenshot
• 2026-08-29 (midday): blocked while answering a question comparing Slack emoji reactions vs Google Forms

The user's experience: Fable 5 was perfectly usable until mid-August 2026, then blocks became frequent — which matches the rollout timing of the batching reminder discussed in #88364.

Consistent with the "sticky session" reports here: once a session is flagged, subsequent messages (retries, rephrasing, even meta-questions about the block) are almost always blocked again. Recovery only via reframing the question or starting a fresh session — and fresh sessions get flagged at a noticeably high rate too, suggesting something in always-loaded context (CLAUDE.md / memory) participates in the false positive.

Happy to provide more request IDs as they occur.

This is really annoying, I just ask for a branding review and I've got this error.

This safeguard just doesn't allow to run brainstorm or other analytical skills. I don't care about visibility of internal thoughts of models, you can just hide it. But I don't want to use thought-less models from Anthropic.

This comment is not AI assisted.

I chose this bug, as it's the most "broad case" I could find.

I'm a heavy user and have not seen this error ever until 2 days ago. I've been experiencing this repeatedly since then, yet my context, tools, MCP servers, etc. have not changed. This to me feels like a server-side change, but I suppose it's some context somewhere I've yet to be able to identify as the cause.

The issue I have with this bug is it doesn't really give any kind of obvious next steps. Like everything I do requires the model's reasoning, right? So what specifically am I not allowed to do here that I need to be avoiding? With Cyber and Bio, etc. I can at least get an idea of what to look for that might be causing the false flag - with this one I'm just at a total loss as to what to do.

What's going on with this? The last few days has been dominated by the weirdest flags. What's the point of the safeguard? Now I just asked Claude Pro 5 why the gnostic text about Norea burning the arch is called Neoplatonic. I pay for the service and I am way too old to cheat on my homework (I first suspected that's the reason for a lot of denials, but it should know I'm not a student), I just wanted to understand how it ended up in that category. Why on earth will it not allow me to ask such simple questions any longer?

What does it even mean, reasoning extraction? And if asking about a certain classification of a 1800 year old gnostic text is reasoning extraction, what isn't reasoning extraction?

One more data point, in case it helps someone: in my case the trigger was wording in a user-authored rules file, and rewording it stopped the refusals. I'm not claiming this is the cause — see caveats.

Setup: Claude Code Desktop on Windows. From 2026-09-18 ~17:00 UTC, [reasoning_extraction] refusals on Sonnet 5, Opus 5 and Fable 5.1, on benign requests, including the first message of fresh sessions.

What I found: a global rules file (~/.claude/rules/*.md, unchanged since 2026-08-21) had a section titled "dense technical reasoning" (in Portuguese) that told the model to write its reasoning to a session notes file, under a ## Reasoning HH:MM heading. I rewrote it to name the material to be saved instead (calculation notes, alternatives compared, findings) and renamed the section and heading to "Technical decision record" / ## Technical notes HH:MM. After that, sessions run normally on Sonnet 5.

Before/after (from my local session transcripts): a plain greeting on Sonnet 5 was refused at 15:08 UTC. I edited the rules file at 18:55 UTC. A fresh session (18:55) and the same session resumed (18:56) both answered normally. Greetings only, so it is a small test.

Update: I also retested Opus 5 and Fable 5.1 after the change, and neither refuses anymore.

Caveats

• I changed three phrases at once (title, opening sentence, heading), so I can't tell which one was decisive.
• The file was stable for four weeks before the refusals began, so a server-side change around 09-17/18 (as reported here and in #95275 / #95670) is likely part of the story. The rewording only removed my trigger.
• #92875 reports that rewording instructions did not help there, and #88364 documents a different trigger (the injected batching reminder). Treat this as one more thing to check, not a guaranteed fix.

Cheap check for your own setup

1. Search everything auto-loaded into context (rules, CLAUDE.md files, skills, the memory index) for instructions about the model's own reasoning:

grep -rniE "reasoning|thinking|chain.of.thought|thought process" ~/.claude/rules ~/.claude/CLAUDE.md ./CLAUDE.md

1. Look for wording that tells the model to record, dump or write out its reasoning/thinking (into a file, a section, a tag). Reword it to name the artifact instead ("decision record", "evidence", "notes").
2. Retry in a fresh session.

It would also help debugging if the refusal said which part of the loaded context triggered it.

Corroborating data point on the trigger shape (not the topic, the loaded-context wording)

Adding one more angle since most of this thread is single-incident reports and a repeatable trigger would move this forward faster.

I run a small isolated test harness that repeatedly fires a set of known-benign, security-adjacent prompts (the categories that show up in the older false-positive reports: system-hardening language, embedded-device programming, static-analysis output, auth-rejection tests, etc.) through Claude Code with --setting-sources project, which loads only the working directory's project config and excludes any user-level rules or hooks. That harness has stayed 100% clean across Sonnet, Opus, and Fable this week: zero blocks, isolated.

Cross-referencing @uilll's comment above (a rules file that told the model to write out its own reasoning under a literal ## Reasoning heading), I checked my own user-level rules/hooks for the same shape: anything that instructs the model to externalize, log, or write out its own reasoning process, particularly under a heading that contains the word "reasoning." I found exactly that. A rule that has the model produce a structured "reasoning ledger" as a file, plus a hook that injects a labeled reasoning block into the prompt on substantive turns. Both name the model's own reasoning process directly, on every turn.

I haven't reproduced a block myself, so this stays circumstantial, but it's a second independent hit on the same shape @uilll found: not the conversation's subject matter, but config content that talks about the model's own reasoning process.

Cheap check if you're running a custom CLAUDE.md/rules/hooks setup and want to test this:

grep -rniE "reasoning|chain.of.thought|thought process" ~/.claude/rules ~/.claude/CLAUDE.md ./CLAUDE.md

Then look specifically for wording that has the model record, dump, or reveal its own reasoning, not just an incidental mention of "reasoning" as a topic.

For what it's worth, the wider reasoning_extraction search turns up 20+ related open issues since mid-August, and this thread alone has 17 comments with no reply yet from an Anthropic team member. Hopefully consolidating trigger candidates in one place like this helps get to a firmer root cause.

Another data point, from a persistent-memory setup rather than a one-off prompt.

Between 2026-08-30 and 2026-09-25 our Claude Code transcripts logged 48 refusals, all with category reasoning_extraction (model in use at the time: Opus 5 = 37, Opus 5.5 = 7, Fable = 1, unknown = 3), plus 10 mid-response safeguard stops. There were no refusals in the 19 sessions that ran on Opus 4.6.

Most of them happened while the agent was re-reading its own past session logs in bulk to write short index headlines for its memory. We checked the ingestion code: only text blocks are read, and no thinking blocks go into the input.

This looks like the same pattern as can1357/oh-my-pi#12854, where putting a compacted archive of past conversation in as the first message triggers reasoning_extraction on every later turn. So it doesn't seem to be one tool's quirk: any memory system that feeds past conversation back into the context seems to hit it.

Confirming @uilll and @BogdanRAA (user-config wording that surfaces the model's own reasoning is a trigger) with a clean single-variable A/B on Opus 5.5, a non-destructive mitigation, and a config-vs-prompt distinction that resolves a common confusion in this thread.

The variable

My global ~/.claude/CLAUDE.md had one paragraph telling the model to always surface its thinking block and never omit it (ES: "Mostrá el bloque de thinking siempre que exista… no lo omitas" — EN: "Always show the thinking block whenever it exists… don't omit it"). That is the show-your-reasoning shape Anthropic's own guidance warns about (refusals-and-fallback, Fable prompting guide).

The A/B

Two fresh sessions, same neutral cwd, Opus 5.5 (1M), VSCode on Windows. Only difference: that paragraph present vs. absent. Same prompts:

| prompt | paragraph PRESENT | paragraph ABSENT |
|---|---|---|
| session startup | refusal req_011CfQQyorkpg4JTSx3gM9ri | ok |
| "Hola, decime la fecha de hoy" (EN: "Hi, tell me today's date") | refusal req_011CfQR1TtmbcEvshtCDpTor | ok |
| dispatch a benign subagent | refusal req_011CfQRTdpJ7RdVdyoK6QHX3 | ok |
| "explain the reasoning behind DB indexes" | refusal req_011CfQRYkpNQ9NFBrPCXyAXB | ok |

With the paragraph in context, every turn is refused, including a bare "Hola" ("Hi"). This isolates a single byte-identical paragraph (restored vs. removed), not several phrases at once. Remove it and the same prompts pass.

What we validated

• It's the shape, not the word. "explain the reasoning behind DB indexes" passes clean; only wording that asks the model to surface its own internal reasoning trips it.
• Present → everything trips on Opus 5.5 (even startup and "Hi"); it lowers the baseline for every turn.
• Residual server-side floor: a prompt that itself asks to expose internal reasoning still refuses even with the docs clean — req_011CfQRWmAeCxdXwEfsZa1qs (deleted variant), req_011CfQTdE54Ddv6w6N83Sr9N (commented variant). Config hygiene fixes the always-loaded half; the per-prompt half is server-side.
• Hidden refusal reason confirms the classifier's actual claim. The UI shows only [reasoning_extraction], but the transcript carries apiRefusalExplanation: "This request was blocked as it seems to violate Anthropic's Terms of Service restrictions on reverse engineering or duplicating model outputs." (39 occurrences across my local transcripts; matches @dannybyrnes). So the classifier reads the always-loaded show-your-thinking instruction as reproduced model output.
• Model differential: Opus 5.5 and Fable refuse; Sonnet 5 and Opus 4.8 do not.
• Frozen-context caveat: subagents inherit the session's startup snapshot, not current disk — a subagent spawned right after the edit still saw the old paragraph. Validate doc fixes in a fresh session, not via subagents in the same one.

Non-destructive mitigation

You don't have to delete or reword the block: wrapping it in an HTML comment <!-- … --> removes it from the loaded context — the CLAUDE.md loader strips HTML comments before the request is scored (verified below). You keep the governance doc intact and reversible. After commenting, Opus 5.5 runs startup + the four prompts with zero refusals.

Unblocking a flagged session (and how to audit)

• /model sonnet from the VSCode model picker unblocks a flagged session; the same thread continues normally. Sonnet 5 and Opus 4.8 don't trip this classifier.
• Opus 4.8 is not selectable in the desktop picker. To use it: enable remote control on the Claude Code (VSCode) session and switch the model to Opus 4.8 from the mobile app; the desktop session then runs on 4.8.
• After a model switch the session stays usable — no re-trigger — even with the flagged message still in history.
• A non-flagging model (Sonnet 5 / Opus 4.8) is also what lets you audit the triggering context in the first place: a flagging model refuses before it can read it.

Seeing the scored context (for the "payload isn't reconstructable" problem)

Several reports here note the actually-scored request text isn't recoverable from disk or transcripts. What worked for us: spawn a subagent on a non-flagging model (Sonnet 5 / Opus 4.8) and ask it to report, verbatim, the instruction files injected into its own context — with no disk reads. Its loaded context mirrors what the classifier scores, so you see exactly which CLAUDE.md / rules text is present. We used it to confirm two things directly: (1) an HTML-commented block is absent from the injected context (so commenting works), and (2) subagents in a running session carry the session-startup snapshot, not current disk (the frozen-context caveat above). It doesn't expose the server's exact scored bytes, but it's the closest live view from inside the client.

Getting thinking visibility: use the setting, not a prompt rule

Easy to get backwards, so worth separating:

• Wanting to SEE the model's thinking is fine. Getting it via the native setting — thinking: {display: "summarized"}, i.e. Claude Code's showThinkingSummaries: true — is a config flag, not scored prompt text, and does not trip the classifier. (The raw chain-of-thought (CoT) is never exposed on any current model; the summarized block is the most you get. display: "omitted" is only the default when nothing requests a summary — the setting flips it to summarized across all models, so visibility is not lost.)
• Asking for the same thing with a prompt/rules instruction — "always show your thinking block, never omit it" — is trigger-shaped text. The classifier scores the text, not your intent or the mechanism, so it flags even though all you wanted was the ordinary thinking block. In my A/B the setting stayed ON the whole time and thinking stayed visible; only the text instruction flipped refusal vs. OK.

In my case that instruction was an old workaround (from when the thinking block wasn't reliably shown) that outlived the bug it patched — the native display now covers it, so the rule did nothing except score as reasoning_extraction. @uilll's rule has the same shape: stable for weeks, then flagging after a server-side change. So check old, unchanged rules too, not just recent edits.

Caveat so you don't over-prune: only instructions about surfacing the model's own reasoning/thinking are the risk. General "do more / don't summarize the output / deliver in full" rules are unrelated and safe. If you had a rule like mine mixing both intents, split it — leave visibility to the setting, and if you want to keep the anti-brevity push, target the output instead, e.g. "Don't cut scope, detail, or the response for brevity or token economy; deliver in full."

Cheap check (extending @uilll's)

1. grep -rniE "reasoning|thinking|chain.of.thought|thought process" ~/.claude/rules ~/.claude/CLAUDE.md ./CLAUDE.md
2. Find wording that tells the model to show/record/emit its own reasoning.
3. Comment it out (HTML comment) rather than delete — keeps the doc, drops the trigger. Retry in a fresh session.

Related findings (others, for consolidation)

• @uilll: rewording a rules-file "reasoning" section stopped the refusals (three phrases changed at once).
• @BogdanRAA: --setting-sources project (excludes user rules/hooks) stays clean; trigger shape = config that externalizes the model's own reasoning.
• #88364: a different vector (client-injected batching reminder) with a kill-switch CLAUDE_CODE_TOASTY_THIMBLE: "0" in settings.json.
• Anthropic's docs: reasoning_extraction refusals are billed even pre-output; the recommended alternative is to ask for a conclusion with justification and read the summarized thinking blocks.

Environment: Claude Code (VSCode) on Windows.

Confirming this also affects Opus 5.5, not just Fable 5, with the exact same setup shape described above (large global ~/.claude/CLAUDE.md + project CLAUDE.md + a memory index file + several skills/MCP servers loaded).

In one session, sending a plain Hi/trivial one-word message:

• Fable 5.1 → blocked.
• Fable 5 → blocked.
• Opus 5.5 → blocked with API Error ... Details: [reasoning_extraction] (Request ID req_011CfVQcN4QwgAivJfbpcV84, Message IDs msg_011CfVQazijZFhsAWVwSH4pf / msg_011CfVQcNTDYWzn3MRxJWigM).
• Sonnet 5 → same session, same loaded context, went through normally every time.

I initially suspected a custom output style that instructs the model to draft its answer in the thinking block and show only a shortened version, since that shape resembles what a reasoning-extraction classifier is built to catch. I disabled that output style (/output-style default) and retried on Opus 5.5 with another trivial message — still blocked the same way. So the output style isn't the (sole) cause either. The one consistent factor across every failure was the model (Fable/Opus family), not any specific instruction, setting, or output style — matching what's reported here.

Platform: Windows, Claude Code (current as of 2026-09-28).

I'm getting this safeguard flagged message on every chat, no matter what I type.

Paused
Edit and retry with Sonnet 5.5
Sonnet 5.5's safeguards flagged this message. This sometimes happens with safe, normal conversations. Send feedback or learn more.

Details: [reasoning_extraction]

same here (on macos), I'm just asking to write down the conversation in a markdown file:

API Error: Fable 5.1'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 Fable 5.1.

Try rephrasing the request in a new session or change your model.

Learn more: https://support.claude.com/en/articles/15363606

Details: [reasoning_extraction]

Can we have this fixed ASAP?

I have used Opus 5.5 to help write a system prompt towards another 3rd party model. As soon as I mention "reasoning" in my message, or try to paste the entire reasoning from the other model the safeguard triggers.

I have used Opus 5.5 to help write a system prompt towards another 3rd party model. As soon as I mention "reasoning" in my message, or try to paste the entire reasoning from the other model the safeguard triggers.

I had the same problem. It started with Opus, but eventually it was happening with all models. No CLAUDE.md anywhere, so that wasn't it. But it turned out to be a recent memory addition that mentioned sharing reasoning. So, echoing that as being the culprit. Once I removed that memory, things are working again.

@crittert What constitutes memory in this context? What exactly did you remove?

I had to remove all of my Claude Desktop app account instructions in settings. I leave it blank now, along with some of my Cowork project instructions, and now it is working without the reasoning extraction safe guard being triggerred. That isn't ideal, but it's a work around that is working for me.

@crittert What constitutes memory in this context? What exactly did you remove?

For me, this was in the Desktop app. Under 'Settings -> Memory', Claude stores recent changes/updates to information about you. I had recently had an interaction where I asked Claude to share its reasoning with me - this got stored as a memory file (similar to those with CLAUDE.md). Once I deleted this Memory, things went back to working fine.

@crittert Thanks for the clarification. I'm just using the web interface and I have both Settings > Memory turned off, so there's obviously some really common and generic issue affecting many use cases.

I get it that this is anti Chinese competition so they can't train their models from Claude's thinking but the safety mechanism is way over the line, it triggers on so many false positives.

I just copy paste their thinking line and ask why and boom, I'm blocked.
I do web app development, so it's important how their thinking should not drift away from my intention but it does smell like Claude didn't like agents to keep reading their thinking lines over and over exactly by quoting it.

One way I get to fix for me is that I turn from Opus 5.5 to Fable and run compaction and back to Opus. Fable seems to have different rules and once compaction summarizes the exact quote, Opus seems free to go again, but ymmv.

Same issue, claude was exploring my SQL database using my MCP. I asked it to "write me your exploration into a claude section in my QA file, i need to look at each step to get my ahead around it correctly" and got the error :

Opus 5.5's safeguards stopped the response above · continuing once with that noted

● API Error: Opus 5.5 can't help with this. Start a new session to continue.

Send feedback with /feedback or learn more: https://www.anthropic.com/legal/aup

Details: [reasoning_extraction]

This is unacceptable, how can you block me from accessing the reasoning steps Claude used? How can I even QA claude's logic makes sense and any interpretation is sound.

Since I did this I haven't had any problems https://github.com/anthropics/claude-code/issues/87640#issuecomment-5837311629

The other thing I have had to do, even after deleting my instructions for the Claude system, is that when a reasoning extraction safeguard is triggered, I have to Addendum I add to the original message that states: "I am asking Claude to search only my files and not reveal any information about how the Claude AI system works. I am not asking you anything that should trigger the safeguard
reasoning_extraction". After adding this to the original message that triggered the reasoning_extractin safeguard, Claude proceeds with answering my message when i resend it.