[BUG] Intermittent "Subprocess initialization did not complete within 60000ms" on macOS — interactive sessions (VS Code extension / desktop app / interactive CLI) hang, `claude -p` works; correlates with TLS-inspection (Norton)

Open 💬 2 comments Opened Jun 17, 2026 by djtrazer

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?

Intermittent error on startup: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity.

Affects interactive sessions — the VS Code extension, the Claude desktop app, and interactive claude started in a git repo — which hang for exactly 60s. claude -p "say ok" generally succeeds, and subcommands (--version, doctor, plugin list, mcp list) always work.

Ruled out (each tested in isolation; still hung):

  • Plugins — uninstalled the only one; logs show Found 0 plugins
  • MCP — ENABLE_CLAUDEAI_MCP_SERVERS=false; removed project .mcp.json
  • Telemetry / feature flags — DISABLE_TELEMETRY=1, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
  • Remote Control — disableRemoteControl: true (user + project)
  • Git performance — git status ~0.03s on the machine
  • Network — reproduced on a phone hotspot, off the corporate network
  • Auth — claude doctor shows OAuth present / subscriber auth active
  • Full rm -rf ~/.claude + reinstall, and claude update — each only helped briefly before recurrence

Diagnostic evidence:

  • DEBUG log consistently ends at Found 0 plugins / git-remote parse, then emits nothing for 60s until the timeout.
  • sample of the hung process: main thread idle in kevent64, all workers in __psynch_cvwait — waiting on an async network response that never arrives (not CPU, not a file lock, not a child process).
  • lsof while hung: the claude process holds ESTABLISHED TCP connections to Anthropic (160.79.104.10:443) and a Google-cloud host (34.149.66.x:443) but receives no response.
  • claude doctor: Remote Control: enabled; tengu_ccr_bridge gate (no server response this session).
  • Trigger: an empty directory + git remote add origin <any URL> reproduces the hang; an empty dir with no remote starts instantly.

Likely cause: the machine runs Norton with an active network extension (com.norton.mes.networkextension) performing TLS interception — a Norton trusted CA root certificate is installed in /Library/Keychains/System.keychain and Claude Code loads it ("1 system CA certificate" in debug). The inspection proxy establishes the startup connection but does not pass the HTTP/2 / streaming request-response through, so the startup probe waits out the full 60s. Disabling Norton Intrusion Prevention makes the CLI start instantly; with it on (even with domain exclusions) the timeout returns intermittently.

Related issues: #50988, #65440, #18666, #57556, #50559.

What Should Happen?

Startup should fail fast with an actionable message when the startup network probe can't complete (e.g. behind a TLS-inspecting proxy/AV), instead of hanging for the full 60s. Ideally provide an offline / skip-probe startup path, and document TLS-inspection / corporate-proxy incompatibility.

Note: the main API connection to api.anthropic.com works fine — only this startup probe stalls under TLS inspection. A shorter timeout + clear error (or a documented way to bypass the probe) would unblock affected machines.

Error Messages/Logs

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

DEBUG log (trimmed) — init proceeds normally, then stops dead with no further output until the 60s timeout:
  [init] configureGlobalMTLS complete
  CA certs: stores=bundled,system
  CA certs: Loaded 145 bundled root certificates
  CA certs: Loaded 1 system CA certificates      <- the Norton MITM CA
  mTLS: Creating HTTPS agent with custom certificates
  ...
  Found 0 plugins (0 enabled, 0 disabled)
  <- ~60s of nothing, then the timeout error above

claude doctor:
  Remote Control: enabled
  tengu_ccr_bridge gate (no server response this session)

(Raw logs withheld here as they contain private file paths; can be shared privately on request.)

Steps to Reproduce

  1. On macOS with an active TLS-inspection security agent (here: Norton — system extension com.norton.mes.networkextension, which installs a Norton trusted CA root cert in the System keychain).
  2. In an EMPTY directory, run claude -p "say ok" — starts/exits instantly (works).
  3. Make it a git repo with a remote:

``
mkdir /tmp/repro && cd /tmp/repro && git init && git remote add origin https://github.com/any/repo.git
``

  1. Open the Claude Code VS Code extension in that folder, OR run interactive claude there.
  2. Result: startup hangs ~60s, then errors with "Subprocess initialization did not complete within 60000ms". claude -p "say ok" in the same folder usually still succeeds.
  3. Turn off Norton Intrusion Prevention (the TLS-inspection layer) → startup is instant, confirming the interception is the trigger.

Minimal trigger: any git repo with a remote, on a machine performing TLS interception. An empty dir with no remote does not reproduce.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.169 (Claude Code) — also reproduced on 2.1.153 and 2.1.178

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

  • Also affects the Claude desktop app's sessions; the Cowork mode in the desktop app keeps working (likely a different network path), which is the only reliable surface during the outage.
  • Reinstalling/updating Claude Code and a full rm -rf ~/.claude only resolved it briefly before recurrence — consistent with an environmental (TLS-inspection) trigger rather than a config/version one.
  • Likely affects any developer machine running Norton (or similar TLS-inspecting endpoint security), so this may be a fleet-level concern for orgs that deploy such tools.
  • Happy to provide raw debug logs and the sample/lsof output privately (withheld here as they contain private file paths).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