Race condition: concurrent sessions corrupt ~/.claude.json

Bug Description

Running multiple Claude Code sessions concurrently causes repeated corruption of ~/.claude.json. The file is written by multiple processes without file locking, resulting in truncated JSON (unexpected EOF).

Environment

• Claude Code: v2.1.59
• OS: Windows 11 Enterprise 10.0.26200
• Shell: Git Bash
• Model: Opus 4.6 (Claude Max)

Reproduction Steps

1. Open two (or more) Claude Code sessions in the same project directory
2. Use both sessions actively (tool calls, etc.)
3. Start a third session

Observed Behavior

On startup, the new session reports:

Claude configuration file at C:\Users\RL04\.claude.json is corrupted: JSON Parse error: Unexpected EOF
The corrupted file has been backed up to: C:\Users\RL04\.claude\backups\.claude.json.corrupted.<timestamp>

The ~/.claude/backups/ directory accumulates hundreds of .corrupted files rapidly. In one session today, 291 corrupted backup files were generated in a few hours. Multiple corruptions can occur within the same second (timestamps differing by <100ms), confirming concurrent write contention.

Evidence of Scale

File listing shows clusters of corruptions at identical timestamps:

.claude.json.corrupted.1772095184101   504 bytes
.claude.json.corrupted.1772095184102   504 bytes  ← 1ms apart
.claude.json.corrupted.1772095184204   881 bytes
.claude.json.corrupted.1772095184360   102 bytes
.claude.json.corrupted.1772095184367   102 bytes  ← 7ms apart

Corrupted file sizes range from 77 bytes to 35KB, suggesting writes are being truncated at arbitrary points.

Root Cause

Multiple Claude Code processes perform non-atomic read-modify-write cycles on the shared ~/.claude.json file (tool usage stats, project settings, client data cache, etc.) without any file locking mechanism.

Expected Behavior

Concurrent sessions should not corrupt shared configuration. Possible fixes:

• Atomic writes: Write to a temp file, then rename() (atomic on most filesystems)
• File locking: flock() / advisory locking before read-modify-write
• Per-session state: Move volatile data (tool usage counters, timestamps) to per-session files; only share stable config

Workaround

Currently the only workaround is to avoid running multiple sessions simultaneously, or accept the corruption messages on startup (the app does self-heal by creating a fresh config).