Problem

On the desktop/TUI app, an assistant turn that produced only a thinking/reasoning block (extended-thinking turns, thinking-only recovery responses) disappears from the session view on resume/reload — while the turn is still in the transcript DB, so a new session can recall "what was said." This is the second symptom reported on #44022 (scorpio-dot's comment):

after 2 or 3 messages, mainly when the LLM starts to use its "thinking" block, the message disappears entirely. I tested by opening a new session and getting the agent to recall what was said in that session and it can see the messages but they are still invisible in the session.

Root cause

tui_gateway/server.py::_history_to_messages drops any message whose coerced text is empty before the assistant reasoning fields are attached:

if not content_text.strip():
    continue
msg = {"role": role, "text": content_text}
if role == "assistant":
    for key in ("reasoning", "reasoning_content", "reasoning_details", "codex_reasoning_items"):
        if key in m and m.get(key) is not None:
            msg[key] = m.get(key)   # <- never reached for a reasoning-only turn

A reasoning-only assistant turn has empty content but non-empty reasoning, so it is filtered out of the resume payload entirely. The turn is still persisted (gateway/session.py stores the reasoning fields), which is why recall from a fresh session works — the asymmetry is display-only, on the history→messages serialization path used by desktop/TUI resume and reload.

Fix

Keep an assistant turn when it carries any reasoning content, even with empty visible text, so the desktop's reasoning ("Thinking…") disclosure has something to render. Genuinely empty turns (no text, no reasoning, no tool calls) are still filtered out, and tool-call-only turns are unaffected.

Tests

• test_history_to_messages_keeps_reasoning_only_assistant_turn — a reasoning-only turn survives with its reasoning field intact.
• test_history_to_messages_still_drops_empty_assistant_without_reasoning — empty/whitespace turns with no reasoning are still dropped.

Both pass; full tests/test_tui_gateway_server.py shows no new failures (one pre-existing unrelated browser_manage failure present on main as well).

Scope

This is the display/serialization half of #44022's reports. The separate "resume fails with No LLM provider configured" provider-restore bug is addressed by #44062 (the complete restore-side fix) / #44151, and the persist-side by #44109. Using Refs #44022 rather than Fixes so the provider bug isn't auto-closed.

Refs #44022

🤖 Generated with Claude Code