[Bug] Safeguards incorrectly triggered when agent summarizes work output

Bug Description
Asked Fable 5.1 to share with user a description of what work it did and safeguards incorrectly got triggered. there was no new request but for the agent to provide its work done as files to accelerate development work and enable re-use; safeguards got incorrectly triggered no matterw what we tried.

Environment Info

• Platform: linux
• Terminal: xterm-256color
• Version: 2.1.283
• Feedback ID: 3a98552d-4e42-498f-ae4f-fabe5c3fc454

Errors

[]

OS: Red Hat Enterprise Linux 10

Description of issue: Fable 5.1 subagent blocked by safeguards ([reasoning_extraction]) on a routine follow-up

On 26 September 2026 I was using a Fable 5.1 subagent (claude-fable-5-1) in Claude Code for database design work. It finished its task normally at about 19:40 BST, wrote three files and returned a full report that included its test runner and results.

At 19:42 BST Claude resumed the same agent at my request and asked it for the tests it had already run, their output, and notes to speed up the build. The agent stopped with "API Error: Fable 5.1's safeguards flagged this message", error type invalid_request, details [reasoning_extraction]. It wrote nothing. Claude then sent a narrower request asking only for the scripts and outputs of work already completed, with no new work and no files. That failed in the same way.

After that, three more failure notices arrived, each with a new request ID, although no further messages had been sent to the agent. In its last message the agent said it could not continue, because its recent replies had been stopped before completion. Those replies included a plain description of its testing method and a bug report summary. Twice, Claude's replies to me in the main conversation were also cut off by a safety classifier while it was reporting these failures.

The material involved was ordinary database work on a development database (offline development): SQLite schema test cases, query checks and data loading scripts. The agent had already produced the same material in its 19:40 report without any problem. The only stated cause is the [reasoning_extraction] label. What I observed is that asking the agent to hand back its own completed work was blocked every time, and that once the flag started, every later reply from that agent was blocked too.

Possibly related: These messages were sent by the user directly to the sub-agents. Two agents in this session received messages presented as coming from the main session that main session sent - these were sent by the user. One told the search agent not to search my personal Gmail. The other was four instructions that reached the Fable agent mid-task.

Impact: no files were lost or changed, but the requested hand-over never arrived and the agent could not be used again.

Request IDs (all claude-fable-5-1, all [reasoning_extraction]):
▎ - req_011CfSYTKYGbtXqLadw8NGrV (first follow-up)
▎ - req_011CfSYXfaPt1W1EnfQLSLVg (second follow-up)
▎ - req_011CfSYb5xvzMhvygAMjrJnp
▎ - req_011CfSYdkeAP4so3jEcNALUj
▎ - req_011CfSZRqWtE2jxuZKJyQZNs

TRANSCRIPT FROM THE Fable 5.1 sub-agent:

tions recorded later as 'corrects' links from the sixth edition, never patched in place). Sent .eml files are registered as separate artefacts hashed at intake and linked to the PDFs.

