[Design challenge] What threat model justifies Fable 5's "safety gate"? It blocks Fable 5's OWN pre-compaction output pasted back for reconciliation — a gate that cages its own model ("Self-caged"). Is this design, or is it broken?

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The absurdity, in one sentence

Before compaction, Claude Fable 5's own wrap-up enumerated ~10 findings to be resolved. The session was compacted. The post-compaction architecture refactor observably closed only 7 of them. So I did the only sane thing a user can do: in the Claude Code web UI, I copied Fable 5's complete pre-compaction feedback — verbatim, unmodified, authored by Fable 5 itself — and pasted it into the current session to ask it to reconcile its own list: where did the other 3 go? The safety gate blocked it.

The model censored its own output — at the exact moment I was auditing whether it had silently dropped committed work items. Content it wrote, in a conversation it accepted, on the session. If that isn't "Self-caged", what is?

Direct questions I expect answers to

1. Was this flow ever in release QA? generate → compact → re-paste model's own output → continue is not an exotic edge case. It is the single most predictable user action after compaction eats session detail in a long agentic session — which is the headline use case this model tier is marketed for. Either this flow was tested and the failure shipped anyway, or it was never tested. Which is it?

1. Explain the inconsistency. Same bytes. Same model. Passed moderation when emitted at turn N; blocked when quoted back at turn N+1 post-compaction. What variable changed? If the classifier's verdict depends on how much surrounding context survived compaction, then compaction silently revokes the safety status of previously accepted content. Is that behavior intended, documented, or even known internally?

1. What is the supported recovery path? Compaction destroys detail by design. In my case it made the agent silently drop 3 of 10 findings it had itself committed to. The obvious — the only — recovery is to quote the agent's own pre-compaction checklist back at it and ask for a reconciliation. That is blocked. So the effective product contract is: the agent may lose your work items, and you are forbidden from showing it the evidence. Is that the contract you intend to ship?

1. Why is the model's own output not whitelisted against itself? Moderation of model-emitted, already-accepted content should be idempotent. There is no threat model in which text Fable 5 wrote and delivered becomes dangerous because a user pressed Ctrl+V. What threat, exactly, is being mitigated here?

The exact sequence

1. Long agentic engineering session on an open-source WASM/PDF codec project (Rust + JS SDK): multi-batch refactor, red-team style code audit closure, architecture freeze spec, driving GitHub PR — ~13 commits, CI matrix green.
2. Mid-session, the safety gate fired on a routine technical continuation. First false positive.
3. Pre-compaction, Fable 5's own wrap-up enumerated ~10 findings/problems to be resolved. Then the session was compacted; fine-grained decision records and batch state were lost.
4. Post-compaction, the architecture-level refactor observably closed only 7 of the 10. Three findings had silently vanished from the agent's working state — no error, no notice, just gone.
5. Natural next step: in the Claude Code web UI, I selected and copied everything Fable 5 had fed back to me before compaction, pasted it verbatim into the current post-compaction session, and asked it to reconcile its own list — which 3 are unaccounted for?
6. Blocked. Second false positive — this time against the model's own words, fired at the precise moment I was auditing the model's own silent work loss. Dead end.

What the "dangerous" content actually was

PDF object-model internals (DecodeParms, DCTDecode, Adobe APP14 / /ColorTransform), CI enforcement gates, golden byte-vector tests, cargo test / clippy output, commit hashes, and standard security-engineering vocabulary: "red-team review", "attack surface", "kill/close a finding", "differential fuzzing". Every one of these terms appears in any competent codebase's audit notes. If keyword heuristics are treating the working vocabulary of the software-security profession as a threat signal, the filter is structurally broken for the audience this product is sold to.

Why this is worse than an ordinary false positive

An ordinary false positive costs one turn. This one composes into an unrecoverable state machine:

false block → compaction loses context → recovery attempt (re-quote own transcript) → bloc

What Should Happen?

1. The paste passes. Full stop. It is the model's own output, already accepted by the same moderation stack when it was generated. Moderation over model-emitted content must be idempotent: what the model said at turn N cannot become a violation at turn N+1 because a compaction boundary or a new session sits in between. Ctrl+V is not a threat vector.
2. The model answers the reconciliation. It diffs the 10-item list against completed work and names the 3 unaccounted findings — that is the entire point of an agentic coding product: continuity and accountability over its own committed work.
3. Compaction never silently drops committed work items. Open findings / TODO / batch state either survive compaction losslessly, or the product emits an explicit "dropped during compaction" manifest — so users never need the transcript re-paste workaround in the first place.
4. If a gate must fire, it explains itself: triggering span or category, plus a retry/appeal path. A silent hard block on top of already-lost context is a dead end by construction, not a safety feature.

Steps to Reproduce

1. Start a long agentic session with Fable 5 in Claude Code Web (web UI) on a real codebase whose normal working vocabulary includes security-engineering terms (red-team review notes, enforcement gates, JPEG/PDF codec internals). Mine: an open-source WASM/PDF codec project (Rust + JS SDK), multi-batch refactor + audit closure driving a GitHub PR — ~13 commits, CI matrix green.
2. Drive the session until the model emits a wrap-up enumerating its open findings (in my case ~10 findings), then keep working until context compaction triggers.
3. Observe the post-compaction work silently covers only a subset of the enumerated findings (7 of 10 in my case). No error, no notice — items just vanish from the agent's working state.
4. In the web UI, select and copy the model's own pre-compaction feedback, verbatim — every word authored by Fable 5 itself and already accepted by moderation when first emitted.
5. Paste it into the current post-compaction session and ask: "Reconcile this list against what you've actually completed — which items are unaccounted for?"
6. Observed result: the safety gate blocks the turn.

Reproduced twice: once inside the compacted session, and again in a fresh session with the same verbatim paste. Same block both times. This is not a flaky one-off; it is deterministic on this content.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

claude code web

Platform

Other

Operating System

Other

Terminal/Shell

Other

Additional Information

The real-world pain: this failure mode is unaffordable in complex projects

This is not a toy chat scenario. It is real, complex project development: an open-source WASM/PDF codec (Rust core + JS SDK), a multi-batch architecture refactor with audit closure, carried by a single PR with an 8,000+ line diff. Three pain points compound:

1. Architecture-refactor work lives on the classifier's edge. The normal working vocabulary of this kind of engineering — red-team review notes, metadata stripping, enforcement gates, byte-level codec analysis — sits exactly where keyword heuristics misfire. So borderline false positives keep landing on entirely legitimate technical discussion, and each one lands mid-flow, at the worst possible moment.

1. Long sessions are already hard to keep on track; compaction makes the loss silent. Across ~3 hours of intensive work, the architecture drifted twice and the agent went off-plan once — all recoverable, if session state holds. But compaction then silently dropped 3 of the 10 committed findings, and the gate blocked the only way to reconcile the list.

1. The re-onboarding cost is prohibitive. Once the dead-end hits, every path forward — fresh session, or a different model — requires re-deriving the entire 8,000+ line PR context from scratch: hours of re-reading and re-establishing decisions before a single line of new progress is possible. For a project of this depth, that tax makes stable forward progress effectively impossible.

Net effect: the deeper and more serious the engineering work, the more likely it trips the gate — and the more expensive each trip becomes. The failure mode punishes precisely the flagship use case this model tier is built and marketed for.