Desktop fails to recover from mid-session SSH disconnect — reattaches to orphaned remote process instead of spawning fresh

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?

Summary
When the SSH connection to a remote server drops mid-session (e.g. ECONNRESET), Claude Desktop auto-reconnects but then incorrectly reuses the pre-crash remote server state and attempts to reattach to a process that no longer exists on the remote host. When the reattach fails, Desktop abandons the process rather than spawning a fresh one. The UI hangs silently, and empty session scaffolding accumulates on the server.
Recovery requires a full Desktop restart.
Environment

Claude Desktop version: cee98937dc257e6af64e712d71dbe4497eb82452
Remote CLI: v2.1.111
Local OS: macOS
Remote: Ubuntu 24.04.4 LTS (Hetzner VPS), user UID 1000
Model: claude-sonnet-4-6

Exact failure sequence (from ~/Library/Logs/Claude/ssh.log)
Session is running fine from 02:19:39 onward. Then:
02:50:29 [error] [SSH2Connection] Connection error: read ECONNRESET
02:50:29 [error] [RemoteServerController] SSH2 error: read ECONNRESET
02:50:29 [warn] [RemoteServerController] SSH2 connection closed
02:50:29 [info] [RemoteServerController] Auto-reconnect attempt 1 in 1000ms
02:50:29 [warn] [RemoteServerController] RPC stream closed

Desktop attempts to spawn a new process BEFORE reconnecting

02:50:29 [info] [RemoteProcess:1bf74170-...] Creating process: ...ccd-cli/2.1.111...
02:50:29 [info] [RemoteProcess:1bf74170-...] Spawning: ...
02:50:29 [error] [RemoteProcess:1bf74170-...] Spawn failed: Not connected to remote server

Reconnect succeeds

02:50:30 [info] [RemoteServerController] Ensuring server is ready ... (trigger: focus)
02:50:32 [info] [SSH2Connection] Connected to <REMOTE_IP>:22
02:50:33 [info] [BinaryDeployment] Remote: home=/home/<user>, platform=linux, arch=amd64

THE BUG

02:50:34 [info] [BinaryDeployment] Reusing existing remote server
02:50:35 [info] [BinaryDeployment] Exec channel opened to /home/<user>/.claude/remote/rpc.sock
02:50:35 [info] [RemoteServerController] Connected to remote server (5324ms, trigger: focus, reused: true)
02:50:35 [info] [RemoteServerController] Rebinding 1 live process(es)
02:50:35 [info] [RemoteProcess:1bf74170-...] Rebinding (fromSeq=0)
02:50:35 [warn] [RemoteProcess:1bf74170-...] reattach: process not found on remote
02:50:35 [warn] [RemoteProcess:1bf74170-...] Abandoning (transport lost, no reattach)
After Abandoning, no further attempts are made. Desktop sits idle. UI hangs.
~7.5 hours later, after a Desktop restart:
10:13:33 [info] [RemoteProcess:b03ad7c0-...] Creating process: ...
10:13:34 [info] [RemoteProcess:b03ad7c0-...] Spawn confirmed
A fresh Desktop launch spawns a new process with no issue. Same host, same user, same credentials — the only difference is starting from a clean client state.
Root cause (hypothesis)
Two assumptions are wrong after an SSH ECONNRESET:

Reusing existing remote server is incorrect after a transport-level disconnect. The remote server process is parented to the SSH session (via the exec channel to rpc.sock); if SSH dies, the server dies with it. Desktop's check for "server already exists" is apparently file/socket-based and doesn't verify the server process is actually still alive after reconnect.
Abandoning (transport lost, no reattach) is the wrong recovery path. If the reattach fails because the process is gone, the correct action is to spawn a new process and notify the UI — not silently drop the session.

Server-side corroboration
Confirmed on the remote host: every failed Desktop reconnect creates an empty session directory under /tmp/claude-<uid>/<project-path>/<uuid>/ with an empty tasks/ subdirectory. A working CLI session under the same tree, same user, produces a populated tasks/<hash>.output file as expected.
Failed (Desktop, after ECONNRESET):
<uuid>/tasks/ (empty)

Working (direct CLI on remote):
<uuid>/tasks/<hash>.output (30KB, 558 lines)
This matches the client-side log: Desktop never got past Abandoning, so no CLI process ever ran, so no output was ever written.
Reproduction

Connect Claude Desktop to a remote server over SSH. Confirm session is working.
Force an SSH disconnect mid-session. Easiest way: drop network briefly, or sudo pkill -HUP sshd the session server-side, or let a laptop suspend/resume with flaky network.
Observe: Desktop auto-reconnects, logs Reusing existing remote server, logs reattach: process not found on remote, logs Abandoning, then goes silent.
UI hangs. No error surfaced to the user.
Quit and relaunch Desktop → works immediately.

Workaround
SSH directly to the host and run claude from the shell. This entire bug report was drafted from a CLI session that worked normally on the same host that Desktop had hung against.
Suggested fix areas

After an SSH reconnect following a transport error (ECONNRESET, EPIPE, timeout), do not trust Reusing existing remote server — treat the remote server as dead and re-provision.
On reattach: process not found on remote, spawn a fresh process in the current session rather than abandoning.
Surface an error to the UI when a session is abandoned, instead of leaving the user staring at a spinner.

Not attached but available

main.log (23KB, Desktop main process) — happy to share if the above sequence isn't enough.
Server-side evidence files (directory listings showing empty tasks/ folders across three consecutive failed reconnect attempts).

