claude --resume hangs indefinitely on startup — account-level connector discovery stalls with no timeout, unkillable via SIGINT

Summary

claude --resume (and plain claude on session resume) hangs indefinitely on startup. The hang is unkillable via Ctrl-C (SIGINT is not honored), survives a full computer reboot, and is not fixed by connecting, disconnecting, or re-authenticating any MCP server or claude.ai connector. Diagnosis points at an account-level connector discovery/lookup call that stalls with no client-side timeout.

Environment

• Claude Code version: 2.1.204 (native install)
• OS: macOS 26.5.1 (Build 25F80), Darwin 25.5.0, arm64 (Apple Silicon)
• Terminal: iTerm2 3.6.11
• MCP servers configured: 1 local stdio (xcode, via xcrun mcpbridge) + 3 claude.ai account-level connectors (Gmail, Google Calendar, Google Drive — Scope: claude.ai config)

Steps to reproduce

1. Have at least one claude.ai connector (Gmail/Calendar/Drive) configured on the account.
2. In a project directory with existing session history, run claude --resume (or claude -r) in an interactive terminal.
3. Observe: the process hangs after loading the session list, before the picker/UI ever becomes interactive.

What I ruled out

• Not the local xcode MCP server. Debug logs (--debug-file) from a hung run show xcode connecting successfully via stdio in 58ms every time. A targeted test using claude --resume --strict-mcp-config --mcp-config '{"mcpServers":{"xcode":{"command":"xcrun","args":["mcpbridge"]}}}' (xcode only, connectors excluded) completed successfully every time.
• Not a specific claude.ai connector. Tested all connector states: all three connected, a mixed state (2 in "needs authentication," 1 connected), and all three fully disconnected. The hang reproduced identically in every state, with the same destination IPs opening each time.
• Not local process/session state. A full computer restart did not resolve it — the same hang reproduced immediately after reboot.
• Not a corrupted session transcript. The 4 session .jsonl files for the affected project were inspected directly — reasonable sizes (up to ~390KB), valid JSON per line, no corruption.
• Not raw network/DNS connectivity to Anthropic's API. curl to api.anthropic.com from the same machine during testing resolved DNS, connected, and completed a TLS handshake in ~124ms.

Diagnostic evidence

--debug-file capture from one hung run — everything stops cold right after the session list is loaded, with a quota-check API request fired but never logging a completion:

.../2026-07-08T05:18:04.233Z [DEBUG] MCP server "xcode": Starting connection with timeout of 30000ms
.../2026-07-08T05:18:04.237Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=... source=quota_check
.../2026-07-08T05:18:04.290Z [DEBUG] MCP server "xcode": Successfully connected (transport: stdio) in 58ms
.../2026-07-08T05:18:04.306Z [DEBUG] /resume: loading sessions for cwd=..., worktrees=[...]
.../2026-07-08T05:18:04.306Z [DEBUG] /resume: found 4 session files on disk
.../2026-07-08T05:18:04.522Z [DEBUG] [Bootstrap] Fetch ok
.../2026-07-08T05:18:04.523Z [DEBUG] [Bootstrap] Cache unchanged, skipping write
(nothing further logged; process never becomes interactive)

Live-process inspection (same machine, direct ps/lsof/sample access to the hung PID) was repeated across three different connector states and showed the identical signature each time:

• lsof -p <pid> -a -i always shows several ESTABLISHED TCP sockets to Anthropic endpoints plus two connections to Google-hosted infrastructure: one IPv4 whose PTR resolves via *.bc.googleusercontent.com (forward IP in the 35.190.x.x GCP anycast range) and one IPv6 in the 2600:1901::/32 GCP allocation. These sockets are present and ESTABLISHED even with all three Google connectors fully disconnected on the account.
• sample <pid> 5 (macOS stack sampler, 1ms interval, 5s duration) on the live hung process shows the runtime's dedicated HTTP Client thread 100% parked in kevent64 (libuv/kqueue event-wait) for the entire sampling window — i.e., genuinely blocked waiting on a socket read event that never arrives, not CPU-spinning. No thread shows any request timeout firing.
• claude --resume --strict-mcp-config (which skips the account-level MCP/connector configuration lookup, not just individual server connections) reliably avoids the hang and resumes normally, every time, across all tested connector states.

Expected behavior

claude --resume should either complete promptly or fail visibly (with a clear error) within a bounded time, even if a backend connector-discovery call is slow or unreachable. It should not hang indefinitely with no timeout, and it should honor Ctrl-C (SIGINT) so the user can at least recover without a hard kill -9.

Suggested areas to look at

• Whatever call is responsible for enumerating the account's configured claude.ai connectors at startup appears to have no timeout and is not cancelable via SIGINT.
• Given the hang reproduces identically regardless of individual connector connect/disconnect/auth state, the stalling call is likely the connector list/discovery request itself rather than any specific connector's MCP handshake.

Happy to provide the full --debug-file log or additional sample/lsof captures if useful — captured during live reproduction and can regenerate.