~10 minute delay before first response in new session (Windows, MSIX) — API call itself is fast

Follow-up with a concrete timing breakdown

I found the exact session file for the slow run (~/.claude/projects/<project>/<sessionId>.jsonl), and it lines up with lastSessionId recorded in ~/.claude.json for this project at the time:

• sessionId: 3f808196-de7f-4ecc-9646-4317f0055394
• The underlying claude process was launched at 12:57:35 (local).
• The first user message entry in that session's JSONL is timestamped 10:07:37 UTC (13:07:37 local).
• The assistant response entries are timestamped 10:07:47–10:07:52 UTC — i.e. ~10-15 seconds after the message was actually sent to the model.

So essentially all of the ~9m48s delay happened before the user message was ever dispatched to the API — purely in local session bootstrap (MCP server setup / hook execution / whatever happens between process launch and the first logged user turn). Once the message was actually sent, the round trip was fast, consistent with the lastAPIDuration (~12.4s) vs lastDuration (many minutes) gap I mentioned in the original report.

Hope the session ID lets someone correlate with server-side telemetry for that request.

Internal app log excerpt for the same window (from the desktop app's own main.log, not external guessing)

Grepping %AppData%\Claude\logs\main.log for the exact delay window (12:57–13:08 local) shows the app doing plugin/skill/MCP resync right around then:

[RemotePluginManager] Starting remote plugins sync (quick — skipping user-plugin cleanup)
[RemotePluginManager] Sync complete: 0 downloaded, 0 removed, 0 orphans cleaned
[SkillsPlugin] Starting skills sync
[SkillsPlugin] Found 10 enabled skills
[SkillsPlugin] Sync complete: 0 downloaded, 0 failed, 0 removed, 0 orphans cleaned
[PluginsFetcher] fetchAutoInstalledPlugins: 1 plugins
[CCD] LocalSessions.replaceEnabledMcpTools: sessionId=..., toolCount=74
[CCD] LocalSessions.replaceEnabledMcpTools: sessionId=..., toolCount=77
[CCD] LocalSessions.replaceRemoteMcpServers: sessionId=..., serverCount=6
[CCD] [replaceEnabledMcpTools] Calling SDK with 15 total servers {{ ... }}
[CCD] [replaceRemoteMcpServers] Calling SDK with 15 total servers {{ ... }}
[reconcileServers] deleted=[] created=[plugins (internal), skills (internal), cowork-onboarding (internal), dev-debug (internal), Claude Code iOS Simulator (internal), Claude Code Android Emulator (internal), computer-use (internal), Window Halo (internal), Framebuffer (internal)] total=15

None of these individually report as slow (sync completes report 0 downloaded/0 failed etc.), but they are all happening in the same narrow window where the user message sat un-dispatched for ~9m48s (see previous comment with exact timestamps). My guess is the actual bottleneck is somewhere in how these get sequenced/awaited relative to each other and to the MCP tool-list rebuild (15 servers / 74-77 tools), rather than any single one of them being individually slow — but that's a guess on my part; the log lines above are the literal facts, not my interpretation.

Important generalization: this is not limited to literally new chats

I reproduced this again in what I considered an existing, not-closed conversation (just resumed it after being idle for a while). The desktop app's main.log shows:

2026-08-11 14:40:39 [info] Starting local session local_db9c8358-b738-4421-9f22-3aaba3f9a099 in G:\Work\confluence-tools

So from the user side it feels like continuing an existing conversation, but under the hood the app spun up a brand-new local session process for it — and that's exactly the kind of event that pays the ~10 minute tax described above. So the real trigger isn't "opening a new chat" per se, it's "Claude Code needs to start/re-establish a local session process," which can happen any time a conversation has been idle for a while and you send another message in it, not only when you explicitly start a fresh chat.

This makes the practical impact worse than the title suggests: it's not a one-time cold-start cost, it recurs any time a conversation goes idle and gets resumed — which is presumably why it keeps breaking the OP's VS Code integration (1-minute timeout) throughout the day, not just on first launch.