[BUG] Focus mode hides a standalone final text-only message — not just text co-located with a tool_use

Summary

In focus mode the assistant's final, text-only reply is collapsed into a summary line and never rendered:

* Worked for 3m 58s · 2 messages hidden (/focus to show)

Toggling /focus off renders the same turn in full, answer text included. So the text exists — it is a render decision.

Why this is worth a separate report: the diagnostic note in #50894 says the hide is keyed on API message structure, specifically that "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." Our transcript shows the collapse also happens for a standalone message whose content is a single text block, with no tool_use anywhere in it. The rule that drops the text is broader than that note describes, which may matter for whoever fixes it.

Environment

• Claude Code 2.1.241, model claude-opus-5[1m]
• Headless Linux (Ubuntu 24.04), terminal TUI over mosh + tmux — not VS Code, not the desktop app

Reproduction

1. /focus on.
2. Issue a request that takes several tool calls and ends with a substantive text answer.
3. Let the turn finish, then start another turn (in our case a scheduled task fired ~4 minutes later).
4. The finished turn now renders as Worked for 3m 58s · 2 messages hidden (/focus to show). The answer is not on screen anywhere.
5. /focus off → the full answer appears in place, and the same line reads simply Worked for 3m 58s.

Transcript evidence

Assistant messages of that turn, in order, straight from the session JSONL:

| time | content blocks | text length |
|---|---|---|
| 17:57:20 | ["thinking"] | 0 |
| 17:57:35 | ["tool_use"] | 0 |
| 17:57:43 | ["tool_use"] | 0 |
| 17:57:54 | ["thinking"] | 0 |
| 17:57:56 | ["tool_use"] | 0 |
| 17:58:11 | ["tool_use"] | 0 |
| 17:58:26 | ["tool_use"] | 0 |
| 17:58:47 | ["text"] | 1761 chars |

No message mixes text with tool_use. The final message is text-only, it is the answer, and it is the thing that got hidden.

Impact

We run long autonomous sessions where the operator reads only the final message of each turn — that is precisely what focus mode is for. When the final message is the thing that disappears, the operator sees that work happened and cannot see what it concluded. In our case the hidden text carried a root-cause analysis and the list of commits that fixed it; the operator only learned it existed after toggling focus off and scrolling back.

The failure is silent: nothing on screen indicates that the missing content was the answer rather than tool noise.

Related

• #50894 — same bug, auto-closed as stale/not planned on 2026-06-16; a "this is still live" comment from 2026-07-23 has not reopened it. Dupes filed against it: #53239, #56968.
• #67474 — desktop-app variant of the same class.
• #83746 — open feature request asking focus view to keep human-facing messages visible.

Happy to have this closed as a duplicate if #50894 is reopened instead — one live thread is better than two.