[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

```shell
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//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

5. 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.

Start with the remote-server.log entries and the ccd-cli bootstrap path described in the report; reproduce the delay using the provided awk command and compare it with plain SSH startup. The issue names no source files or tests, so first identify the silent bootstrap step and where client-side logging belongs. Done means the bootstrap delay is explained and fixed or logged, with remote sessions starting without SIGTERM/reconnect loops.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.