[Bug] Desktop app displays assistant reply text that the transcript records only as a (summarized) thinking block

Environment: Claude Code desktop app (Code tab), Windows 11, model claude-opus-5-5, effort medium.

What happens

An assistant message made of [thinking, visible reply text, tool_use] is displayed correctly in the app: the user sees the reply text above the tool call. But the session transcript JSONL records that message as:

record N   : {"type":"assistant", content:[{"type":"thinking", ...}], apiBlockIndex:0}
record N+1 : {"type":"assistant", content:[{"type":"thinking", "thinking":"<one-line paraphrase of the reply>", "signature":...}], apiBlockIndex:1}
record N+2 : {"type":"assistant", content:[{"type":"tool_use", ...}]}

No {"type":"text"} block is written. The apiBlockIndex:1 block, which should hold the reply text, holds a short signed paraphrase of it instead.

Why it matters

PreToolUse hooks read transcript_path to see what the assistant just told the user. Any hook that checks for text the assistant must post before acting (ours requires a "FLIGHT PLAN" block before the first file edit) wrongly denies the call, because the text the user saw is not in the transcript. It also means the transcript is not a faithful record of what the user was shown.

Frequency

Intermittent. In one session, 7 of 8 hook denials had this shape. Other messages in the same sessions record [thinking, text, tool_use] correctly. The operator confirmed that in affected messages the full reply text was visible in the app.

Evidence

Local transcripts, available on request:

• Session ff727810-b25d-4986-b290-789209969eb7, messages ending 12T36o, Hfr57V and s7UMsp (the last reproduced while trying to file this issue)
• Session 3b6d3572-f750-4fe2-9c53-5e74a57ed382, messages ending syFmyh, QmFHWo, rZik9G, 2uehGb, zpAjGh

Expected

Visible reply text is persisted as a {"type":"text"} content block before PreToolUse hooks run for the tool_use that follows it.