[BUG] Dispatch: desktop pane renders no messages — sessions-bridge drops every user echo ("empty inboundUserMessages FIFO")

Summary

Dispatch works end-to-end — messages sent from the mobile app reach the local agent, are processed, and are answered — but the desktop Dispatch pane stays completely empty. No user message and no assistant reply is ever painted. From the desktop it looks like Dispatch is dead; from the phone it looks like it is talking to something invisible.

The cause appears to be that sessions-bridge discards the user-message echo that would render the turn in the desktop UI, misclassifying it as a post-compact re-emit.

Environment

| | |
|---|---|
| Claude Desktop | 1.44121.4.0 (x64, MSIX / Microsoft Store package) |
| Claude Code (bridged SDK) | 2.1.258 |
| OS | Windows 11 Pro 26100 |
| Plan | Max |
| Agent runtime | Cowork Linux VM (CoworkVMService running) |

UUIDs, session IDs and paths are redacted below as <ORG>, <DEVICE>, <SESSION-B>, <VM-HOME>.

Steps to reproduce

1. Pair Dispatch between Claude Desktop (Windows) and the mobile app.
2. Send a message to the Dispatch thread from the phone.
3. Observe the phone receives a normal reply.
4. Observe the desktop Dispatch pane — it remains empty.

Expected

The turn (user message + assistant reply) renders in the desktop Dispatch pane, matching what the phone shows.

Actual

The desktop pane shows no messages at all. main.log logs a dropped echo once per message:

08:41:53 [info] [sessions-bridge] Received user message for session <SESSION-B> (2 chars)
08:41:54 [info] Starting local session local_ditto_<ORG> in <VM-HOME>
08:42:07 [info] [sessions-bridge] Dropping user echo with empty inboundUserMessages FIFO
                for session <SESSION-B> (likely post-compact re-emit)
08:42:08 [info] [sessions-bridge] Query completed for session <SESSION-B> (pendingTurns=0, isError=false)
08:42:08 [info] [sessions-bridge] Session <SESSION-B> turn completed, keeping transport open for follow-ups

This repeats exactly once per message — three messages produced three drops (08:42:07, 08:44:54, 08:45:44), each immediately before a successful Query completed (isError=false).

Note the "likely post-compact re-emit" attribution looks wrong here: this was a freshly created session (Created session <SESSION-B> (trigger=start) at 08:40:15), and the drop occurs on the very first message of that session. No compaction had taken place.

Evidence that the messages are genuinely processed

The on-disk agent transcript contains all three turns, so only the UI render path is affected:

local-agent-mode-sessions/<DEVICE>/<ORG>/agent/local_ditto_<ORG>/.claude/projects/.../<cli-session>.jsonl

[2026-09-03T22:42:04Z] user: hi
[2026-09-03T22:42:08Z] assistant: Sent.
[2026-09-03T22:44:53Z] user: where is this session?
[2026-09-03T22:45:01Z] assistant: Answered.
[2026-09-03T22:45:43Z] user: 1
[2026-09-03T22:45:49Z] assistant: Answered.

bridge-state.json likewise recorded all three message UUIDs in processedMessageUuids.

Notes

• The bridge itself is healthy: Environment registered, remote-tools-device authenticated, remote-control bridge_state: "connected".
• This is distinct from the "desktop appears offline" reports (#45937 and its duplicates) — here the desktop is genuinely online and serving turns; only the desktop's own rendering is broken.