Feature request: Claude Desktop SSH remote — session should survive client disconnect (reconnect/resume)
When Claude Desktop's SSH remote client disconnects — intentional quit, network drop, laptop lid close — the Claude Code process on the remote server terminates with it. There's no way to reconnect and pick up where you left off.
Verified this today by starting a long-running background bash script (logging a tick every 30s to a file) via the SSH remote session, then disconnecting the client. On reconnect: the bash process was still running and logging fine, but the Claude Code session itself was gone — no way to resume the conversation or see the in-flight tool calls.
For comparison, Codex CLI keeps the session alive server-side; reconnecting reattaches to it, essentially tmux-style. The current workaround for Claude Code is to manually wrap claude inside tmux before connecting, which sidesteps the integrated SSH remote feature entirely.
Expected behavior: the server-side Claude Code session stays alive on client disconnect, and Claude Desktop reattaches to the existing session on reconnect. A --detach/--attach CLI pair would also cover headless cases.
Environment:
- Local client: Claude for Mac 1.3109.0 (35cbf6)
- Remote: Claude Code 2.1.112 on Linux
Related: #49644 (Terminal panel disabled in remote sessions)
Showing cached comments. Read the full discussion on GitHub ↗
13 Comments
+1, this exact scenario is my primary use case. I'm running a remote dev environment on a cloud instance (Ubuntu 24.04) with full toolchain installed (Node, Go, custom CLIs, project files). I want to use Claude Desktop's SSH feature as the primary client because it's the cleanest architecture: UI on my Mac, environment fully on the server.
Setup:
Current behavior is exactly what's described: when I quit Claude Desktop, the remote ccd-cli process terminates and the session is gone. Mobile and web clients (via /remote-control from inside the SSH session) lose access immediately as soon as the desktop app closes, because the desktop app is acting as a relay between the API and the remote process.
The workaround of running claude inside tmux over a manual SSH connection works, but it defeats the entire purpose of the integrated SSH feature — at that point the desktop app is just a worse terminal.
Expected behavior: closing the desktop app should leave the remote ccd-cli process running, and reopening should reattach to it (the way Codex CLI does, as the original report mentions). Bonus: this would also fix the gap where mobile/web access dies when the laptop closes.
Would really appreciate prioritization on this — it's the missing piece that makes the SSH remote feature actually compete with tmux+CLI for serious remote dev work.
+1
+1
+1 Would be nice if the sessions started through ssh also showed up in
claude agentsin the remote ...Same here. Windows 11, Claude Code Desktop with SSH host = Mac mini (macOS 26.5, Apple Silicon). Session works fine with Windows Desktop open, but closing Windows kills the session on the Mac side — iPhone still shows it as "Connected" but messages time out or render extremely slowly. Sessions started directly via Mac Claude Code Desktop with /rc work perfectly. Suggests the issue is specifically in Windows Desktop's SSH-host session lifecycle.
+1 I moved my agents of my main machine and the idea behind that was to not have my Mac constantly open. Especially while traveling this is becoming cumbersome. In an ideal world I can just pick up from my phone when I close my laptop and vise versa.
+1
Codex desktop does this well, and this is a big limitation of Claude desktop
A server-hosted angle: when the remote host is a server that's always on, persistence needs no new infrastructure. The reason a session would otherwise have to move to Anthropic's cloud to persist is that a personal machine might sleep or shut down — but a server doesn't. So the remote agent is being killed on client disconnect when it could just keep running where it already is.
Concrete ask: a per-remote opt-in — "keep the session alive on disconnect" — that leaves the remote agent running on the server instead of killing it when the client goes away. That's all I'd need: with Remote Control already on, a surviving session shows back up in the session list / web / mobile on its own, so there's nothing extra to build for reattach.
Setup: Desktop (Max) → SSH → always-on Linux server,
ccd-cli 2.1.215.Untested theory, grain of salt: the installed binaries carry some reattach/persistence-named symbols and env flags that might be relevant plumbing — a
reattachRPC (ReattachParams/ReattachResult), plusCLAUDE_CODE_FORCE_SESSION_PERSISTENCE,CLAUDE_BRIDGE_REATTACH_SESSION/_SEQ,CLAUDE_CODE_RESUME_SOURCE_ALIVE,onTransportPersistence*. Haven't tested whether they're wired for this case or only for transient reconnects — just a possible starting point.Happy to test a flagged build.
+1
+1 it's a big miss that this is supported in ChatGPT Desktop and not in Claude Desktop
+1
Until this lands natively, the reliable pattern is a persistence layer on the server side: run the CLI inside a detachable session (tmux, or shpool which is lighter), so the SSH client dropping doesn't SIGHUP the agent. You reattach and the conversation is intact.
Disclosure: I maintain Session Kit (https://github.com/dob323/session-kit), an MIT-licensed layer on top of shpool built for this exact Claude-Code-over-SSH case. Beyond surviving disconnects it adds per-session names, a "needs your reply" state, and identity checks so reattaching to many agents stays sane. Public beta, Linux/macOS.