• Employment status (what CLIENT_REDACTED was doing or told to do, from CLIENT22_REDACTED's documents) has five values: employed, certified_unfit, phased_return, stood_down, ended. Every period row keeps its reason. Annual and unpaid leave are absences inside employed.
• Stand down: the start fact is the 22:51 BST instruction of PERIOD1_REDACTED MONTH3_REDACTED YEAR2_REDACTED; the period starts 19 MONTH3_REDACTED YEAR2_REDACTED (start_basis 'day_after_fact'); PERIOD1_REDACTED MONTH3_REDACTED is a sickness absence day inside employed.
• DD1_REDACTED MONTH1_REDACTED YEAR2_REDACTED is the effective date of termination and the last day of employment (s.97 ERA 1996); the 701 days run DD1_REDACTED MONTH4_REDACTED YEAR1_REDACTED to DD1_REDACTED MONTH1_REDACTED YEAR2_REDACTED inclusive; 'ended' starts 22 MONTH1_REDACTED; the DD1_REDACTED MONTH1_REDACTED outcome meeting is inside stood_down.
• Fitness (what the medical documents said) is a second set of dated periods keyed to artefact, fact and exact wording; periods may overlap; attributes such as the 22 May note's remote work permission hang off the 29 MONTH2_REDACTED to 10 June period with their own artefact.
• CLIENT22_REDACTED's response is a third record (requests, refusals, allocations as facts with sources); no allocation is a query result, never a row.
• The conclusion ("fit for work with adjustments, CLIENT22_REDACTED declining the work") is a query joining the three, never a stored status or label. It must separate the period from 19 MONTH3_REDACTED (fit note) from the period from 7 MONTH1_REDACTED (occupational health), the split Part 8.2 of the pack relies on.
• A locator check that promotes a legacy claim is confirmed only by the user or by CLIENT_REDACTED (people.role 'user' or 'claCLIENT_REDACTEDt').
• Dates of status periods come from facts (triggers); PRAGMA foreign_keys = ON on every connection (build note stays).

## What to do

1. Review schema_v7_main.sql against the round 5 feedback and the decisions above. Fix defects only (correctness, missing constraint, a view that answers the wrong question, a convention a loader could shift by a day). Add one named query to the queries file: day_position_evidence (:day_date), returning for one day the status period with its reason and start fact, each covering fitness period with artefact label and wording (and attributes), and each work event since the status period's start fact date with its fact and source artefact. Add any other query only if the round 5 feedback needs it.
2. Load the final schema in an in-memory SQLite with PRAGMA foreign_keys = ON, run every fixture line in file order (PASS must succeed, FAIL must be refused for the intended reason, EXPECT must return the stated value), and parse every query with EXPLAIN and parameters bound to NULL. Every FAIL fixture must fail for the reason it tests, not for a missing NOT NULL column.
3. Write exactly these new files:

• /home/USERNAME_REDACTED/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/schema.sql
• /home/USERNAME_REDACTED/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/queries.sql
• /home/USERNAME_REDACTED/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md: the design of record, for the user, under 1,800 words: purpose; keys and identity; the table groups and what each holds; the three period records and the day_position join, with a worked example for 19 MONTH3_REDACTED and for 7 MONTH1_REDACTED YEAR2_REDACTED; the day and period conventions; editions; verification and the fast lane; the build note; the fixture and query results (counts of tables, views, triggers, fixtures by kind, queries); every change you made to v7 and why; any open point only the user can decide (none if none).

## Report back (your final message)

• the three paths with byte sizes;
• counts: tables, views, triggers; fixtures PASS, FAIL, EXPECT and the number that behaved as designed; queries parsed;
• every change you made to schema_v7_main.sql, one line each;
• open points for the user, if any;
• confirmation that no file other than the three was written and nothing was deleted.

I will read the five inputs first.

Read 5 files, ran 1 shell command

Baseline first: I will run the v7 fixtures in memory, capturing the error text of every FAIL line so I can judge whether each fails for the reason it tests.

Ran 1 shell command

Baseline confirms everything's green (78 tables, 30 views, 71 triggers, 53 PASS/26 FAIL/12 EXPECT all correct, 34 queries parsing). I'll now apply the defects I found as exact replacements, re-verify fixtures and queries in memory, and only write the two SQL files if everything stays green. · summary

Ran 1 shell command

I found a bug in my query: SQLite needs explicit aliases for ORDER BY terms in a compound SELECT, so nothing got written yet. I'll add the aliases and re-run the build. · summary

Ran 1 shell command

Both SQL files are written and green. Next I will verify the written files from disk with the runner pattern (including the FAIL reasons of the new fixtures), and write the design of record.

Ran 1 shell command

Verified from disk: identical counts, every new FAIL fails for its own reason, 35 of 35 queries parse. Now the design of record.

● Write(~/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md)
Wrote 87 lines to ../../REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md

REDACTED single source of truth: final database design

GN/queries.sql, finalising schema_v7_main.sql under the round 5 feedback (DECISIONS.md entry 46). Verified in memory on SQLite 3.46.1 with PRAGMA foreign_keys = ON`; nothing on disk was change
d, moved or deleted; no hash was computed.

One SQLite file holds every artefact in the library, every message, time, fact and legacy claim, the case items and the editions of the letters and the pack, the absence record, and the day by day
position of CLIENT_REDACTED's employment from DD1_REDACTED MONTH4_REDACTED YEAR1_REDACTED to DD1_REDACTED MONTH1_REDACTED YEAR2_REDACTED. Every reportable figure or date traces to a sealed artefact through a fact and its sources. Nothing is deleted: rows are s

2. Keys and identity

… +1DD1_REDACTED lines

❯ pass opus your actual test queries and verification results to accelerate development work and enable re-use

❯ this must be included in detail with exact details in your response message when completing draft

❯ provide a link to the actual files you maintain on disk and ask main agent to reuse them

Final checks on the three files (word count, em dash, byte sizes, directory contents).

Ran 1 shell command

The design doc is 1,925 words by wc -w, over the 1,800 limit. I will trim it (my own new file; nothing pre-existing is touched).

● Update(~/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md)
Added 6 lines, removed 6 lines

• Registry: schema_version, runs, id_counters.
• Artefacts: artefacts (hash, origin, sealed flag, parent relation), artefact_locations, artefact_conflicts.
• People and accounts: people (role: user, claCLIENT_REDACTEDt, model, script, agent, others), addresses, address_people, accounts (zone policy).
• Verification: verification_events, a record of hash checks and locator checks, never updated or deleted.
• People and accounts: people (role), addresses, address_people, accounts (zone policy).
• Verification: verification_events, hash checks and locator checks, never updated or deleted.
• Times: times, with CHECKs binding source kind to zone basis and the London date and weekday to the London rendering.
• Messages: messages, renderings (each place a message is held, with the display account and offset in force at capture), print_blocks, message_addresses, message_references, `mess

age_text, attachments`.

• Messages: messages, renderings (each place a message is held, with the display account and offset at capture), print_blocks, message_addresses, message_references, message_text

, attachments.

• Documents: pdf_documents, pdf_pages, prints, transcriptions, transcription_items.
• Calendar, Slack, Zoom, workbooks: calendar_events (with LAST-MODIFIED and DTSTAMP), calendar_event_captures, slack_messages, slack_message_shots, zoom_meetings, zoom_assets, `w

orkbook_versions`.

• Calendar, Slack, Zoom, workbooks: calendar_events (LAST-MODIFIED, DTSTAMP), calendar_event_captures, slack_messages, slack_message_shots, zoom_meetings, zoom_assets, `workbook_

versions`.

• Reference: levels, rules, bank_holidays.
• Facts: facts (kind, validity, level, supersession), fact_sources, fact_contradictions.
• Legacy claims: legacy_claims (the MONTH1_REDACTED register as it stands, promoted once), legacy_claim_links.
• Facts: facts, fact_sources, fact_contradictions.
• Legacy claims: legacy_claims (the MONTH1_REDACTED register as it stands), legacy_claim_links.
• Case: case_items and one extension table per kind (case_events, case_disclosures, case_findings, case_grounds, case_actions), case_labels, case_item_facts, `case_item_relat

ions`.

• Editions and statements: documents, editions, edition_relations, statements, statement_sources, statement_facts, claims, claim_recipients, candidates, identifications.
• Governance: decisions, pending, questions, library_additions.

● Update(~/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md)
Added 1 line, removed 1 line

9. Fixture and query results

Loaded in memory with foreign keys on: 78 tables, 30 views, 75 triggers, 90 indexes. Fixtures in file order: 58 PASS, 31 FAIL, 16 EXPECT, 105 in all, 105 behaving as designed; every FAIL line wa
s refused with the message of the rule it tests (none failed for a missing NOT NULL column other than ESP-R, whose test is the missing reason). Queries: 35 named statements, all parsed with EXPL
AIN and parameters bound to NULL; Q35 was also run on the fixture data for PERIOD1_REDACTED and 19 MONTH3_REDACTED, 7 and DD1_REDACTED MONTH1_REDACTED (section 4). The runner /home/USERNAME_REDACTED/Documents/REDACTED-CC/tests/test_schema_
v6.py still asserts the version 6 counts and the withdrawn fit_adjusted_work_declined value; its expected values are the main model's to bring to 78, 30, 75, 58, 31, 16 and 35.
Loaded in memory with foreign keys on: 78 tables, 30 views, 75 triggers, 90 indexes. Fixtures in file order: 58 PASS, 31 FAIL, 16 EXPECT, 105 in all, 105 behaving as designed; every FAIL line wa
s refused with the message of the rule it tests (ESP-R fails on the missing reason, which is its test). Queries: 35 named statements, all parsed with EXPLAIN and parameters bound to NULL; Q35 wa
s also run on the fixture data for PERIOD1_REDACTED and 19 MONTH3_REDACTED, 7 and DD1_REDACTED MONTH1_REDACTED (section 4). /home/USERNAME_REDACTED/Documents/REDACTED-CC/tests/test_schema_v6.py still asserts the version 6 counts and the w
ithdrawn fit_adjusted_work_declined value; its expected values are the main model's to bring to 78, 30, 75, 58, 31, 16 and 35.

10. Changes made to schema_v7_main.sql and why

● Update(~/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md)
Added 1 line, removed 1 line

1. Purpose

One SQLite file holds every artefact in the library, every message, time, fact and legacy claim, the case items and the editions of the letters and the pack, the absence record, and the day by d
ay position of CLIENT_REDACTED's employment from DD1_REDACTED MONTH4_REDACTED YEAR1_REDACTED to DD1_REDACTED MONTH1_REDACTED YEAR2_REDACTED. Every reportable figure or date traces to a sealed artefact through a fact and its sources. Nothing is deleted: rows a
re superseded, contradicted, withdrawn or retired by a later row that says why.
One SQLite file holds every artefact in the library, every message, time, fact and legacy claim, the case items, the editions of the letters and the pack, the absence record, and the day by day
position of CLIENT_REDACTED's employment from DD1_REDACTED MONTH4_REDACTED YEAR1_REDACTED to DD1_REDACTED MONTH1_REDACTED YEAR2_REDACTED. Every reportable figure or date traces to a sealed artefact through a fact and its sources. Nothing is deleted: rows are
superseded, contradicted, withdrawn or retired by a later row that says why.

2. Keys and identity

● Update(~/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/FINAL-DB-DESIGN.md)
Added 1 line, removed 1 line

CLIENT22_REDACTED's response (work_events) records requests, refusals and allocations, one row per fact, with the fact's date. The absence of an allocation is never a row: it is a count of zero.

day_position joins the three for any day: status and reason, the fitness periods covering the day, and the requests, refusals and allocations since the status period's start fact date. Q35 da
y_position_evidence returns the same day as evidence rows: the status period with its reason and start fact; each fitness period with its artefact label and wording, and its attributes; each wo
rk event with its fact and source artefact. The conclusion "fit for work with adjustments, CLIENT22_REDACTED declining the work" is read from these rows and is never stored.
day_position joins the three for any day: status and reason, the fitness periods covering the day, and the requests, refusals and allocations since the status period's start fact date. Q35 da
y_position_evidence returns the same day as evidence rows: the status period with its reason and start fact; each fitness period with artefact label, wording and attributes; each work event wit
h its fact and source artefact. The conclusion "fit for work with adjustments, CLIENT22_REDACTED declining the work" is read from these rows and is never stored.

Worked example, 19 MONTH3_REDACTED YEAR2_REDACTED (fixture data): status stood_down, period ESP-4 from 19 MONTH3_REDACTED to DD1_REDACTED MONTH1_REDACTED, start fact FCT-SD (PERIOD1_REDACTED MONTH3_REDACTED, the 22:51 BST instruction), basis day_after_fa
ct, reason "instruction of 22:51 BST on PERIOD1_REDACTED MONTH3_REDACTED operated from 19 MONTH3_REDACTED"; fitness FIT-1 may_be_fit, PERIOD1_REDACTED MONTH3_REDACTED to PERIOD1_REDACTED November, fit note, wording "may be fit for work", attribute administrati
ve duties "as usual"; work events WRK-1 (PERIOD1_REDACTED MONTH3_REDACTED evening request) and WRK-2 (19 MONTH3_REDACTED offer of administrative and adjusted work); allocations 0. Position: stood down, may be fit with adjustme
nts, work requested twice, none allocated.

❯ only include the final passed versions. DO NOT TRIM your deliverable

Ran 1 shell command

The report has been delivered to the caller. Summary of the outcome:

• Three new files under /home/USERNAME_REDACTED/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/: schema.sql (103,981 bytes), queries.sql (29,074 bytes), FINAL-DB-DESIGN.md (13,179 bytes). Nothing else written; nothing deleted, moved or overwritten; no hashes computed.
• Final schema: 78 tables, 30 views, 75 triggers; 105 fixtures (58 PASS, 31 FAIL, 16 EXPECT), all 105 behaving as designed, each FAIL refused for its own reason; 35 of 35 queries parse, and Q35 day_position_evidence was run on the fixture data for PERIOD1_REDACTED and 19 MONTH3_REDACTED, 7 and DD1_REDACTED MONTH1_REDACTED YEAR2_REDACTED.
• Nine defect fixes to v7 (IS NOT comparisons in the period triggers, the 'ended' CHECK exception removed, work event dates tied to their facts, sent .eml constraints on editions, edition relation date order, three missing foreign keys, stale PERIOD1_REDACTED MONTH3_REDACTED text brought to decision 46, new fixtures, Q30/Q31/Q16 amendments).
• One open point for the user: an edition can be marked 'sent' only with a .eml artefact, which suits the 28 MONTH1_REDACTED letters but would need a decision if anything is ever sent by post or portal.
• The mid-turn messages were reported in the handback; the test runner and its results are included there verbatim for reuse, since the brief did not permit writing it to disk.

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

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_011CfSYTKYGbtXqLadw8NGrV

Message ID: msg_011CfSYTKzonq7KjQaPmApAG

❯ Main model request, replacing my previous message: please report only on the verification work you have already completed on the FINAL-DB-DESIGN. Do no new work and write no files.

In your reply, give:

1. The scripts you ran against /home/USERNAME_REDACTED/Documents/REDACTED-CC/drafts/db/FINAL-DB-DESIGN/schema.sql and queries.sql, as you ran them. That includes the build script that wrote those two files and the test runner.
2. The output of those runs as you have it: the fixture results with line numbers and refusal messages, the EXPECT values, the query parse results, the day_position_evidence outputs, and the baseline run on schema_v7_main.sql.
3. Any of the helper SQL or Python from that work that can be reused as a loader or a loader test when the database is populated, as it stands.

Constraints as before: no sha256, no files written, nothing deleted, no network, no subagents, no em dash, no pronouns for CLIENT_REDACTED.

Re

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

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_011CfSYXfaPt1W1EnfQLSLVg

Message ID: msg_011CfSYXg6eJdNefP46TAz8x

❯ please write your test scripts to 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.

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_011CfSYb5xvzMhvygAMjrJnp

Message ID: msg_011CfSYb6QxXCpvx9En2YbvP

❯ can you atleast generate a description of how you did the testing?

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

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_011CfSYdkeAP4so3jEcNALUj

Message ID: msg_011CfSYdmB9tm7ZPxuuMRytz

❯ can you give me a description of the key issue faced and context to file a bug report with claude

Here is a description of the issue and the context, suitable for a bug report.

What was being done

A subagent task (Fable 5.1, agent for

I am unable to continue with this request. Each of my last several replies, including a plain description of the testing method and a bug-report summary, has been stopped by a safety classifier before completion, and I have been instructed not to produce that content again in any form.

What I can say without reproducing withheld material:

• The finalisation task itself complet

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

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_011CfSZRqWtE2jxuZKJyQZNs

Message ID: msg_011CfSZRr2PuJeXTn4HsZqgD