claude.json write-race corruption on Windows with concurrent sessions

Summary

Running multiple concurrent Claude Code sessions on Windows causes \ to become corrupted due to write-race conditions. This results in the full onboarding flow (browser OAuth, theme picker) re-triggering on every new session start.

Environment

• Claude Code: v2.1.59 (native install)
• OS: Windows 11 Home 10.0.26200
• Shell: Git Bash
• Usage pattern: 5-10 concurrent sessions in the same repository

Symptoms

1. Full re-onboarding on every new session - browser opens for OAuth authorization, theme/mode selection re-appears
2. Rendering glitches - error messages bleed into the input line while typing
3. Massive corrupted backup accumulation - 281 corrupted backup files created in a single day in 4. Data loss in claude.json - \, \, \, \, and feature flags get wiped

Root Cause

Multiple Claude Code processes read/write \ concurrently without file locking or atomic writes. When sessions start simultaneously:

1. Session A reads 2. Session B reads 3. Session A writes partial update
2. Session B writes its version, truncating Session A's write
3. Result: corrupted JSON (Unexpected EOF)
4. Next session detects corruption, backs it up, starts fresh - losing all onboarding state

Evidence

• 281 \ files generated in \ within a few hours
• Corrupted files range from 77 bytes to 6023 bytes (original is ~6000 bytes), showing writes interrupted at various points
• Many corrupted files generated within the same second (e.g., dozens at timestamp \), confirming concurrent write contention
• \ (separate file) survives intact, confirming the issue is specific to \ write patterns
• Valid JSON backups exist alongside corrupted ones, showing the file oscillates between valid and corrupted states

Expected Behavior

• \ should use atomic writes (write to temp file, then rename) or file locking
• Concurrent sessions should not corrupt shared config
• Onboarding state should persist across sessions

Workaround

Stagger session starts (wait for one to fully load before starting the next). Periodically restore from the largest valid backup in \.