Interactive REPL: every message fails instantly with 'Unable to connect to API (ConnectionRefused)' — non-interactive paths work fine

Bug: Interactive REPL fails every message with "Unable to connect to API (ConnectionRefused)" — non-interactive paths work fine

Environment

• Claude Code: 2.1.224 (npm-global install, fresh reinstall did not fix)
• Node: v24.13.1
• OS: Windows 11 Pro 10.0.26200
• Auth: Claude Max subscription (OAuth token, not API key)
• Shell: cmd.exe and PowerShell, both affected

Symptom

Every message sent in the interactive TUI fails immediately with:

✳ Unable to connect to API (ConnectionRefused) · Retrying in Ns · attempt N/10

This happens on every single message, in every fresh session, regardless of prompt content (reproduces even with a bare "hello").

What's been ruled out

• Network/DNS/TLS to api.anthropic.com: confirmed working (Test-NetConnection, direct Node fetch() to the real endpoint both succeed, including with a 150KB body)
• Proxy/VPN/hosts file: none configured, none found
• OAuth credentials: valid JSON, token not expired
• claude --print "hello" (non-interactive): works instantly, every time
• echo "hello" | claude (piped stdin, non-interactive): works instantly
• Hooks: stripped to {} (zero hooks) — issue persists identically
• MCP servers: stripped to zero (removed all global and project-level entries) — issue persists identically
• Fresh reinstall (npm uninstall -g + npm install -g @anthropic-ai/claude-code): issue persists identically, same version 2.1.224 (already latest)
• Same home network the user has always used — not a new network

Debug log evidence

From --debug output, same session, ~30 seconds apart:

[DEBUG] [API REQUEST] /v1/messages source=quota_check
   (succeeds — no error follows)

...

[DEBUG] [API:timing] dispatching to firstParty model=claude-sonnet-5
[DEBUG] [API REQUEST] /v1/messages source=repl_main_thread
[ERROR] API error (attempt 1/11): undefined Connection error.

The repl_main_thread failure occurs ~4-9ms after dispatch — too fast to be a real network round-trip or even a real TCP connection attempt. source=sdk (used by --print) and source=quota_check both complete successfully in the same process, same machine, same moment. Only source=repl_main_thread (the interactive engine's own dispatch path) fails, every time, instantly.

Also present at startup (may or may not be related):

[DEBUG] [init] configureGlobalMTLS starting/complete
[DEBUG] mTLS: Creating HTTPS agent with custom certificates
[DEBUG] CA certs: Dropped 10 expired certificate(s) from system store

Hypothesis

The interactive REPL's internal "engine" dispatch layer (distinct code path from the SDK/print path — logs show separate [engine] tagged messages) appears to fail client-side before any network I/O occurs, possibly related to the custom mTLS/HTTPS agent construction not being compatible with whatever transport the engine uses for streaming (undici dispatcher vs legacy https.Agent mismatch is one guess, unconfirmed).

Repro steps

1. Fresh terminal, run claude --dangerously-skip-permissions --debug
2. Type any message, press enter
3. Observe "Unable to connect to API (ConnectionRefused)" retry loop, 10 attempts, then failure
4. Check ~/.claude/debug/<session-id>.txt for the source=repl_main_thread / undefined Connection error pattern

Full debug log available on request.