What Should Happen?

After an SSH reconnect following a transport-level error (ECONNRESET, EPIPE, timeout), Desktop should:

1. Not trust "Reusing existing remote server" — the remote server process is parented to the SSH session and dies with it. Re-provision rather than reuse.
2. On "reattach: process not found on remote," spawn a fresh process in the current session instead of abandoning.
3. If a session must be abandoned, surface an error to the UI so the user knows to restart, rather than leaving them staring at a hung spinner.

In short: mid-session SSH drops should be recoverable without a full Desktop restart.

Error Messages/Logs

From ~/Library/Logs/Claude/ssh.log — the failure sequence:

02:50:29 [error] [SSH2Connection] Connection error: read ECONNRESET
02:50:29 [error] [RemoteServerController] SSH2 error: read ECONNRESET
02:50:29 [warn]  [RemoteServerController] SSH2 connection closed
02:50:29 [info]  [RemoteServerController] Auto-reconnect attempt 1 in 1000ms
02:50:29 [warn]  [RemoteServerController] RPC stream closed
02:50:29 [info]  [RemoteProcess:1bf74170-...] Creating process: ...ccd-cli/2.1.111...
02:50:29 [error] [RemoteProcess:1bf74170-...] Spawn failed: Not connected to remote server
02:50:30 [info]  [RemoteServerController] Ensuring server is ready (trigger: focus)
02:50:32 [info]  [SSH2Connection] Connected to <REMOTE_IP>:22
02:50:33 [info]  [BinaryDeployment] Remote: home=/home/<user>, platform=linux, arch=amd64
02:50:34 [info]  [BinaryDeployment] Reusing existing remote server   ← BUG: server died with SSH
02:50:35 [info]  [RemoteServerController] Connected to remote server (reused: true)
02:50:35 [info]  [RemoteServerController] Rebinding 1 live process(es)
02:50:35 [warn]  [RemoteProcess:1bf74170-...] reattach: process not found on remote
02:50:35 [warn]  [RemoteProcess:1bf74170-...] Abandoning (transport lost, no reattach)

[UI hangs silently. No further activity for ~7.5 hours.]

After Desktop restart:
10:13:33 [info] [RemoteProcess:b03ad7c0-...] Creating process: ...
10:13:34 [info] [RemoteProcess:b03ad7c0-...] Spawn confirmed

Steps to Reproduce

1. Connect Claude Desktop to a remote server over SSH. Confirm the session is working (messages send, responses stream, tools execute).
2. Force an SSH disconnect mid-session. Easiest reproductions:

• Let the Mac sleep/wake with flaky network
• Drop the network interface briefly
• Server-side: sudo pkill -HUP sshd targeting the session

1. Observe the auto-reconnect sequence in ~/Library/Logs/Claude/ssh.log:

• SSH2 error: read ECONNRESET
• Auto-reconnect succeeds
• [BinaryDeployment] Reusing existing remote server ← incorrect after transport-level disconnect
• [RemoteProcess:...] reattach: process not found on remote
• [RemoteProcess:...] Abandoning (transport lost, no reattach)

1. Desktop UI hangs silently. No error surfaced. No new process spawned.
2. Quit and relaunch Desktop. Reconnect to the same host. Works immediately — fresh process spawns with no issue.

Corroboration on the remote host: each hung reconnect creates an empty session directory under /tmp/claude-<uid>/<project-path>/<uuid>/ with an empty tasks/ subdirectory. A working CLI session on the same host, same user, produces a populated tasks/<hash>.output file. Client-side log confirms no process ever spawned after "Abandoning," which matches the empty server-side scaffolding.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.111 updated multiple times may not as well not sure if that didnt work too

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The bug is NOT terminal-specific — it occurs in Claude Desktop's remote SSH session management, not in CLI usage from a terminal. I selected Terminal.app because the form requires a selection.

Key diagnostic insight: the failure is in the reconnect path, not the initial connect. Initial SSH connections work perfectly. The bug triggers when an already-established session loses its SSH transport (ECONNRESET, sleep/wake, network blip) and Desktop tries to recover. Two lines in ssh.log pinpoint it:

[BinaryDeployment] Reusing existing remote server (incorrect — server died with SSH)
[RemoteProcess:...] Abandoning (transport lost, no reattach) (wrong recovery — should respawn)

Same-host same-user CLI sessions via direct SSH work fine. This entire bug report was drafted through a working CLI session on the same remote host that Desktop was hung against.

Additional troubleshooting attempted before filing this report:

• Updated Claude Desktop multiple times (approximately 5 updates). Bug persists across versions.
• Reinstalled Claude Desktop from scratch. No change.
• Cleared caches and reset Desktop configuration. No change.
• Restarted Desktop repeatedly. A restart temporarily resolves it (new process spawns cleanly on fresh launch), but the bug reproduces as soon as the SSH transport is interrupted again.
• Tried a different network. No change.
• Tried a different SSH key. No change.
• Contacted support. Issue not resolved, filing here.
• Verified the remote server is healthy: SSH works, the claude CLI on the remote host works, and CLI sessions write task output files as expected. The failure is isolated to Desktop's reconnect/reattach path.

The bug survives everything client-side short of the structural fix in the reconnect logic itself.

Happy to provide full ssh.log and main.log on request. I've redacted my remote IP and local username from the excerpt in the Error Messages field.