[BUG] Fable-5: Desktop Code-session transcript drops assistant text in spans with AskUserQuestion/ExitPlanMode (~50%; Opus-4.8 unaffected)

Preflight Checklist

• [x] I have searched existing issues — closest relatives are #23862 (closed, TUI variant), the #75217 / #24691 family (TUI/VS Code, different mechanics), and #76025 (same symptom on VS Code, see Related); no report matches this one
• [x] This is a single bug report
• [x] I am using the latest version (Claude Desktop 1.18286.2)

What's Wrong?

In Claude Desktop (Code sessions), plain assistant text silently disappears from the transcript when the span between two typed user messages contains an AskUserQuestion or ExitPlanMode tool call. Three observations distinguish this from the known "text before a tool call doesn't render" family (#24691): (a) one marker was answered "visible" at its dialog check and was found missing on a re-check ~15 minutes later in the same session — the text rendered first and disappeared retroactively; (b) text eaten in a Desktop session is also missing when the same conversation is loaded fresh in claude.ai in an unrelated browser — the outcome is persisted server-side, not a local render race; (c) the eaten text still exists in the session data (local session .jsonl) — it is only never rendered.

Model correlation (from controlled testing — this is the sharpest signal). The loss tracks the model, not the client and not the turn structure. Same account, same Desktop client; only the model and the text/dialog placement were varied:

| | text + dialog in one turn | text and dialog separated by intervening turns/tool calls |
|---|---|---|
| Fable 5 | intact (n=1) | ~50% eaten (10 of 19) |
| Opus 4.8 | 6/6 intact | 5/5 intact |

Across ~11 Opus-4.8 trials (both structures) zero were eaten; on Fable-5 with the identical separated structure ~50% were. If Opus-4.8 shared Fable-5's rate, P(0 of 11 eaten) ≈ 0.05%. Independently corroborated by #76025 (Fable-5 omits text before AskUserQuestion; Opus-4.8 does not) on a different surface (VS Code sidebar). Because the eaten text is present in the session data (point (c) above and property 6 below), this is the renderer dropping Fable-5's emitted text — not the model failing to produce it.

Numbers, from a controlled series on 2026-07-07 (19 trials with recorded outcomes; each trial = a plain-text paragraph with a unique canary string, followed by a dialog tool call, visibility answered through the dialog itself): 10 of 19 markers were missing at check time (~53%). One of the 9 survivors ("🟡 МАРКЕР-С2" / "MARKER-S2") was re-checked later and had disappeared — the user's typed message "маркера 2 нет" ("marker 2 is not there") is recorded in the session data — making the final known score 8 intact / 11 gone. Two further occurrences during normal use: an intact span on 2026-07-08 and an eaten span on 2026-07-09.

Properties established by the trials:

1. Zone boundaries are typed user messages. Dialog-button clicks, task notifications, and scheduled wake-ups do not start a new zone: markers separated from the dialog call by several turns (background commands, wake-ups) still disappeared when no typed user message intervened.
2. Retroactive (observed directly once). МАРКЕР-С2 was answered "intact" at its dialog check and was found gone ~15 minutes later, with only dialog clicks and assistant turns in between.
3. ~50% per trial on Fable-5. Inserting 0–20 s delays or long thinking pauses between the text and the dialog call did not change the odds.
4. Persistent. The missing text has not come back — after answering the dialog, after reloads, or when loading the conversation fresh in claude.ai in a Firefox-based browser.
5. Never affected: tool-use chips, HTML widgets, and the dialog's own fields (question text, options, plan body). In one trial the same content was posted simultaneously as plain text and as an HTML widget: the widget survived, the plain-text copy disappeared.
6. The text exists in the session data. The local session .jsonl contains every eaten marker; the records of eaten and intact trials are structurally near-identical (same message/tool-call sequence, parent chains, stop reasons), so the discriminator is not visible in client-side data.

On this account, with Fable-5, the effect appears in roughly half of all trials (n=21 over three days). I can share session IDs / redacted .jsonl on request via whatever channel the maintainers prefer.

What Should Happen?

Assistant text should render and persist regardless of whether the span also contains an AskUserQuestion or ExitPlanMode call — and regardless of which model produced it.

Error Messages/Logs

None — no errors anywhere; the text is silently absent.

Steps to Reproduce

1. In a Claude Desktop Code session on Fable 5, send a message such as: "Reply with a short paragraph containing the string MARKER-1, then use AskUserQuestion to ask me something." (The effect is much stronger when the paragraph and the dialog end up in separate turns — e.g., ask for a paragraph, then some tool calls, then a question.)
2. Answer the question, then check whether the paragraph with MARKER-1 is present in the transcript.
3. Repeat several times: on Fable-5 roughly half the attempts lose the paragraph while the question card renders normally. Also re-check earlier markers as you go — one marker in my series was visible at first and disappeared later. Running the same steps on Opus-4.8 did not lose text in ~11 trials.
4. Reload, or open the conversation in a browser — the missing text does not come back, although it exists in the session data.

Note: since few others appear to have reported this, there may also be an account- or rollout-specific dimension. If a few attempts don't trigger it, that may mean your account/model isn't affected rather than that the report is invalid — the session-data evidence above stands independently of reproduction.

Claude Model

claude-fable-5 (the bug is Fable-5-specific: not reproduced on claude-opus-4-8 across ~11 controlled trials with the same client and structure).

Is this a regression?

I don't know

Claude Code Version

Engine 2.1.187 and 2.1.202 (the 2026-07-07 session spanned an engine update; the 2026-07-09 trials were on 2.1.202). App: Claude Desktop 1.17377.0 and 1.18286.2 — both affected. (The Linux builds are community repackages of the official app; however, the missing text is also absent on a fresh claude.ai load in an unrelated browser, and the text is present in the session data — packaging cannot explain a server-persisted, model-correlated outcome.)

Platform

Anthropic API (claude.ai subscription login; the app's requests go to api.anthropic.com)

Operating System

Other Linux (Fedora 44, KDE Plasma)

Terminal/Shell

N/A — the bug is in the Desktop app Code-session transcript UI, not in a terminal

Additional Information / Related issues

Filed here because the bug is in the Code-session transcript renderer (Desktop app / claude.ai/code), and its closest relatives all live in this tracker:

• #76025 "[VS Code Sidebar] Fable 5 doesn't show text responses in chat" — very likely the same underlying bug on a different surface, and independent corroboration of the model correlation (Fable-5 affected, Opus-4.8 not). That report attributes it to the model omitting text; the session-data evidence here shows the text is emitted, so it is a renderer drop specific to Fable-5's output shape, not model silence.
• #23862 "AskUserQuestion is blocking text" — closed as duplicate of #58207, fixed in 2.1.141; that was the TUI variant (text overlapped by the question UI). This report is the Desktop-transcript variant and still reproduces on current versions. Filed as a new issue per the lock-bot instruction on #23862.
• #75217 / #24691 family ("text before a turn-ending tool call never renders", TUI/VS Code) — related but distinct: that one is deterministic and tied to any turn-ending tool call. This one is probabilistic (~50%), Fable-5-specific, tied specifically to the dialog tools, was observed once to disappear after having rendered, hits text several turns away from the dialog call, and the outcome persists across clients and reloads.