BUG: Desktop SSH sessions permanently inaccessible when remote host is decommissioned; sshConfig stored server-side, local edits silently overwritten

Problem

When a Claude Desktop SSH session's remote host is permanently decommissioned, the session becomes permanently inaccessible in the Desktop with no recovery path.

What happens

1. Desktop attempts SSH connection to the dead host on every session open — there is no "open locally" fallback
2. The local session cache (%APPDATA%\Claude\claude-code-sessions\<id>\local_<sessionId>.json) contains sshConfig: { sshHost, id, source } which drives this behaviour
3. Editing the JSON has no effect — session metadata including sshConfig is stored server-side on claude.ai. The local JSON is a downstream cache that is overwritten from the server on every Desktop startup. There is no client-side handle to modify it.

Investigation

We confirmed the session data is not present in any local Electron storage:

• AppData\Roaming\Claude\IndexedDB\https_claude.ai_0.indexeddb.leveldb\ — not present
• AppData\Roaming\Claude\Local Storage\leveldb\ — not present
• AppData\Roaming\Claude\SharedStorage-wal — not present
• AppData\Roaming\Claude\DIPS-wal — not present

The local JSON file is overwritten with server state on every startup, making file-level workarounds impossible.

CLI fallback is incomplete

claude --resume <uuid> from a local directory can open the session, but presents a token-cost prompt (the session was 114.9k tokens / 1d 2h old) with no option to continue without that cost or reconnect decision. The SSH reconnection attempt also surfaces here with a forced choice. See #58591 for the related CLI cwd-scoping issue.

Proposed fix

Add a "Detach from SSH host / Open locally" action to the Desktop — either:

1. In the session context menu (right-click on a session in the list)
2. As a fallback option presented when the SSH connection fails at open time: "Could not connect to duncan@stuff-13. Open this session locally instead?"

This action would call a server-side API to clear sshConfig and update cwd to a user-specified local path, making the session re-entrant on the local machine.

Why this matters more than it appears

The session transcript and forensic data from the remote session still exist locally in ~/.claude/projects/ssh-<id>/<uuid>.jsonl — the work is not lost. But there is currently no supported path to access it through the Desktop once the host is gone. The only recovery requires:

1. Manually locating the JSONL in ~/.claude/projects/ssh-*/
2. Creating a new local project directory with the encoded Windows path
3. Copying and rewriting the JSONL with path substitution (Linux → Windows paths, including JSON escaping)
4. Then using the CLI with the token-cost prompt to actually open it

None of this is documented or supported.

Related

• #58591 — --resume hard-filtered by cwd; --cwd flag proposed (CLI layer of the same problem)
• #61589 — closed as duplicate of #58591 (our original report, before discovering the server-side storage layer)
• #61349 — memory orphaned on directory rename (same encoded-path brittleness)

Environment

• Claude Code Desktop v2.1.148
• Windows 11, host machine
• SSH remote: Raspberry Pi 5 (Linux), permanently decommissioned