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

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.

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.

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 (#8, #9).
2. It happens in ordinary coding sessions, not just ones whose context contains security-adjacent vocabulary (#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.

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

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.

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".

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.

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.

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.