[BUG][Windows][native-binary] v2.1.159+ silent-exits during startup — v2.1.112 unaffected

Resolved 💬 1 comment Opened Jun 9, 2026 by jeonghunkim-ops Closed Jul 15, 2026

Summary

v2.1.159 and v2.1.169 (the native binary releases) silent-exit during startup on Windows 11 with no error to stderr. v2.1.112 (the last Node.js JS-based release) works fine on the same machine. The crash point is non-deterministic across modes, suggesting an unhandled async error caught by a top-level handler that calls process.exit(1).

Interestingly, telemetry already knows about this — debug logs show [DEBUG] Prior session exited uncleanly: <uuid> (v2.1.169) and [3P telemetry] Event dropped (no event logger initialized): plugin_loaded. So Anthropic's backend is receiving these crash reports.

Environment

  • Windows 11 Enterprise 10.0.26100
  • Node.js v24.13.1, npm 11.8.0
  • PowerShell 7 + cmd.exe + Git Bash (all reproduce)
  • Corporate domain-joined machine (EDR present, but Defender shows zero block events)
  • Two user plugins installed: telegram@claude-plugins-official, frontend-design@claude-plugins-official
  • MCP servers configured: edgartools, plus claude.ai connectors

Reproduction

npm install -g @anthropic-ai/claude-code@2.1.169
claude                  # silent crash, [O[I focus-tracking residue, no error
claude --safe-mode      # same crash
claude --bare --print x # same crash
claude --version        # works (no init)
claude --help           # works (no init)

Rollback works:

npm install -g @anthropic-ai/claude-code@2.1.112

Diagnostic evidence

Captured with claude --debug-file path --print hi. The crash point varies by mode — suggesting async race, not a single failing function.

--print mode, last log line before silent exit 1:

2026-06-09T00:35:16.339Z [DEBUG] installPluginsForHeadless: starting

--bare --print, last log line:

2026-06-09T00:35:12.071Z [DEBUG] [ScheduledTasks] scheduler start() — enabled=false, hasTasks=false

--allow-dangerously-skip-permissions --print, last log line:

2026-06-09T00:35:20.680Z [DEBUG] Org fast mode: disabled (extra_usage_disabled)

All three exit 1 silently within ~1–2 s of the last log line. Empty stdout, empty stderr.

The full debug log shows startup proceeds through MDM settings → CA cert load (145 bundled + 312 system) → mTLS HTTPS agent → MCP config load → API fetch (api.anthropic.com/v1/mcp_servers succeeds) → LSP manager init → atomic write of .claude.json (succeeds) → then dies. Network is OK, file writes are OK.

What I ruled out

  • Windows Defender: no block events
  • Mark of the Web on claude.exe: not present
  • File permissions: FullControl for current user
  • Parent-process env var contamination (CLAUDE_CODE_EXECPATH, CLAUDECODE, CLAUDE_CODE_SSE_PORT): unset and reproduced
  • Working directory: reproduced from D: drive and from %TEMP%
  • .claude.json corruption: file writes atomically with size 34374 bytes

What I suspect

Given:

  • Non-deterministic last-log-line
  • Telemetry already capturing "Prior session exited uncleanly"
  • [O[I shows terminal raw mode + focus tracking were enabled but not cleaned up
  • All paths through process.exit(1) with no error surfaced

This looks like an unhandled promise rejection caught by a top-level handler that swallows the error. Candidate sources based on the timeline: an MCP server connection failure that throws after the Promise has lost its handler, or a plugin install path that races with bootstrap.

Asks

  1. Surface the actual error before process.exit(1) (preserve it via console.error or write it to the debug log). Right now the SEA binary swallows everything.
  2. If telemetry is already capturing these as "unclean exit," can the corresponding stack be exposed in --debug output?
  3. A flag like --no-plugins --no-mcp (truly minimal, beyond what --bare does) would help users limp along while this is investigated.

I'm happy to share more logs, run more targeted reproductions, or test pre-release builds. The machine is consistently reproducing both v2.1.159 and v2.1.169 — but consistently fine on v2.1.112.

(Diagnostic captured 2026-06-09. Earlier session on 2026-06-01 first hit v2.1.159 with the same symptoms.)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