Focus mode hides substantive assistant messages, not just tool output

Adding a diagnostic note from #53239 (closing that as a dupe of this):

The hide is keyed on API message structure, not on "between tool calls." When the assistant emits text and a tool_use block in the same API message, the collapsed view drops the text alongside the tool render. ctrl+o (detailed transcript) shows the hidden text, so it's a render decision, not transport.

Note for the suggested fixes: #1 and #2 target the right layer. #3 (system prompt) won't fully cover it — text and tool_use can land in the same API message even when the model isn't narrating, and they'll still collapse together.

I can confirm this issue still exists. Here's an additional reproduction path:

1. Enable /focus
2. Send a request that triggers tool calls + a final text summary
3. Exit the conversation
4. /resume to restore the session

The entire response (including the final text reply) is collapsed into Called 1 tool · 3 messages hidden (/focus to show). The user never sees the substantive answer.

Screenshot from my session (Windows 11, claude-opus-4-6):

<img width="1797" height="179" alt="focus-resume-bug" src="https://github.com/user-attachments/assets/45c19f0a-29d6-4582-a339-cd21b7a8158d" />

Filed as #56968 before finding this issue. Closing that as duplicate.

Adding a litigation-workflow use case to weight prioritization.

I run Claude Code primarily for legal / litigation work — drafting filings, managing discovery sets, building case theory across multiple cases. Sessions routinely include inline corrections between tool calls: Claude reads a PDF exhibit, then in the same API message says "the date you cited is 9/15, not 9/12" before issuing the next tool call. With focus mode on, that correction collapses alongside the tool render and isn't visible unless I press Ctrl+O.

Data isn't lost (the Ctrl+O workaround is real and works), but the operational risk is real too: in a Saturday filing window, in the middle of a four-tool-call sequence, I won't always remember to expand. I'm using focus mode despite this bug because the alternative — full tool-output panels in chat — drowns the substantive English in noise across 12+ PR merges, RCA QA passes, document-extract loops, etc. But the inline-text suppression makes high-stakes sessions feel like flying with one eye closed.

Agreeing with @dui's diagnosis upthread: fix at the render layer; #3 (system prompt) won't fully cover it because text and tool_use can land in the same API message regardless of how well the model is instructed to separate them.

Happy to test a candidate fix on the litigation workflow if helpful.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This is still live — recent activity here (#53239, #56968, both marked duplicates of this) shows it's ongoing, not stale. Auto-closing on inactivity buried a real, reproducible bug.

Fresh repro today: a multi-paragraph response under /focus got replaced by an auto-generated "recap" line that picked a different, lower-priority headline than the actual answer — not just hidden text, a misleading stand-in for it. Matches @dui's diagnosis above (text + tool_use landing in the same API message collapse together). Splitting the final answer into its own tool-free message avoids it, but that's a caller-side workaround most people won't know to do.

Given the documented real-world impact already in this thread, worth reopening rather than leaving this on an inactivity auto-close.

Still reproducing on 2.1.241 (model claude-opus-5[1m], headless Linux, terminal TUI over mosh + tmux). Adding a detail that contradicts the diagnostic note above, in case it matters to whoever picks this up.

The note says the hide is keyed on API message structure — text and tool_use emitted in the same API message. In our case the hidden content was a standalone message whose content is a single text block, with no tool_use in it at all. Straight from the session JSONL, the turn's assistant messages in order:

| time | content blocks | text |
|---|---|---|
| 17:57:20 | ["thinking"] | 0 |
| 17:57:35 – 17:58:26 | ["tool_use"] × 5 | 0 |
| 17:58:47 | ["text"] | 1761 chars |

No message mixes text with a tool call. That last text-only message is the answer — a root-cause analysis plus the commits that fixed it. Under /focus the whole turn rendered as Worked for 3m 58s · 2 messages hidden (/focus to show) and the answer was nowhere on screen; /focus off rendered it in place. So the render rule drops clean final text too, not only text co-located with a tool call.

Severity note from our side: we run long autonomous sessions where the operator reads only the final message of each turn — which is exactly what focus mode is for. When the final message is the one that disappears, the operator sees that work happened and cannot see what it concluded, with nothing on screen to indicate that the missing content was the answer rather than tool noise. Ours was found by accident, days later.

This was auto-closed as stale on 2026-06-16 and a "still live" comment from 2026-07-23 did not reopen it. Requesting a reopen — the bug outlived the timer.

Filed the standalone-text-message case as #89318 with the transcript table, since this thread is closed. Happy to have it closed as a duplicate if this one is reopened instead.