Parallel sessions crash simultaneously on Windows (native install)
Description
Running two parallel Claude Code sessions (separate terminals, separate worktrees/branches) on Windows causes both sessions to terminate simultaneously without any logged error. This has happened twice since switching to the native Windows installation (v2.1.50).
Environment
- OS: Windows 11 Pro 10.0.26200
- Claude Code version: 2.1.50 (native installation, not npm)
- Installation: Native Windows installer
- Shell: bash (Git Bash)
Steps to Reproduce
- Open two separate terminal windows
- Launch
claudein each terminal, working on different branches/worktrees - Both sessions actively working (using subagents, API calls, tool use)
- After some time, both sessions terminate simultaneously
Expected Behavior
Each session should be independent — one crashing should not affect the other.
Actual Behavior
Both sessions die at the same time. No error message is displayed. Debug logs (~/.claude/debug/) show no fatal error — the process simply stops, suggesting an external kill.
Possible Root Cause
Debug logs show both sessions perform atomic writes to the same ~/.claude.json file using temp files + rename:
Renaming C:\Users\<user>\.claude.json.tmp.16576.1771764251179 to C:\Users\<user>\.claude.json
If both sessions attempt this simultaneously, there could be a race condition on Windows (where file rename semantics differ from POSIX). One session's rename could fail or corrupt the shared state, causing both to exit.
Additional Context
- Sessions use different git worktrees and branches (no shared git resources)
- Both sessions use subagents (Haiku + Opus), generating concurrent API connections
- The crash is not reproducible on demand — it seems to depend on timing of concurrent writes
- This did not happen (or was not noticed) before switching from npm to native installation
Suggested Fix
- Use per-session state files instead of a shared
~/.claude.json, or - Implement proper file locking (e.g.,
lockfile/flockequivalent on Windows) for shared state writes
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Update: Workaround Found
After further investigation of the
cli.jssource (v2.1.50), we identified that the root cause is not the~/.claude.jsonrace condition, but rather the auto-migrate-to-native mechanism (qL1()function in cli.js).What happens
Every time Claude Code starts, it checks whether it should migrate to the native Windows installation. When multiple sessions are running, this migration process kills and restarts the process — taking down all parallel sessions simultaneously.
The fix
Set the environment variable
DISABLE_AUTO_MIGRATE_TO_NATIVE=1to prevent the auto-migration check.We added it to
~/.claude/settings.json:Other findings
autoUpdatesChannelin settings only accepts"latest"or"stable"— setting it to"disabled"causes a validation error (silent, but may contribute to instability)Result
After applying this fix, we've been running parallel sessions (multiple terminals, worktrees, subagents) without any crash. The sessions remain stable and independent as expected.
Confirmed Fix — Stable after 24h+
The workaround described in my previous comment has been confirmed working after multiple sessions over 24+ hours. Two environment variables provide full protection:
DISABLE_AUTO_MIGRATE_TO_NATIVE=1— prevents the auto-migration check (qL1()) that was killing all parallel sessionsDISABLE_INSTALLATION_CHECKS=1— suppresses the yellow "switched from npm to native" warning message (controlled by a separate mechanism, keynpm-deprecation-warningin cli.js)Both are set as permanent Windows user-scope environment variables (via
[Environment]::SetEnvironmentVariable(..., 'User')) and as backup in~/.claude/settings.jsonenvsection.Summary
qL1()auto-migrate function runs at startup, readsprocess.envof the main process beforesettings.jsonenvis applied (which only affects subprocesses viaq16()). This race condition caused the migration process to kill all running sessions.I'd suggest documenting
DISABLE_AUTO_MIGRATE_TO_NATIVEandDISABLE_INSTALLATION_CHECKSas official env vars for users who need to control this behavior, especially on Windows with parallel sessions.Closing as resolved. Fix confirmed stable after 24h+ of parallel sessions. See last two comments for the full workaround (env vars DISABLE_AUTO_MIGRATE_TO_NATIVE + DISABLE_INSTALLATION_CHECKS at OS level).
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.