[BUG] Critical: Desktop SSH sessions render 'No messages yet' — transcripts intact and correctly resumed server-side, hydration fails client-side (password-auth mirror connection)

Severity: Critical

Every SSH-remote session in Claude Desktop renders "No messages yet" when opened, across all projects. The transcripts are fully intact on the remote host and the backend resumes them with full context — the failure is purely client-side hydration. To the user this is indistinguishable from total data loss of all remote chat history, and it affects every session on every project accessed over this SSH connection. Filing as a consolidated report with a full server-side diagnostic chain; maintainers, feel free to dedupe into the existing cluster (#76124, #76560, #63025, #50982, #58701, #72335).

Environment

| Side | Detail |
|---|---|
| Client | Claude Desktop on Windows 11, LAN → SSH → Linux host |
| SSH auth (main connection) | Password (confirmed in server auth.log, see below) |
| Remote OS | Linux 7.0.0-28-generic x86_64 |
| Remote desktop toolchain | ~/.claude/remote/ccd-cli/ contains 2.1.221, 2.1.222 |
| Remote standalone CLI | 2.1.223 (native installer, ~/.local/share/claude/versions/) |
| Transcript versions in affected session | 2.1.222 (entrypoint: claude-desktop) |

Symptom

• Sidebar lists all sessions correctly, grouped by project, with correct titles and worktree/branch bindings.
• Clicking any previously-created SSH session shows "No messages yet". The worktree diff banner (e.g. +418 −3) loads correctly in the same view.
• The one session that renders fine is the currently live one (streaming in real time).
• Typing /resume or /continue into the Desktop chat pane returns "isn't available in this environment."

Diagnostic chain (all verified on the remote host)

1. Transcript is intact and still being appended to by the Desktop app. Example session 9f416701-34ab-440b-9271-1ec74c157c84 ("GitHub Copilot auto-generated commit messages"):

~/.claude/projects/-home-dustin-Claude-Git-Grump--claude-worktrees-copilot-commit-message-generation-837e5b/
  9f416701-34ab-440b-9271-1ec74c157c84.jsonl   612,410 bytes, 190 events, 0 malformed lines

2. The Desktop app is bound to the correct session — no fork. Slash commands typed into the "empty" Desktop pane were appended to that exact .jsonl, same sessionId, "entrypoint":"claude-desktop", tagged version 2.1.222. lastActivityAt in the Desktop session index matches the .jsonl mtime to the second. So this is not the silent-fork failure mode of #73526 — resume targeting works; only rendering fails.

3. Desktop's own view of the session contains only post-reopen events. Reading the session's events through the Desktop session-management surface returns 14 messages — exclusively the post-reopen slash-command attempts. The ~176 prior events (the entire original conversation from the previous day) are absent from what the client surfaces, despite being present in the .jsonl it is actively appending to.

4. Remote ~/.claude.json index is healthy — ruling out the null-projects corruption from #63025's OP for this case. projects is a populated dict with per-project entries for every affected project.

5. Main SSH connection authenticates by password. Server auth.log, interleaved during a Desktop session this morning:

Accepted password  for dustin from 192.168.3.188 ...   ← Windows client (Desktop app)
Accepted publickey for dustin from 172.19.0.2   ...   ← unrelated container, key auth

This matches the community-confirmed trigger in #63025: with password auth, the Desktop app's background transcript-mirror/tail connection cannot authenticate non-interactively, fails silently, and the client-side mirror (%USERPROFILE%\.claude\projects\ssh-<session-id>\) is never created — which is the only source the UI renders from. Multiple reporters (Windows and macOS) confirmed history reappears immediately after switching the connection to key-based auth.

Expected

Opening a session renders its full message history, as local sessions do — regardless of client-side mirror presence. If the mirror/tail connection cannot authenticate, that failure should be surfaced to the user, not swallowed while the pane claims "No messages yet."

Why this deserves critical priority

1. Perceived total data loss. The user sees every past conversation as empty. Nothing in the UI indicates the data is safe, that the failure is cosmetic, or that context is preserved.
2. Silent failure. No error anywhere client-visible; the mirror connection failure is swallowed.
3. Broad blast radius. Password-auth SSH is a common default; every such user loses visible history for every remote session, and reports span Windows, macOS, WSL2, and plain Linux remotes going back months (#58701 was filed in early July).
4. The backend already proves the data is available — the same app instance appends to the correct transcript while refusing to display it. The fix (hydrate from the authoritative remote transcript, or surface mirror-connection failures) has a clearly scoped seam.

Suggested fixes

• Hydrate the message pane from the remote .jsonl via the existing bridge RPC when no local mirror exists (the authoritative data is demonstrably reachable — the resume path reads it).
• If the background mirror/tail SSH connection fails auth, surface it ("History unavailable: background connection failed — this connection uses password authentication; add an SSH key") instead of rendering an empty state.
• Reuse the already-authenticated main connection (connection multiplexing / ControlMaster-style) for the mirror channel so password-auth setups work at all.

Happy to provide sanitized ~/.claude.json from either end, full remote-server.log, or run a specific repro on request.