[BUG] Desktop SSH remote: session init phase blocks on a ~600000ms timeout before succeeding (8/13 sessions affected)
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?
<html>
<body>
<!--StartFragment--><p dir="ltr">On Windows Claude Desktop driving Claude Code on a remote Linux host over SSH, creating a session
intermittently hangs for 10-12 minutes on "Starting Claude Code…" before succeeding normally.</p>
<p dir="ltr">The <code>[CCD start-timing]</code> telemetry shows the delay is entirely inside the <code>init</code> phase, and the
values are clustered on what looks like a hardcoded 600000ms timeout rather than being distributed:</p>
<div dir="ltr">
Timestamp (local) | init | first_assistant
-- | -- | --
2026-08-24 19:35:59 | 84ms | 6723ms
2026-08-26 23:04:09 | 880ms | 4654ms
2026-08-27 12:14:36 | 2185ms | 2187ms
2026-08-26 15:20:11 | 5397ms | 3675ms
2026-08-26 15:20:41 | 459107ms | 21086ms
2026-08-31 21:18:21 | 600591ms | 3301ms
2026-09-02 19:04:13 | 600892ms | 1955ms
2026-08-31 23:51:37 | 601836ms | 3387ms
2026-09-02 18:33:59 | 602243ms | 3097ms
2026-08-31 23:25:11 | 602251ms | 11567ms
2026-09-02 10:30:40 | 602588ms | 2058ms
2026-08-24 18:23:16 | 603157ms | 4165ms
2026-09-02 18:23:19 | 720716ms | 4268ms
</div>
<p dir="ltr" style="">Two things stand out:</p>
<ol dir="ltr" style="">
<li><strong>The distribution is bimodal with nothing in between.</strong> Healthy sessions finish <code>init</code> in
84-5397ms. Affected sessions never come in under 600591ms. Six of the eight affected runs land
within 600591-603157ms, i.e. 600000ms + overhead. This looks like an await that never settles
and is only released by a 600s ceiling, not like general slowness.</li>
<li><strong>Everything after <code>init</code> is healthy.</strong> <code>first_assistant</code> is 2-21s in every single run,
including the 720716ms one. Once <code>init</code> returns, the session works perfectly.</li>
</ol>
<p dir="ltr" style="">Affected rate is 8/13 (62%) over the sampled period.</p>
<h3 dir="ltr" style="">Why this is hard to notice</h3>
<p dir="ltr" style=""><code>CycleHealth</code> reports these runs as healthy, so nothing is logged at <code>error</code> level:</p>
<div role="group" aria-label="코드" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">[CCD CycleHealth] healthy cycle for local_<redacted> (605s, hadFirstResponse=true)</code></pre></div></div>
<p dir="ltr" style="">A 605-second cycle being classified as healthy is arguably a second, separate bug — it means users
have no error to search for and no signal that anything went wrong.</p><!--EndFragment-->
</body>
</html>
What Should Happen?
init should either complete promptly or fail fast with a diagnosable error. It should not block on a 600s ceiling and then proceed as if nothing happened.
Error Messages/Logs
No errors at error level for the delay itself. One related error does appear, on a session ID that is subsequently abandoned:
Error occurred in handler for '...LocalSessions_getSupportedCommands':
Error: No command source for session local_<A> [ccdErrorCategory:unknown]
at e.getSupportedCommands (app.asar/.vite/build/index2.chunk-<hash>.js:1:557432)
at Object.getSupportedCommands (app.asar/.vite/build/index.chunk-<hash>.js:1:38237)
Possibly relevant: the session that gets warmed up is not the session that actually starts. In every observed startup, WarmLifecycle warms session A, registers 900s/1800s idle timeouts against A, and then LocalSessions.start starts a different session B:
18:54:03 [WarmLifecycle:session] Warming up session local_<A>
18:54:03 [WarmLifecycle:preview] Warming up session local_<A>
18:54:07 LocalSessions.getSSHGitInfo / getSSHLocalBranches (for <A>)
18:54:08 [WarmLifecycle:session] Starting idle timeout for local_<A>: 900s
18:54:08 [WarmLifecycle:preview] Starting idle timeout for local_<A>: 1800s
18:54:09 LocalSessions.start:
18:54:09 Starting local session local_<B> in /home/<user>/dev/<project>
The getSupportedCommands failure above is raised against <A> — the session that never runs. If init is awaiting a response keyed to a session ID that was discarded, that would explain an await that only unblocks on the outer timeout.
Also, replaceRemoteMcpServers is called with serverCount=1 but passes 7 servers to the SDK, with visualize appearing twice:
[CCD] LocalSessions.replaceRemoteMcpServers: sessionId=local_<B>, serverCount=1
[CCD] [replaceRemoteMcpServers] Calling SDK with 7 total servers {
serverNames: [ 'visualize', 'claude-in-chrome', 'mcp-registry', 'visualize',
'ccd_session', 'ccd_session_mgmt', 'scheduled-tasks', [length]: 7 ]
}
Steps to Reproduce
Windows Claude Desktop, add an SSH remote host (Linux, key auth). Terminal SSH to the same host works normally.
Open a Code session against a project on that host and send a prompt.
Repeat over a working day. Roughly 6 in 10 sessions sit on "Starting Claude Code…" for 10-12 minutes, then respond normally.
Check %LOCALAPPDATA%\Claude\logs\main.log for [CCD start-timing] and compare init= values.
Things ruled out
Each of these was checked and is not the cause:
SSH / auth / remote command execution. During the stall, ssh.log shows realpath and git RemoteProcess calls completing in 20-60ms each. SSH itself is fast throughout.
Remote CLI spawn. ps on the remote during a stall shows exactly one server --serve, one server --bridge, and live ccd-cli/2.1.255 processes consuming CPU. Spawn succeeds. This distinguishes it from #52790, where no server.spawn RPC is ever issued.
Process accumulation. No stacked --serve generations, so not #54179.
SSH connection flooding / MaxStartups. No connection storm in ssh.log, so not #48530.
MCP servers. Affected runs occur with init_mcp=connected:7/failed:0 and with init_mcp=connected:0/failed:7 alike. mcp=4-5ms in every run. Setting MCP_TIMEOUT and CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT changed nothing. Disabling claude.ai connectors changed nothing (and none are connected).
Cache. Affected runs occur with both cache_hit=true and cache_hit=false.
Transcript / project history size. Largest project history is 56MB; the project in use is 13MB. /stats (worker) scanned 59/59 transcript files completes without delay.
Screen lock / unlock. ssh.log logs powerMonitor:unlock; probing SSH controllers several times a day, but affected sessions do not correlate: the 18:23 and 18:33 stalls began roughly two hours after the preceding unlock, and many unlocks are followed by healthy sessions.
Network interface changes. No network-interface change detected entries at all, so the utun-flap trigger described in #52734 does not apply here.
Error Messages/Logs
init should either complete promptly or fail fast with a diagnosable error. It should not block on a 600s ceiling and then proceed as if nothing happened.
Error Messages/Logs
No errors at error level for the delay itself. One related error does appear, on a session ID that is subsequently abandoned:
Error occurred in handler for '...LocalSessions_getSupportedCommands':
Error: No command source for session local_<A> [ccdErrorCategory:unknown]
at e.getSupportedCommands (app.asar/.vite/build/index2.chunk-<hash>.js:1:557432)
at Object.getSupportedCommands (app.asar/.vite/build/index.chunk-<hash>.js:1:38237)
Possibly relevant: the session that gets warmed up is not the session that actually starts. In every observed startup, WarmLifecycle warms session A, registers 900s/1800s idle timeouts against A, and then LocalSessions.start starts a different session B:
18:54:03 [WarmLifecycle:session] Warming up session local_<A>
18:54:03 [WarmLifecycle:preview] Warming up session local_<A>
18:54:07 LocalSessions.getSSHGitInfo / getSSHLocalBranches (for <A>)
18:54:08 [WarmLifecycle:session] Starting idle timeout for local_<A>: 900s
18:54:08 [WarmLifecycle:preview] Starting idle timeout for local_<A>: 1800s
18:54:09 LocalSessions.start:
18:54:09 Starting local session local_<B> in /home/<user>/dev/<project>
The getSupportedCommands failure above is raised against <A> — the session that never runs. If init is awaiting a response keyed to a session ID that was discarded, that would explain an await that only unblocks on the outer timeout.
Also, replaceRemoteMcpServers is called with serverCount=1 but passes 7 servers to the SDK, with visualize appearing twice:
[CCD] LocalSessions.replaceRemoteMcpServers: sessionId=local_<B>, serverCount=1
[CCD] [replaceRemoteMcpServers] Calling SDK with 7 total servers {
serverNames: [ 'visualize', 'claude-in-chrome', 'mcp-registry', 'visualize',
'ccd_session', 'ccd_session_mgmt', 'scheduled-tasks', [length]: 7 ]
}Steps to Reproduce
Windows Claude Desktop, add an SSH remote host (Linux, key auth). Terminal SSH to the same host works normally.
Open a Code session against a project on that host and send a prompt.
Repeat over a working day. Roughly 6 in 10 sessions sit on "Starting Claude Code…" for 10-12 minutes, then respond normally.
Check %LOCALAPPDATA%\Claude\logs\main.log for [CCD start-timing] and compare init= values.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Desktop: 1.40609.1.0 (Windows, MSIX / C:\Program Files\WindowsApps\Claude_1.40609.1.0_x64__<pkg>) CCD version: 2.1.255 Remote CLI: ~/.claude/remote/ccd-cli/2.1.255 Remote: Linux, reached over SSH on a private network by IP Terminal SSH + claude CLI on the same remote host: consistently fast, no stalls
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_