Claude Code "Unable to connect to API (ConnectionRefused)" on session start/resume — local MITM-proxy startup race

[kofort9]

Environment

• cmux 0.64.12 (build 92), com.cmuxterm.app
• Bundled Claude Code 2.1.162 (/Applications/cmux.app/Contents/Resources/bin/claude)
• macOS, Darwin 25.3.0

Summary

When I enter the agents view (left-arrow twice) and either start a new session or resume an existing one, Claude Code immediately shows Unable to connect to API (ConnectionRefused) and retries up to 10 times with exponential backoff (up to ~14s). I also get UserPromptSubmit hook error: ... Not connected and Failed with non-blocking status code: Error: Not connected. It then self-resolves and the session works normally.

This is not an Anthropic API or network problem. The evidence points to Claude Code's API client racing cmux's local MITM proxy during workspace spin-up: the proxy is not listening yet for a brief window, so the local connect is refused, then succeeds on retry.

Steps to reproduce

1. In cmux, press left-arrow twice to open the agents view.
2. Start a new session, or resume a previously hibernated session.
3. Observe Unable to connect to API (ConnectionRefused) with retries, then auto-recovery.

Expected vs actual

• Expected: opening/resuming a session connects cleanly with no API error surfaced.
• Actual: a burst of ConnectionRefused / Not connected errors at startup that retry and then resolve.

Evidence it is NOT the network / Anthropic API

• curl https://api.anthropic.com/v1/models returns HTTP 401 in ~0.12s (reachable; 401 is expected without an auth header).
• 20 rapid back-to-back probes to the API: 20/20 succeeded, 0 connection-level failures, while everything was running.
• No HTTP(S)_PROXY env vars set; no ANTHROPIC_BASE_URL / ANTHROPIC_API_URL override in the shell.

Evidence it IS a local proxy startup race

From ~/Library/Logs/Claude/cowork_vm_node.log:

[Spawn:vm] id=... OAuth token approved with MITM proxy
[VM:network] Not connected, will show error in 30000ms if not resolved

From the connection logs:

ConnectionRefused on initial connect — retry 1/3 in 1000ms
ConnectionRefused on initial connect — retry 3/3 in 4000ms
Connection failed after 18ms: Unable to connect. Is the computer able to access the url? (code: ConnectionRefused, errno: none)
Connection failed after 60ms: Unable to connect. Is the computer able to access the url? (code: ConnectionRefused, errno: none)

The decisive detail: these failures occur in 18 to 60 milliseconds with code: ConnectionRefused, errno: none. A failure to reach a remote API over the internet cannot fail that fast. A sub-100ms refusal with errno: none is the signature of a loopback connect to a listener that is not up yet, i.e. the local MITM proxy during VM spin-up, not api.anthropic.com.

Likely regression window

This started only in the last few days, correlating with 0.64.11 (June 1, 2026), which introduced:

• "Agent Hibernation: pauses idle agent sessions and restores them on demand"
• "Detachable SSH PTY daemon ... keeps the session alive across reconnects"

Restoring a hibernated session on demand is exactly the resume path that triggers the error: the VM and its MITM proxy are brought back up, and Claude's API client connects before the proxy is listening. Timing and mechanism both fit.

Suggested fix

Gate the in-VM Claude API client until the MITM proxy is confirmed listening (readiness check / health probe), or have the proxy bind its listening socket before the agent process is allowed to start sending. At minimum, suppress the user-facing Unable to connect to API error during the known proxy-warmup window so transient startup refusals are not surfaced as API errors.

---

Secondary, related finding: keychain write fails inside the VM (-60008), forcing file-fallback and occasional re-login

claude doctor flags: macOS Keychain is not writable, with add-generic-password: returned -60008 and "Unable to obtain authorization for this operation."

-60008 is errAuthorizationInternal (an Authorization Services failure on write). Keychain reads still succeed, which is why auth keeps working. The cause appears architectural: cmux runs Claude in a sandboxed VM detached from the macOS GUI login session, and a keychain write needs an Authorization Services grant tied to that GUI session, which the detached VM context cannot obtain. This is the same class of problem as "keychain is inaccessible over SSH."

Effect: background OAuth token refreshes cannot persist to the macOS keychain, so Claude Code falls back to writing ~/.claude/.credentials.json (confirmed: that file is being written). The user-visible symptom is the occasional unexpected "please re-login" prompt when a refreshed token could not be saved.

Suggested handling: either perform the keychain write from a process attached to the GUI session, or explicitly prefer/document the ~/.claude/.credentials.json fallback for in-VM sessions so token refresh persists reliably and re-login prompts stop.

---

Related issues

• Sparkle auto-update fails on macOS (non-sandboxed): SUSparkleErrorDomain(4005) / Timeout: agent connection was never initiated #5123 (Sparkle auto-update failure on macOS) is a separate symptom I also see; not re-reported here.
• Crash in WebKit WebPageProxy::updateActivityState after wake on macOS 26.5 #5261 (WebKit post-wake crash) appears fixed in 0.64.13; mentioned only for version context.
• No existing issue found describing this ConnectionRefused-on-session-start / MITM-proxy startup race.