[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug Report: Claude Desktop loses/fails to render conversation history on SSH remote sessions

Summary

Claude Desktop (Windows) fails to display existing conversation history when connecting to a project via an SSH remote host, even though the session data is fully intact on the remote server. The app shows "No messages yet" / "showing 0 of 0 messages" for sessions that actually contain hundreds of messages on disk.

Environment

• Claude Desktop version: 1.32885.1 (a757f5), later updated during troubleshooting
• Claude Code CLI (local, Windows): updated from 2.1.233 → 2.1.235 during troubleshooting
• Claude Code CLI (remote host, auto-installed by Desktop app): found two versions coexisting at ~/.claude/remote/ccd-cli/: 2.1.229 and 2.1.234
• Connection type: Claude Desktop → SSH remote host (Linux server)
• Remote project path: a shared project directory (working directory was registered by the app in some places via a home-directory symlink pointing to the real shared path)

Problem Description

After a Claude Desktop update on Windows, all projects connected via SSH remote host started showing "No messages yet" in the chat pane, even for projects with extensive prior conversation history.

Verified Root Cause (confirmed via MCP inspection)

This is not data loss. The underlying transcript files are fully intact on the remote server:

~/.claude/projects/<project-dir>/
  <session-id-1>.jsonl   (1,251,037 bytes)
  <session-id-2>.jsonl     (536,620 bytes)
  <session-id-3>.jsonl   (1,150,530 bytes)

The live session registry (~/.claude/remote/run/...) confirms the Desktop app IS correctly connecting to the right session ID:

{"pid":<pid>,"sessionId":"<session-id-2>","cwd":"<remote-project-path>","startedAt":<timestamp>,"procStart":"<procStart>","version":"2.1.234","peerProtocol":1,"kind":"interactive","entrypoint":"claude-desktop","messagingSocketPath":"/run/user/<uid>/cc-socks/<pid>.sock","name":"<project-name>-57","nameSource":"derived","nameSince":<timestamp>}

The CLI process itself launches correctly and resumes the correct transcript:

ccd-cli/2.1.234 … --resume=<session-id-3> --replay-user-messages
cwd: <remote-project-path>

However, --replay-user-messages fails to repopulate the Desktop app's chat window. The client reports "showing 0 of 0 messages" for a session whose transcript file actually contains 255 messages. This was confirmed directly via the app's own MCP interface.

Manually resuming the exact same session ID from the CLI on the remote host (./ccd-cli/2.1.234 --resume <session-id>) loads the full history correctly — proving the transcript and session-matching logic both work. The failure is isolated to the Desktop app's client-side rendering/replay step specifically for sessions resumed over the SSH remote connection path.

Suspected Contributing Factor

The transcripts affected were originally written by CLI version 2.1.229 and are being reopened/resumed by 2.1.234 (and later 2.1.235) after the Desktop app auto-updated. This version skew between "writer" and "reader" may be involved in the replay failure — worth checking whether the message-replay parser has a compatibility issue across these versions.

Steps to Reproduce

1. Set up Claude Desktop on Windows with an SSH remote host connection to a Linux server.
2. Have an extended conversation (100+ messages) in a project on that remote host.
3. Let Claude Desktop auto-update to a new version (or manually update).
4. Reconnect to the same SSH remote project.
5. Observe: chat pane shows "No messages yet" despite the remote .jsonl transcript containing full history and the app correctly identifying/resuming the matching session ID.

Impact

• Users relying on SSH remote development (server-side execution required — Docker, databases, Linux-only tooling) lose visible access to conversation history through the GUI after any Desktop update, even though no data is actually lost.
• This creates a false impression of data loss and forces users to either start fresh (losing context) or fall back to manually running the CLI binary over SSH by hand — defeating the purpose of the Desktop app's SSH remote feature.
• Related to (but distinct from) the closed issue #21280, which covers a different mechanism (path/symlink resolution fragmenting project directories). In our case the project directory and session ID are correctly matched — the failure is purely in the client-side message replay/render step.

What We've Ruled Out

• Not a symlink/path resolution issue: tested by creating an equivalent symlink under .claude/projects/ and re-querying; no change, reverted with no config left modified.
• Not data loss: transcript files verified intact with correct sizes and content, readable in full via manual CLI resume on the remote host.
• Not a "new/orphaned session" issue: the live session registry confirms the Desktop app is targeting the exact same sessionId that holds the historical content — it isn't creating a fresh empty session, it's failing to render the existing one.

Requested Fix

Please investigate why --replay-user-messages fails to repopulate the Desktop app's UI for SSH-remote-resumed sessions, despite the CLI process itself successfully loading the correct transcript. A client-side rendering/sync bug that makes fully-intact remote conversation history invisible is a serious reliability problem for any SSH-based remote development workflow.

Happy to provide additional logs, the exact .jsonl transcripts (redacted if needed), or reproduce further tests if useful.

What Should Happen?

Claude Desktop should retain and correctly render full conversation history when connecting to a project via an SSH remote host, even after an app update, version change, or reconnect. Existing session transcripts on the remote host should be displayed in full, not shown as empty.

Error Messages/Logs

Client reports "showing 0 of 0 messages" via the app's own MCP interface for a session whose remote transcript file actually contains 255 messages.

Session registry entry confirming correct session targeting:
{"pid":"<pid>","sessionId":"<session-id>","cwd":"<remote-project-path>","version":"2.1.234","peerProtocol":1,"kind":"interactive","entrypoint":"claude-desktop","messagingSocketPath":"/run/user/<uid>/cc-socks/<pid>.sock"}

CLI resume command launched by the app:
ccd-cli/2.1.234 ... --resume=<session-id> --replay-user-messages

Steps to Reproduce

1. Set up Claude Desktop on Windows with an SSH remote host connection to a Linux server.
2. Have an extended conversation (100+ messages) in a project on that remote host.
3. Let Claude Desktop auto-update to a new version (or update manually).
4. Reconnect to the same SSH remote project.
5. Observe: chat pane shows "No messages yet" / 0 of 0 messages, despite:

• The remote .jsonl transcript file containing the full history intact (verified via file size and manual CLI resume).
• The app correctly identifying and resuming the matching session ID (confirmed via the live session registry file).
• Manually running the CLI on the remote host with the same --resume <session-id> loads the full history correctly, proving the failure is isolated to the Desktop app's client-side message replay/render step, not the underlying data or session-matching logic.

Not caused by data loss, symlink/path fragmentation (ruled out), or orphaned/new session creation (ruled out) — see attached report for full diagnostic detail.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

2.1.229

Claude Code Version

2.1.235 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

<img width="1006" height="1015" alt="Image" src="https://github.com/user-attachments/assets/0dbc45e1-f419-44c6-b2ff-1c23cb10f022" />