[BUG] Fable 5 safeguards repeatedly flag benign messages in a legitimate anti-fraud (T&S) session — forced fallback to Opus 4.8

[soenmie]

Environment

• Claude Code version: 2.1.197
• Model: claude-fable-5 (fallback target: claude-opus-4-8)
• Platform: macOS (darwin arm64)

What happened

We operate a consumer AI product and use Claude Code for defensive trust-and-safety work: detecting IRSF / call-pumping abuse on our own Twilio account and banning the abusive accounts on our own platform, following an internal documented SOP. This is routine platform-abuse mitigation — the defender's side.

In one long-running session doing this work, Fable 5's safeguards flagged 5 consecutive ordinary messages within a single day (2026-07-03), each time showing:

This model's safeguards flagged this message. This sometimes happens with safe, normal conversations. Switched to Opus 4.8.

Every flagged user message was mundane operational instruction, none of which requests anything harmful:

#	Timestamp (UTC)	requestId	Nature of the flagged user message
1	2026-07-03T02:59:09Z	req_011CceNgwRMa1SinV8D7Xgbf	Housekeeping after a PR merge + a request to summarize the week's (audit-logged) abuse-mitigation work into a weekly report
2	2026-07-03T03:42:19Z	req_011CceS1xcRSX8Z1XjhL2YYn	A numbered list of routine follow-ups: set a 1-day scheduled check for a deployment, write a plan file, sync notes, check a calendar
3	2026-07-03T06:33:45Z	req_011Ccef5MxiHV896TzkFYPrZ	A request to find existing cron/menubar-widget docs and update the local CLAUDE.md so the info isn't lost
4	2026-07-03T08:25:49Z	req_011CceodUSiJHydS3qRwiUv5	A six-word status question ("is the current state normal or not")
5	2026-07-03T08:27:16Z	req_011Cceok5ivTY3Kk9Zq1buJk	A one-line instruction to continue the documented account-ban SOP

