›_ Claude Code Issues
Claude Code Issues / #75601

[Bug] First session after idle hangs indefinitely at init; starting ANY new session instantly unblocks it

Open 💬 0 comments Opened Jul 8, 2026 by ansoncake62-cmd

[Bug] First session after idle hangs indefinitely at init; starting ANY new session instantly unblocks it

Environment

  • Claude Code v2.1.197–2.1.204 (native install, autoUpdates=false for CLI; desktop app auto-updates)
  • macOS 15.7.7 (24G720), x86_64
  • Claude Pro plan (claude.ai login)
  • Entry points affected: desktop app (CCD sessions), terminal CLI (claude, plain and with --channels plugin), non-interactive claude -p
  • Claude desktop app running concurrently (v1.19367.0)

Summary

The first Claude Code session started after a period of idleness frequently hangs during the init phase — indefinitely, not a fixed timeout (observed 2 min up to 14 min 09 s, and telemetry shows historic worst of 768 s). The hung process sits at 0% CPU with its main thread idle in kevent64, holding several ESTABLISHED HTTPS connections to Anthropic (160.79.104.x). It never recovers on its own.

Starting any new session immediately unblocks the hung one — reproduced 5 times (4 by the user in normal use, 1 instrumented). The rescuing session itself starts normally (~20–50 s). This suggests sessions serialize on a shared resource (daemon/IPC/credential refresh?) that only a fresh session startup resets.

Evidence

1. Official start-timing telemetry (~/Library/Logs/Claude/main.log)

[CCD start-timing] ... preflight=3ms worktree=0ms mcp=24ms query=1ms enqueue=2ms
init=128057ms first_assistant=4566ms total_to_assistant=132653ms cache_hit=true mcp_count=10

Local MCP registration is 24 ms; first-token generation 4.5 s; all lost time is inside init. Historic values from the same log: 20.9 s / 24 s / 31 s / 36 s / 53 s (healthy days) → 86 s / 92 s → 128 s → 488 s / 604 s / 768 s (worst).

2. Instrumented reproduction (non-interactive)

  • claude -p "hi" (timed): hung with no output, then completed the moment the user opened a new desktop session — total 14 min 09 s, CPU time 2.6 s (0%). Output was a normal reply; exit 0.
  • Earlier same day: probe1 (claude --debug -p hi) hung ~98 s; probe2 launched at t+98 s; probe1 completed at t+102 s (4 s after probe2 started).

3. Stack sample of a hung process (sample <pid> 5)

Main thread parked in kevent64 (event loop idle, waiting on I/O); all Bun pool threads in __ulock_wait2. No CPU work, no local lock contention visible. lsof: 5–12 ESTABLISHED TCP connections to 160.79.104.10:443 (Anthropic), no other endpoints pending.

4. Ruled out locally (all measured)

  • Local MCP servers (register in 24 ms; claude mcp list completes in 3.1 s)
  • npx-based servers (none), shell init (0.6 s), CLI cold start (--version 0.13 s)
  • Network (api.anthropic.com RTT 0.1 s), DNS
  • iCloud vault I/O (0.003 s reads), transcript history size (11 MB)
  • claude.ai connectors: authorizing a stuck-unauthenticated connector did NOT help; disableClaudeAiConnectors: true did NOT help (the claude -p 14-min hang above ran with it enabled)
  • Usage-limit throttling (reproduced right after weekly window reset)

Repro (as reliable as we can make an intermittent bug)

  1. macOS with the Claude desktop app running; several sessions opened and closed over days.
  2. Leave the machine idle for a while (hours).
  3. Open one new session (any entry point: desktop conversation, claude, or claude -p "hi").
  4. Observe it hang at init (spinner; -p produces nothing). It will not recover by itself (≥14 min observed).
  5. Start a second session — the first completes within seconds.

Impact

Every "first session of the day" costs the user 2–14 minutes unless they know the workaround (start a second session to kick the first). Users who don't know it just wait — ours waited 4 minutes repeatedly and nearly abandoned the tool.

Notes

  • Feels correlated with the desktop app's shared background services: hangs began appearing alongside heavy desktop-app use, and the desktop app auto-updated twice that day (2.1.202 → 2.1.204), once killing the user's first message mid-flight (beforeQuitForUpdate, hadFirstResponse=false).
  • Happy to provide the full stack samples, lsof output, and log excerpts.

View original on GitHub ↗