[BUG] Cold start warming takes ~155s on every Claude Desktop launch (SSH)

Resolved 💬 1 comment Opened Apr 22, 2026 by machmikal79 Closed May 26, 2026

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?

Every time I open Claude Desktop on macOS with a remote Cowork session (SSH to my own Linux server), the first message takes ~3 minutes to get a response. This happens on every fresh launch of the app — not only the first one after installation.

Timing from ~/Library/Logs/Claude/main.log:

[CCD] Session local_xxx warmed successfully in 155923ms
[CCD start-timing] ... query=157908ms ccd_overhead=158375ms total_to_assistant=162016ms ... mcp_count=0

Steps to reproduce:

  1. Cmd+Q Claude Desktop
  2. Reopen the app
  3. Send any short message like "hi"
  4. Observe ~3 min before the assistant starts responding

What I already tried (no change in warming time):

  • Disconnected Google Drive connector
  • Deleted 12 duplicate anthropic-skills plugin copies on the remote server at /home/claude/.claude/remote/plugins/
  • Confirmed the lag is NOT on the server side — the Go remote-server.log shows a ~3 min gap between SSH connect and process.spawn, where the Mac client is only pinging

The 155s warming appears to happen inside the macOS app before it even asks the remote server to spawn the CLI.

What Should Happen?

Cold start (app launch + first message) should complete in under 30 seconds, not 2–3 minutes. The CCD warming phase should either be faster, cached between launches, or run in background so the user can type while it finishes.

Error Messages/Logs

=== ~/Library/Logs/Claude/main.log ===
[CCD] Passing 8 plugin(s) to SDK (skills: 1, remote: 0, local: 7)
[CCD] [replaceRemoteMcpServers] Calling SDK with 6 total servers:
  serverNames: [ 'Google Drive', 'Claude in Chrome', 'mcp-registry',
                 'computer-use', 'ccd_session', 'scheduled-tasks' ]
[RemotePluginSync] Synced 209 file(s) from .../skills-plugin/... → /home/claude/.claude/remote/plugins/<hash>
[CCD] Session local_xxx warmed successfully in 155923ms
[CCD start-timing] preflight=447ms worktree=0ms mcp=20ms query=157908ms enqueue=6ms init=1145ms first_assistant=2490ms | ccd_overhead=158375ms total_to_init=159526ms total_to_assistant=162016ms cache_hit=false worktree=false mcp_count=0

=== Remote server log ===
22:35:55 New connection from: @
22:35:55 Connection closed: @
22:35:55 New connection from: @
22:36:01 RPC request: method=files.read  (2 reads)
22:39:08 RPC request: method=process.spawn   <-- 3m 13s gap, client-side warming

Steps to Reproduce

  1. On macOS, have Claude Desktop configured with a remote Cowork session (SSH to a Linux server).
  2. Fully quit Claude Desktop with Cmd+Q.
  3. Reopen Claude Desktop. It auto-reconnects to the remote session.
  4. Send any short message (e.g. "hi") to the assistant.
  5. Measure time until the assistant starts responding.

Expected: first token within ~30 seconds.
Observed: first token after ~160 seconds (2m 40s).

The delay is reproducible on every cold start. Subsequent messages in the same open app are fast.

Confirmed via logs that the time is spent inside the macOS client during "CCD warming" (see main.log line: "[CCD] Session ... warmed successfully in 155923ms"), NOT on the remote server. The remote server log shows it only receives the process.spawn RPC 3+ minutes after the SSH connection was established.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown exact version, but the app was responsive (<30s cold start) until ~2026-04-21 when delays started.

Claude Code Version

Claude Code CLI (local Mac): 2.1.90 Claude Desktop app: 1.3883.0 (93ff6c), built 2026-04-21T17:24:01Z Remote CLI on SSH server: 2.1.111 (v2.1.111 cached at /home/claude/.claude/remote/ccd-cli/) Remote server binary: claude-ssh 9a871e263f5ad97516c97c8c8129f94990635ae7, built 2026-04-21T17:07:27Z Note: local CLI (2.1.90) and remote CLI (2.1.111) are on different versions — unsure if related to the warming delay.

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment specifics

  • Connection mode: Cowork remote SSH (not local CLI)
  • Remote host: own Linux server (Ubuntu) via SSH on port 22
  • macOS version: [pon la salida de sw_vers -productVersion]

Version mismatch observed

Local Claude Code CLI: 2.1.90
Remote CLI on server: 2.1.111

Unclear if this version drift is related to the warming delay, but flagging it in case it is.

What was NOT the cause (already tested)

  • Disconnected Google Drive connector → no improvement in warming time
  • Deleted 12 stale duplicate anthropic-skills plugin copies under /home/claude/.claude/remote/plugins/ on the remote (freed 42 MB) → no improvement
  • Confirmed remote server is NOT the bottleneck: remote-server.log shows a ~3 min gap between New connection and process.spawn where the Mac client is only pinging and doing 2–3 files.read calls

Workaround I'm using

Not Cmd+Q'ing Claude Desktop between uses — only closing the window. That avoids paying the 155s warming for every message. But this means I can't fully close the app without suffering the delay on next launch.

Other MCPs still active

Claude in Chrome, computer-use, mcp-registry, ccd_session, scheduled-tasks (these are default/built-in, not user-configured).

Severity

Medium — not blocking work, but adds ~3 min friction per app launch. Over a day of multiple launches this is significant.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