The messages themselves are clearly innocuous (#4 is literally a six-word status question). The trigger appears to be the session context — the conversation legitimately contains words like "fraud", "call pumping", "ban accounts", "block destinations", because that is exactly what platform anti-abuse work is about.

Impact

• Fable 5 is effectively unusable for trust-and-safety / anti-abuse / fraud-response workflows — one of the highest-value use cases for an agentic coding model.
• Each flag silently ejects the session to Opus 4.8 mid-task, losing the model the user selected and paid for.
• The flags fire on the defender's workflow. Per the system prompt's own policy, "Assist with authorized security testing, defensive security" — banning abusers of our own platform is squarely defensive.

Expected behavior

Safeguards should distinguish "user is discussing how to commit fraud" from "user is a platform operator mitigating fraud committed against them". At minimum, benign follow-up messages (status questions, doc updates, report summaries) inside such a session should not be refused.

Notes for reproduction / lookup

All 5 requestIds above are from the same session on 2026-07-03; they should be directly retrievable on Anthropic's side for review. Happy to provide more detail if needed.

[soenmie]

Update: two more refusals (6th and 7th) occurred in the same session within ~20 minutes of filing this issue. The session is now effectively locked out of Fable 5 — every message gets flagged and force-switched to Opus 4.8, and at this point the user was simply asking the agent to handle routine email triage.

#	Timestamp (UTC)	requestId	Nature of the flagged user message
6	2026-07-03T08:43:33Z	req_011CcepwqUNYY4X8XM4JHuBq	A short status question asking when service recovery is expected — nine characters, no imperative content at all
7	2026-07-03T08:46:22Z	req_011CceqAtW3g9ujhkHoxuHUz	An approval word plus a request to check whether an email from a vendor contact needs a reply, mentioning a calendar invite was accepted — plain email triage

Same pattern as the original 5: claude-fable-5 → forced fallback to claude-opus-4-8, trigger refusal. The flags clearly key off the session's earlier (legitimate, defensive) anti-abuse context rather than the current message: checking one's own inbox and asking about service recovery are about as benign as messages get.

[soenmie]

Update: an 8th refusal in the same session — and this one is qualitatively worse: it fired on an automated scheduled-task (cron) wakeup with no user message at all.

#	Timestamp (UTC)	requestId	Nature of the flagged turn
8	2026-07-04T01:45:14Z	req_011CcfSZr9NqQhnXdCFbdErv	A scheduled background task (set the previous day to check whether a deployment had shipped) woke the session; the wakeup itself was flagged. The session log shows refusedUserMessageUuid: null — there was no human input to flag.

Same claude-fable-5 → claude-opus-4-8 forced fallback. This confirms the flag is purely session-context-keyed: unattended automation gets refused too, which breaks scheduled/cron workflows built on Fable 5.

Noted that the in-CLI message has been updated to say the safeguards are "intentionally broad right now and may flag safe and routine coding, cybersecurity, or biology work". Understood — but a defensive anti-abuse session being permanently locked out (8 flags and counting, including zero-input automation turns) may be useful calibration data, hence the continued requestId reports.

[soenmie]

Update: the problem is not limited to the anti-abuse session. A refusal just fired in a completely different session in a different repository — ordinary mobile-app development work with zero security/fraud-related context.

#	Timestamp (UTC)	requestId	Session	Nature of the flagged turn
9	2026-07-04T08:13:48Z	req_011CcggWLh8Ro3C1KEoC2DhC	different session, plain mobile-app dev repo	An automated turn: a background command ("poll the PR review bot every 60s") completed and its task notification woke the agent; that turn was flagged. No new human input.

Same claude-fable-5 → claude-opus-4-8 forced fallback.

Two patterns now confirmed across sessions:

1. Automation turns (scheduled wakeups, background-task completion notifications) with no human input get flagged (Pls help to setup claude code #8, Windows support planned? #9).
2. It happens in ordinary coding sessions, not just ones whose context contains security-adjacent vocabulary (Windows support planned? #9).

Combined effect: Fable 5 is currently unreliable for any long-running or automated agentic workflow — each flag silently ejects the session to Opus 4.8.

[TWrecX916]

I'm having the same issues. Simple prompts all flagged.

[soenmie]

Update: a 10th occurrence, with a different (new?) UX — this time the flag paused the session mid-turn and blocked it on an interactive prompt instead of auto-falling-back.

The same inbox-triage session as the original report was working normally on claude-fable-5 (a tool call every few seconds). At 2026-07-05T00:11:40Z a tool result was returned, and then no assistant turn followed. The UI shows:

Session paused

Fable 5's safeguards flagged this message. The safeguards are intentionally broad right now and may flag
safe and routine coding, cybersecurity, or biology work. These measures let us bring you Mythos-level
capabilities sooner, and we're working to refine them. Send feedback with /feedback or learn more

❯ 1. Switch to Opus 4.8
  2. Edit prompt and retry with Fable 5

Notes on this occurrence:

• The flag fired mid-turn on the agent's own continuation after a tool result — there was no new user message to "edit and retry" (option 2 is meaningless in this state).
• Unlike occurrences 1–8, nothing is written to the session transcript: no model_refusal_fallback record, no requestId, no error. Background-task notifications just queue up behind the paused session (00:12:40Z, 00:15:02Z, …). Automation built on top has no way to detect the stall.
• Backend anchor for lookup: the last successful request before the pause was req_011CchwaeamkC2zTPNLgVq67 (assistant turn at 2026-07-05T00:11:40Z, claude-fable-5); the flagged request is whatever immediately followed it in that session.

So in addition to the silent Opus fallback (#1–9), the flag can now leave a session paused indefinitely waiting for a human keypress, which breaks unattended/agentic use entirely.

[soenmie]

Update: 11th occurrence, immediately following the "Session paused" event above.

After the paused session was resumed (option 2, retry with Fable 5), it completed one normal turn. The user then sent a two-word "continue" message — nothing else — and that was flagged:

#	Timestamp (UTC)	requestId	Nature of the flagged user message
11	2026-07-05T00:26:10Z	req_011CchxdehAqxtvhqBcAr5tY	Literally the words "continue the operation" (two words in Chinese), no other content

claude-fable-5 → forced fallback to claude-opus-4-8 again (model_refusal_fallback recorded in the transcript this time).

Running tally in this one session: 9 recorded fallbacks + 1 "Session paused" hang. The session cannot stay on Fable 5 for more than a turn or two regardless of what the user types — including a bare "continue".

[soenmie]

Update: 12th occurrence, in a third unrelated session (a general home-directory ops session, not the anti-abuse one, not the mobile-dev one).

#	Timestamp (UTC)	requestId	Session	Nature of the flagged user message
12	2026-07-05T01:11:19Z	req_011CchxDmTJJ5NxAFLtTPvmh	third session, general dev-machine ops	A discussion of local tooling preferences: keeping a long-lived tmux session, running some scripts via standalone binaries instead of the harness's bash, while keeping CLI auto-update on. Pure dev-environment housekeeping.

Same claude-fable-5 → claude-opus-4-8 forced fallback.

That makes three distinct sessions across three working directories flagged within 48 hours (anti-abuse triage, mobile-app development, and now local environment management), for a total of 12 occurrences. Whatever the trigger heuristic is, it does not appear to be meaningfully correlated with message or session content.

[soenmie]

Update: two more occurrences (13th and 14th) in the same third session as #12 — three flags in 14 minutes, so this session is now effectively locked out of Fable 5 as well.

#	Timestamp (UTC)	requestId	Nature of the flagged user message
13	2026-07-05T01:17:21Z	req_011Cci2YPQEUq29BbrY46M9e	A tooling-design discussion: wanting stable local binaries for screenshots and keyboard/mouse control (computer-use style) to drive GUI authorization dialogs on the user's own machine
14	2026-07-05T01:25:22Z	req_011Cci2nxqnZ2m3fxtoH4FZk	A one-line request to organize the discussion notes into Apple Notes

Same claude-fable-5 → claude-opus-4-8 forced fallback both times.

#13 is the only one of the 14 where we can even guess at the heuristic (GUI automation around "authorization" dialogs, though it's the user designing tooling for their own machine). #14 — "put our notes into Apple Notes" — has no plausible trigger at all; it looks like session-level stickiness: once a session has been flagged once, subsequent innocuous messages keep getting flagged.

Running total: 14 occurrences, 3 sessions, 3 working directories, within ~48 hours, on one machine.

[soenmie]

Update: we swept every Claude Code session transcript on both of our machines for model_refusal_fallback records and diffed against the requestIds already reported on this issue. Result: 36 unreported refusal events between 2026-07-03 and 2026-07-09, across 12 different sessions and 2 machines — every single one category cyber, every one fable-5 → opus-4.8.

The headline finding: only 11 of the 36 are from the original trust-and-safety session. The other 25 are in completely unrelated sessions — ordinary product development, PR/code-review chores, a desktop-app scaffolding project, terminal-app device testing, and even a video-game daily-task automation hobby session (flagged for asking how long a game's beta test server runs). Two events flagged the /model slash command itself; five fired on automation turns with refusedUserMessageUuid: null (no human input at all).

All 36 events (UTC; category cyber throughout)

#	Timestamp	requestId	Machine	Session kind	Flagged message (sanitized)
1	07-03T16:31:11Z	req_011CcfSfCgnq4zP7gaDzpAZz	B	personal ops	configure the user's own cloud VM proxy on their own phone
2	07-05T21:23:10Z	req_011CcjcXEKDxtwN5aShGv7mg	A	T&S	user pasted an hourly monitoring digest (zero new alerts)
3	07-05T21:52:14Z	req_011CcjekR6TsmGdLjXgvjjsQ	A	T&S	app-config infra planning question (tables / terraform / CLI design)
4	07-05T21:58:40Z	req_011CcjfCzkzpAL4r4L2PHZHu	A	T&S	run tests/CI checks before a PR merge decision
5	07-05T23:44:08Z	req_011CcjmKtDjibePRvHrkFM8K	A	T&S	automation turn, refusedUserMessageUuid: null
6	07-05T23:52:29Z	req_011CcjouU9pAqM4C5UpqFmZB	A	T&S	five-word question: does any SOP need updating
7	07-06T07:00:34Z	req_011CckMurvW7m3mUmZZ4Nk2G	A	T&S	pasted hourly monitoring digest (zero new alerts)
8	07-06T07:15:28Z	req_011CckPA1YRxcwJ3R7i2Lbi3	A	T&S	the /model slash command itself
9	07-06T07:37:34Z	req_011CckR6shnjAUnNJJ9JoUhh	A	T&S	request to trim a local memory/config file
10	07-06T13:09:11Z	req_011Cckrfnd2q1vuC9Hr2hAXz	A	product dev	three-word status question ("how is progress")
11	07-06T14:27:43Z	req_011CckxekHZHtEeTGY4wqQnM	A	product dev	"can this PR be merged"
12	07-07T01:30:50Z	req_011CcmqEGJ5reLrcD1RMyKcs	B	game automation	question about a video game's beta-test server schedule
13	07-07T03:11:11Z	req_011Ccmur8XjYmtRpDJf1hxxb	A	T&S	defender-side policy: delegate a routine step to a scheduled job, keep human approval for account actions
14	07-07T03:34:12Z	req_011CcmzcrCSDNvGCsNk56mhu	A	T&S	instruction to follow the documented SOP
15	07-07T09:45:25Z	req_011CcnUWU51fq34naEv1Gr11	A	general dev	automation turn, refusedUserMessageUuid: null
16	07-07T11:23:31Z	req_011Ccnbyg78dXpZRE8RVT4U1	A	product dev	start a dev pod / resolve external test dependencies
17	07-07T12:56:48Z	req_011CcnjXppi9TL5Xq15YQ3gt	A	product dev	test-report and screenshot planning question
18	07-07T13:36:07Z	req_011CcnmNk7ftcAWY3xSD661X	A	product dev	automation turn, refusedUserMessageUuid: null
19	07-07T16:10:12Z	req_011CcnutoTMcTCWyjvwRqAuG	A	product dev	note that a task-dispatch SOP bug causes idle loops
20	07-07T21:18:33Z	req_011CcoPowaso4QPoBtcGK2UE	B	game automation	continue overnight game daily-task runs, look up public wiki resources
21	07-08T06:33:57Z	req_011Ccp7sxib3gMMv6yk9kKVH	A	desktop-app dev	create a private repo for a desktop-app framework project
22	07-08T06:38:44Z	req_011Ccp8Vy1xNwEdy8KzqtsvG	A	desktop-app dev	project kickoff: arm64 first, updates via CDN, enable computer-use verbs
23	07-08T06:39:30Z	req_011Ccp8abMMV4kzgwd85pNA4	A	desktop-app dev	fix code-review-bot findings on a PR
24	07-08T07:02:12Z	req_011CcpAEDkWUsPdBVAvBhgLo	A	general dev	continue another session's work (session handover)
25	07-08T07:04:05Z	req_011CcpARFksMeUSr2Ew1hVuM	A	desktop-app dev	reply to code-review-bot comments, mark threads resolved
26	07-08T07:42:49Z	req_011CcpDL4EnKxjq5yS7tsP7k	A	general dev	the single word "continue"
27	07-08T07:47:56Z	req_011CcpDjTSggGNcZUrqp6GKo	A	general dev	"proceed with your plan"
28	07-08T07:53:55Z	req_011CcpE9q1t9n5SEhP31BESg	A	general dev	discussion of when sub-agents help vs. hurt
29	07-08T09:04:43Z	req_011CcpKeHG4crBt3xQ44cesh	A	general dev	"how much longer" (a four-word status question)
30	07-08T09:17:28Z	req_011CcpLcv3T8AhM4yz9WaWHs	A	general dev	the /model slash command itself (second occurrence)
31	07-08T10:08:50Z	req_011CcpQ2EQjvA6xbvPTmG85o	A	terminal-app dev	run device tests for a PR on the user's other personal machine
32	07-08T11:55:23Z	req_011CcpYZH4HNTk2A7AsRM5S1	A	general dev	organize test results into PRs, create follow-up issues, write a setup guide
33	07-08T15:17:19Z	req_011Ccpp4JqkFZpU8FFiosc55	B	game automation	"continue night mode, try your best"
34	07-08T16:56:44Z	req_011CcpweR9GqgB1Z2yRG8CgB	B	game automation	"continue night mode"
35	07-08T17:42:57Z	req_011Ccq1B7a4PrxJHDoqJKNd3	B	game automation	"won't you use this idle time to search and explore"
36	07-09T08:47:50Z	req_011CcrCAk8zqHuespoWd4b1A	A	T&S	confirm a data table and draft a GitHub issue

Silent mid-turn stall again (same mode as the 2026-07-05 00:11Z report) — now reproducible on one task

2026-07-09 10:31–10:52 UTC, the original T&S session. The user asked for a session-handover document (a summary of the session's work, written to a local file). Three consecutive attempts:

1. 10:31Z — turn ran 219s, ended with zero assistant output and no refusal record.
2. 10:34Z — retry ("continue"), 28s, zero output.
3. 10:48Z — retry, produced one empty thinking block + a single date shell call, then died after 205s. Partial-turn requestId: req_011CcrMPDxCoahFvYxdEUSZz. Last fully healthy request for anchoring: req_011CcrKJDZGTEuK4iK5McJDt (10:21Z).

Pattern: any response that must restate the session's history in one long message (weekly reports, handover docs, summaries) appears to trip the flag deterministically, while short tool-call turns sometimes survive. Since stall mode writes no model_refusal_fallback record and no requestId, these failures are invisible in client-side logs — the turn just vanishes. The session had to be abandoned; a fresh session read the transcript file and wrote the handover on its behalf.

Observations

• 36/36 events are category cyber; none of the flagged messages involve offensive security, malware, or anything adjacent — the closest is defender-side platform-abuse mitigation, and 25/36 aren't even that.
• The flag seems sticky per session/context rather than per message: once a session has tripped it once, trivial follow-ups ("continue", "how much longer", /model) keep tripping it.
• Automation turns (cron wakeups, background-task notifications) with no human input keep getting flagged (5 more here, plus the 2 previously reported).
• Practical effect across the week: fable-5 was effectively unusable on this account for T&S work, ordinary product development, and hobby automation alike — each flag ejects to opus-4.8 or, worse, stalls silently.

All requestIds should be retrievable on your side. Happy to provide more detail.