[BUG] Remote session hangs on "Starting session…" — server logs connection, then 50–118s of silence, then SIGTERM and reconnect loop

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?

Remote sessions from the Claude desktop app to a Linux host hang on "Starting session…" for 1–2 minutes, then get killed and retried, sometimes never reaching a usable session. Other attempts hang at "Setting up plugins…" instead, or surface a "Not connected to remote server" error.

The remote server accepts the connection and logs it, but then nothing happens for 50–118 seconds before ccd-cli is spawned. In several cases ccd-cli is later terminated with exit code 143 (SIGTERM) and the client reconnects, producing a connect → hang → kill → reconnect loop.

Crucially, neither side writes anything during the silent window: the remote server log has no entries, and the Windows client writes no files at all during the same period.

Key comparison: installing Claude Code as a plain CLI on the same host and connecting over ordinary SSH across the same network path starts in seconds. Same host, same path, same account, same project directory — only the remote session layer is affected.

What Should Happen?

Either the session starts promptly, or the delay is attributable to a logged step. A 50–118 second window with no log output on either side gives users nothing to act on.

Error Messages/Logs

Client error dialog (View details):
    Not connected to remote server
Session footer: "Connection failed"

--- Remote server log: gaps >2s between consecutive lines ---
 55s -> 2026/08/22 14:41:26 [Server] New connection from: @
 50s -> 2026/08/22 14:42:16 [process.Manager] Process 3d1535c2-... started, PID=2775716, command=/root/.claude/remote/ccd-cl...
134s -> 2026/08/22 14:53:04 [process.Manager] Process 3d1535c2-... exited with code 143
2322s -> 2026/08/22 15:31:51 [Server] New connection from: @
118s -> 2026/08/22 15:33:52 [process.Manager] Process 00319214-... started, PID=2856675, command=/root/.claude/remote/ccd-cl...

Two separate sessions: "New connection" is logged, then 50s and 118s
respectively pass with ZERO log output before ccd-cli is started.

--- Reconnect loop ---
15:41:27  [Server] New connection from: @
15:43:35  [Server] Connection closed: @
15:43:58  [Server] New connection from: @
15:55:15  [Server] Connection closed: @
16:04:15  [Server] New connection from: @

--- Intermittent: a session that DID work, then dropped ---
13:38:34  a dozen git/realpath processes spawned and "exited with code 0"
          within the same second -- no gaps, working normally
13:39:01  [Server] Connection closed: @
13:41:32  [Server] New connection from: @
13:41:34  [process.Manager] Process 8d08fefc-... exited with code 143
13:42:01  [Server] Connection closed: @

--- No client-side log exists for the hang ---
PS> Get-ChildItem "$env:LOCALAPPDATA\Claude-Data" -Recurse -File |
      Where LastWriteTime -gt (Get-Date).AddHours(-2)
    (no results, despite repeated session attempts in that window)

Only logs under %LOCALAPPDATA%\claude-cli-nodejs\ are two days old
and unrelated. There is no client-side log covering the bootstrap at all.

Steps to Reproduce

1. Connect the Claude desktop app to a remote Linux host (Ubuntu 24.04)
2. Open a session in a project directory and send any message (e.g. "test")
3. Observe "Starting session…" persisting for 1–2+ minutes, or hanging at "Setting up plugins…"
4. On the host, inspect ~/.claude/remote/run/<id>/remote-server.log and note the gap between "[Server] New connection" and the ccd-cli process start:

awk '{split($2,t,":"); s=t[1]3600+t[2]60+t[3];
if(p!="" && s-p>2) printf "%3ds -> %s\n", s-p, substr($0,1,140);
p=s}' remote-server.log

1. For contrast: SSH into the same host, run claude in the same directory — the CLI starts in seconds.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.241 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related but distinct: #74793 reports drops during ACTIVE sessions (heartbeat
timing out on a healthy-but-quiet SSH transport). This report is about the
BOOTSTRAP phase — the session never starts; there is a 50-118s silent window
between "[Server] New connection" and ccd-cli even being spawned, followed by
SIGTERM. Possibly a shared root cause in the remote session layer.

This is a REMOTE session: Claude desktop app on Windows 11 connecting to a
remote Ubuntu 24.04 host. Version note: CLI on the host is 2.1.241, while the
remote runtime pushed by the desktop app is ccd-cli 2.1.237.

Geography/latency: client in Jakarta, host in Europe. ~205 ms RTT on a
direct Tailscale path (verified direct, not DERP relay).

RULED OUT during investigation, each measured:

• Host network egress: curl https://api.anthropic.com returns in 0.08-0.12s
• IPv6/DNS: IPv4-only and default paths both fast, no AAAA timeout
• Tailscale relay: connection is direct, not DERP; MTU normalized, no change
• Disk/inodes: 180GB free, 4% inode usage
• MCP auth: probes complete in ~3.7s in parallel; cache shrinks to 3 entries
• Plugin marketplace: all 23 entries in enabledPlugins are false on the client
• git in the project: observed gaps precede "started" lines, not "exited" lines,

so they are inter-command idle time, not slow git

• Session history: ~20MB of older .jsonl archived out of ~/.claude/projects/,

retested, no change

• The host itself: the CLI on the same host over the same path starts in seconds

SPECULATIVE (cannot be confirmed from outside):
Since plain SSH across the identical 205ms path is responsive while the remote
bootstrap is not, the bootstrap handshake may be chatty -- many sequential
round-trips, invisible at 20ms but compounding at 205ms. If the client timeout
is calibrated for low-latency links, a cross-continent connection could exceed
it before the handshake completes, matching the observed SIGTERM-then-retry.

NOTE: there appears to be no client-side log for remote session bootstrap.
Adding one would make this class of issue self-diagnosable.