SSH remote sessions render empty - client-side mirror transcript is created with 0 bytes

Environment

Client (Windows, where the UI runs)

• Claude Desktop, connected to a remote host over SSH
• Mirror path: %USERPROFILE%\.claude\projects\ssh-<session-id>\<session-id>.jsonl

Remote host (Windows 10 Pro 10.0.19045)

• Claude Desktop 1.44121.4 (MSIX, WindowsApps\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc)
• ccd-cli 2.1.260 (also seen: 2.1.247, 2.1.255, 2.1.258)
• Remote server binaries under ~/.claude/remote/srv/: 7d193f89… (08-31), 678bbae5… (09-03), 4534d864… (09-04)
• Transcripts: ~/.claude/projects/<cwd-key>/<session-id>.jsonl

What happens

Opening an existing SSH remote conversation shows "No messages yet". The SSH badge is present and shows connected. Typing works, and only messages typed from that point on appear.

No errors anywhere: DevTools Console and Network are clean (checked with Preserve log enabled), and the remote remote-server.log contains only [process.Manager] and [Server] lines with zero errors.

Root cause

The renderer does not read the transcript on the remote host. It reads a mirror copy on the client, and that mirror is created empty.

| session | remote original | client mirror |
|---|---|---|
| A | 5,914,939 B | 0 B |
| B | 7,528,834 B | 972 B |

The same signature appears for subagent transcripts: at one reconnect the client created several hundred agent-*.jsonl files, all 0 bytes, while the corresponding files on the remote host are 85–134 KB each.

Confirmation: copying the remote original over the client-side mirror (app closed, then scp) restores the full conversation for both sessions. This confirms the mirror is the only source the renderer reads, and that the remote data was never affected.

scp "<user>@<host>:C:/Users/<user>/.claude/projects/<cwd-key>/<session-id>.jsonl" \
    "%USERPROFILE%\.claude\projects\ssh-<session-id>\<session-id>.jsonl"

This explains every symptom: nothing errors because nothing fails — the client faithfully renders an empty file; new messages appear because they are appended to the mirror; restarting the app does not help because the mirror is never backfilled.

Reproduction

Not deterministic yet. It occurred six times over two days on this setup. What we can state:

• It is not project-specific — two sessions with different working directories were affected simultaneously.
• The transcript on the remote host is always intact (see below), so it is purely a sync/mirror failure.
• Several occurrences immediately followed a client update that pushed a new srv/<hash> server binary and a new ccd-cli version to the remote host, but at least one occurrence had no version change, so that is a correlation and not an established trigger.

Remote data is never damaged

Verified structurally, not just by line count:

session A   4284 records   orphans 0   parent chain 3361   single sessionId
session B   1968 records   orphans 0   parent chain 1557   single sessionId

Zero records whose parentUuid points at a missing uuid. Session B is a clean single-leaf chain and still rendered empty.

Workarounds

1. claude --resume <session-id> in a terminal on the remote host — bypasses the mirror path entirely and always works.
2. scp the remote original over the client mirror with the app closed (verified above).

Closing and reopening the window worked once early on and stopped working afterwards.

Note for triage

The desktop app stopped writing its own file logs on this machine after 2026-08-21 — logs/main.log, ssh.log have no entries since then, and main-window.log / mcp.log are 0 bytes. That left DevTools as the only live diagnostic channel, which made this much harder to narrow down than it should have been.

Ruled out during investigation

Listing these so they are not chased again — each was checked and excluded:

• Old and new server.exe --serve on different sockets (split-brain), and bridges attaching across them
• ccd-cli process being force-respawned under a live window
• serve / bridge binary generation mismatch — the stale servers were terminated and the generations aligned; the symptom was unchanged
• Session being opened as local instead of remote — the SSH host is bound and connected
• Transcript corruption or a broken parent chain