Desktop (Windows): remote SSH session loses UI message history after reboot

I'm having this same issue. However, I noticed the problem also happens without a reboot if I shutdown claude for windows, then go into task manager and end all claude tasks, then restart claude for windows.

I hit the same UI symptom from a different trigger and have additional evidence pointing to the root cause. Cross-posting from #58797 (which I'll close as duplicate).

Different trigger, same bug: instead of rebooting the client, I killed the bridge process on the remote host (kill $(pgrep -f "remote/server --bridge")). The bridge auto-respawned, but all existing sessions then showed "No messages yet" — exactly as in this issue. The reboot path probably hits the same code path because Windows reboot drops the in-RAM ccd-cli processes the Desktop client was previously process.reattach-ing to.

Direct test of the binary, bypassing the client and bridge entirely:

{ echo '{"request_id":"t","type":"control_request","request":{"subtype":"initialize","hooks":{}}}'; sleep 8; } \
  | timeout 10 ~/.claude/remote/ccd-cli/2.1.138 \
      --output-format stream-json --input-format stream-json --verbose \
      --resume <SESSION_UUID> \
      --replay-user-messages --include-partial-messages \
  > /tmp/stdout.log 2> /tmp/stderr.log

Result: 1 line of stdout — only the control_response/success to initialize. Zero user/assistant events replayed from the transcript. Same result on 2.1.121, 2.1.128, and 2.1.138 — not a regression, the cold-spawn replay path appears to have never worked.

Two distinct code paths, only one of which works:

• process.reattach (client reconnects to a long-lived ccd-cli that has the transcript buffered in RAM) → works, history renders
• process.spawn + --resume + --replay-user-messages (cold start, transcript must be read from disk) → silent, no replay events emitted

Whatever drops the in-RAM state of ccd-cli processes (client reboot in your case, bridge restart in mine, --serve daemon restart in general) forces the client onto the cold-spawn path, which exposes the missing replay.

Suggested fix (pick one):

1. Make ccd-cli --resume X --replay-user-messages emit the buffered user/assistant records on stdout immediately after the first initialize response.
2. Add an explicit control_request:replay_history RPC the client can issue after process.spawn of a --resumed process.

Full details with binary symbol analysis and /proc/<pid>/fd/ inspection in my closed duplicate: #58797.

Happening on macOS, this is not Windows-specific.

Environment:

• Claude Desktop 1.9255.2 (1dc8f7) on macOS
• SSH session from MacBook Pro to Mac mini
• Remote project's ~/.claude/projects/<slug>/ on the mini has several healthy .jsonl transcripts, all recent, owned by the SSH user with normal permissions

Symptom: every session in the project's sidebar shows "No messages yet". Session titles and metadata are intact, transcript content is missing only in the UI.

The 1.9255.2 update doesn't appear to be the trigger. This matches the diagnosis in #58797 (cold ccd-cli --resume via process.spawn not replaying the on-disk transcript, vs. the warm process.reattach path that works). Posting mainly so this isn't triaged as Windows-only.

+1 issue to thread:

Desktop app (WSL): existing chat shows "No messages yet" — transcript is present in WSL but never loaded into the UI

Environment

• Claude Code: 2.1.131
• App: Claude Code Desktop (Windows), "Code" tab, connected to a WSL2-hosted project via the remote bridge
• WSL: Ubuntu 22.04, kernel 6.6.114.1-microsoft-standard-WSL2
• Model shown: Opus 4.8 (1M context)
• Stores: Windows %USERPROFILE%\.claude (session index/list) + WSL ~/.claude (transcripts)

Summary

In the Desktop app, opening a chat whose project lives in WSL renders an empty message pane
("No messages yet") even though the conversation exists and is being recorded. This happens
after restarting the app, and reproduces even when WSL is already running and was started
before the app. The session resumes with full context (the model behaves as if it remembers
everything), but none of the prior messages are displayed.

Steps to reproduce

1. Start WSL2 (confirm it's running — e.g. an open WSL terminal).
2. Launch the Claude Code Desktop app (Windows) after WSL is up.
3. Open the "Code" tab and select an existing chat for a WSL-hosted project.

Expected: the chat's prior messages render in the pane.
Actual: the pane shows "No messages yet", while the session is otherwise live and the model
has full context. (Screenshot available: an active session reads "No messages yet" in the center.)

Evidence — this is a UI load/backfill bug, not data loss and not a startup race

• The transcript is actively being written in WSL during the live session. The current

session's file ~/.claude/projects/<escaped-cwd>/<uuid>.jsonl grew from 24 → 59 lines (≈56 KB → ≈242 KB)
over the course of the conversation, with fresh assistant entries timestamped seconds before
the pane was observed empty. So the writer and the data are fine.

• The empty pane reproduces with WSL already up and started before the app, which rules out a

"WSL/filesystem not warm yet" race.

• The Windows-side %USERPROFILE%\.claude has a populated session list (so chats appear in the

sidebar), but the message bodies live only in WSL and are not pulled into the UI on connect.

• A remote bridge runs in WSL (~/.claude/remote/server --serve + --bridge,

socket ~/.claude/remote/run/<id>/rpc.sock); the app connects through it.

Conclusion: on (re)connect, the Desktop app does not backfill/render the existing transcript
for a WSL-hosted session. The data is intact and resumable; only the UI rendering of history fails.

Impact

Every restart leaves past conversations unreadable in the UI, even though they exist on disk and
the session resumes with full context.

I can confirm this bug. Exact same issue and context (issue on claude desktop only ,windows machine -- ssh --> wsl2)

Same bug on macOS → Linux over SSH, still present in current builds (ccd-cli 2.1.217, 2026-07-23). Adding a data point since this is labeled platform:windows — it is not Windows-specific.

Environment

• Client: Claude Desktop on macOS <!-- fill in app version from About -->
• Remote: Ubuntu 22.04.5 VM over SSH
• App-pushed remote CLI: ~/.claude/remote/ccd-cli/2.1.217 (the app has pushed 2.1.209 → 2.1.215 → 2.1.217 over the past ten days; bug present throughout)
• Transcript on remote is intact: ~/.claude/projects/<flattened-cwd>/<session-uuid>.jsonl — 1.5 MB, 635 lines, and still growing while the pane says "No messages yet"

Two symptoms beyond the OP

1. No OS reboot needed — quitting and reopening the desktop app is enough to blank the pane.

• OS reboot also did not help

1. It's not only scrollback: new turns don't render either. The pane stays blank even though (a) the session's process is alive on the remote and correctly registered in ~/.claude/sessions/<pid>.json (right sessionId, version 2.1.217, entrypoint claude-desktop), and (b) messages typed into the blank pane DO reach the session — the model receives and answers them, which I can verify with claude --resume in a terminal on the remote, where the full history renders fine.

A probe that may help debugging: the app's own session-management backend can't see remote transcripts at all. Calling the list_events tool (ccd_session_mgmt MCP) from inside a session against another remote session with a fully populated transcript returns showing 0 of 0 messages. Meanwhile the process/registry layer is healthy — session list, git status polling, and message delivery all work, and ~/.claude/remote/run/*/remote-server.log shows no errors.

Consistent with the mechanism described in #58701 (and dups #54187 / #64393): the UI only hydrates history from live-process events and never falls back to the on-disk .jsonl.