iOS Remote Control duplicates one assistant text block around its Bash row; earlier mobile prose matches thinking blocks instead of CLI output (host 2.1.288)

Environment: macOS host, CLI process version 2.1.288 (verified in incident JSONL); installed CLI later reports 2.1.289. Model claude-opus-5-5, Medium. Session launched with --remote-control. Claude iOS app version, iOS version and macOS version unknown. Ten user mods are enabled. No plugin-disable reproduction has been performed.

Observed steps (one captured incident, not a deterministic minimal repro):

1. Run a local interactive Claude Code session with Remote Control and follow it in the Claude iOS app.
2. During a multi-tool turn, have Claude give a brief progress update before a Bash call. At 2026-10-03 23:47:10.713 EDT, the update was “C1 is now usable again. Next, why the engine refused the 1490 intent file:”.
3. Observe a Bash row described as “Show validation output before the preflight failure”.
4. While the app is still synthesizing, observe the same sentence both above and below that row.
5. Compare local JSONL: one text block, one tool_use and one result; the next response contains different prose. Also compare the two earlier blockquoted phone paragraphs: they exactly match persisted thinking fields, while the CLI wording supplied by the observer differs and is absent from saved text fields.

Expected: render each response text block once, maintain order around tool rows, and clearly distinguish thinking summaries from delivered assistant prose; keep CLI, persisted transcript and remote view consistent.

Actual: two screen copies of a single saved text block. Earlier phone paragraphs are thinking content. Reload persistence, web-client behavior and whether the server sends duplicate events are unknown.

Evidence: text UUID 240408ec-2aaa-43d4-9f37-0b4caa53520b; message msg_011CfgWdQTJKoPbWyGYjLhNa; apiBlockIndex 1; Bash toolu_01P6xGmrXqiRNpQ36ZJpBBep; timestamps. Earlier thinking UUIDs e667531c-1487-48de-a406-c0eb99e23959 and 0fe3f19c-dc3b-4672-8d3c-83acceea2b5d.

Related issues: #94397 (different SendUserMessage mechanism), #88897 (remote duplicate rendering), #85443 (potential text persistence loss), #93470 (thinking-versus-delivered-answer distinction).

Questions for maintainers: Is the text block emitted twice by the relay, rendered once as historical content plus again as the current streaming message, or split into two UI rows when the tool completes? Why are these phone paragraphs mapped to thinking while the reported CLI text is absent from JSONL? Please correlate server event IDs/content-block indices with the provided local IDs.

Suggested vendor investigation/fix direction, not a proven patch: inspect deduplication between current streaming text and committed/history rows using message ID plus content-block index; verify role/block-type preservation across the relay and persistence pipeline. The evidence does not justify a specific implementation change without wire-level traces.

🤖 Generated with Claude Code