[BUG] Claude Code 2.1.252 subprocess hangs indefinitely on socket handoff — host reports misleading 60s 'authentication and network connectivity' timeout

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?

**When Claude Code is launched from an IDE extension host (reproduced in both the Antigravity IDE extension and the official VS Code extension, both bundling 2.1.252), the spawned claude subprocess completes all initialization normally — CA cert/mTLS setup, skill loading, MCP proxy connections to mcp-proxy.anthropic.com (all 6-7 claude.ai connectors: Slack, Gmail, Calendar, Drive, Granola, Zoom, Atlassian), policy limits fetch, and an atomic .claude.json write — all within 1-3 seconds of spawn. After that it goes completely idle: no further log output at all. Exactly ~60,000ms after the spawn call, the host extension kills it and reports:

Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

This error text is misleading. claude auth status returns loggedIn: true in every case tested, and every network call the subprocess itself makes completes in under 2 seconds. The actual bottleneck is entirely inside the ~55-second silent gap between "MCP servers connected" and the forced kill.

Direct evidence from sampling the live process during this silent window (sample <pid> 5): the main thread spends 4268 of 4339 samples (98%) parked in kevent64 — i.e. cleanly idle in its event loop, waiting for the next input event. It is not deadlocked, not spinning, not CPU-bound. It is correctly waiting for its next instruction message via the UDS socket it opened ([uds-messaging] Listening: /tmp/cc-socks/<pid>.sock) — and that message never arrives. Only when the host extension's kill/interrupt signal arrives does the subprocess "wake up" and run its normal teardown sequence**

What Should Happen?

The extension host's message handoff to the spawned subprocess over /tmp/cc-socks/<pid>.sock should land promptly after the subprocess signals it's listening, allowing the session to proceed normally — as it does in the working case (Claude Desktop's own bundled Claude Code panel, version 2.1.247, which does not exhibit this hang on the same machine). If the handoff genuinely cannot be delivered, the subprocess/host should fail fast with an accurate error rather than waiting the full 60 seconds and reporting a misleading "authentication and network connectivity" message.

Error Messages/Logs

[error] Error spawning Claude (on channel <id>): Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity
[error] Failed to load config cache: Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

[DEBUG] MCP server "claude.ai Granola": Successfully connected (transport: claudeai-proxy) in ~1400ms
[DEBUG] MCP server "claude.ai Slack": Successfully connected (transport: claudeai-proxy) in ~1700ms
[DEBUG] File /Users/<user>/.claude.json written atomically
   <complete silence for ~55s>
[DEBUG] [uds-messaging] Shutting down          <- only after host sends kill/interrupt
[DEBUG] MCP server "...": CLAUDEAI-PROXY connection closed after ~60s (cleanly)
[DEBUG] [print] turns run on the engine session (createHeadlessSession)

Steps to Reproduce

Steps to Reproduce

Install Claude Code 2.1.252 as a VS Code extension (or Antigravity IDE extension — same result).
Open the Claude Code panel in a project directory containing custom skills/MCP config (reproduced consistently with a project connecting 6-7 claude.ai proxy connectors; unconfirmed whether connector count is a factor).
Send any message, or simply let the extension's automatic background "config cache" warm-up spawn run (no user interaction required — reproduces identically with zero user input, ruling out any dependency on user typing/response time).
Observe: MCP connections and setup complete within ~2-3 seconds, then nothing happens for the remainder of a 60-second window, after which the extension reports the timeout above.

Direct, host-independent reproduction (bypasses the IDE entirely, isolates the subprocess itself):

/path/to/extension/resources/native-binary/claude \
-p "say hello" --output-format stream-json --input-format stream-json \
--setting-sources=user,project,local --verbose

Result: prints one hook_started event, then hangs indefinitely (confirmed idle in kevent64 via sample <pid> 5) — because --input-format stream-json expects the next instruction on stdin and none was piped. This suggests the IDE-host case is the same failure mode via its socket channel instead of stdin: the subprocess is correctly waiting for a message that isn't being delivered.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.252 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Ruled out: stale/duplicate install artifacts (reproduces on a fully clean reinstall with all app state wiped), Antigravity-specific bugs (identical failure in the official VS Code extension), raw network latency (consistently ~20-30ms to api.anthropic.com and mcp-proxy.anthropic.com).
Contributing but not causal: machine shows real memory pressure (heavy swap churn, ~35-40% free RAM on 8GB), and one event-loop-stall was logged (1059ms, 676 major page faults) during a shutdown sequence — but the direct-repro stack sample shows clean idle waiting, not resource thrashing, during the actual hang window.
Unconfirmed suspect: machine is DEP/MDM-enrolled via Kandji, with an Endpoint Security Framework system extension (io.kandji.KandjiAgent.ESF-Extension) and a co-deployed agent ("Iru") active, installed roughly 5 days before this issue was first noticed. Possible that local Unix domain socket I/O is being intercepted/delayed, though this is correlation rather than confirmed causation.
Happy to provide the full sample output or additional logs on request.