.claude.json corrupted by race condition when multiple CLI sessions run concurrently on Windows

Description

~/.claude.json is repeatedly corrupted when running multiple Claude Code CLI sessions simultaneously on Windows. The file becomes truncated (Unexpected EOF), triggering cascading error messages across all open sessions.

Environment

• OS: Windows 11 Pro 10.0.26200
• Shell: Git Bash
• Claude Code version: 2.1.59
• Platform: Native install (not WSL)

Reproduction Steps

1. Open 3+ Claude Code CLI sessions simultaneously (separate terminal windows, same user profile)
2. Work normally in each session (tool calls, skill invocations, etc.)
3. Within minutes, one or more sessions will emit:

Claude configuration file at C:\Users\<user>\.claude.json is corrupted: JSON Parse error: Unexpected EOF
The corrupted file has been backed up to: C:\Users\<user>\.claude\backups\.claude.json.corrupted.<timestamp>
A backup file exists at: C:\Users\<user>\.claude\backups\.claude.json.backup.<timestamp>
You can manually restore it by running: cp "..." "..."

1. Multiple sessions detect the corruption within the same second, each creating its own backup — producing a burst of 5-15 corrupted backup files per incident.

Evidence

Over a 7-day period (Feb 20-26, 2026), 315 corrupted backup files accumulated in ~/.claude/backups/. The corruption events cluster in bursts, with timestamps within the same second (e.g., 12 files all at 10:15 on Feb 26), strongly suggesting a write-write or write-read race condition.

File size analysis shows truncation at various points (38 bytes to 16 KB), consistent with one process truncating the file while another is mid-write.

Burst example (Feb 26, 10:15):

.claude.json.corrupted.1772072128344  (658 bytes)
.claude.json.corrupted.1772072128384  (658 bytes)
.claude.json.corrupted.1772072128435  (658 bytes)
.claude.json.corrupted.1772072128487  (658 bytes)
.claude.json.corrupted.1772072128518  (658 bytes)
...14 more files within the same second...
.claude.json.corrupted.1772072128849  (79 bytes)   <- truncated mid-write
.claude.json.corrupted.1772072128883  (159 bytes)  <- partial content

Expected Behavior

Multiple concurrent Claude Code sessions should safely share ~/.claude.json without corruption. File writes should use atomic operations (write to temp file, then rename) or file locking.

Actual Behavior

• File is truncated/corrupted unpredictably
• All open sessions detect the corruption and emit error messages
• Each session creates its own .corrupted backup, amplifying disk usage
• The file self-heals (gets rewritten by one session), but the error burst is disruptive
• Over time, hundreds of corrupted backups accumulate in ~/.claude/backups/

Suggested Fix

Use atomic file writes: write to a temp file in the same directory, then rename() (which is atomic on both POSIX and NTFS). This is a standard pattern for safely updating config files shared across processes.

Alternatively, use OS-level file locking (LockFileEx on Windows / flock on POSIX) to serialize writes.

Workaround

Avoid running multiple Claude Code sessions simultaneously from the same user profile. Periodically clean up ~/.claude/backups/ with:

find ~/.claude/backups/ -name "*corrupted*" -type f -delete