.claude.json corrupted by concurrent CLI sessions on Windows (non-atomic writes)

Bug Description

When multiple Claude Code CLI sessions run concurrently on the same Windows machine, ~/.claude.json gets corrupted with "JSON Parse error: Unexpected EOF". This happens reliably when launching 2+ terminals within seconds of each other.

Environment

• OS: Windows 11 Pro 10.0.26200 (Surface Laptop)
• Claude Code: v2.1.59
• Shell: Git Bash (native, not WSL)
• Install method: Native

Steps to Reproduce

1. Open a Claude Code terminal in any project
2. Within 1-3 seconds, open a second Claude Code terminal
3. Second terminal shows:

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>

Root Cause

~/.claude.json is written non-atomically. Multiple Claude Code processes read-modify-write the same file without file locking or atomic rename. One process truncates the file while another is mid-write, leaving partial JSON on disk.

Evidence from a single session:

• Corruption backups created within 19ms of each other (e.g., .corrupted.1772074360427, .corrupted.1772074360446, .corrupted.1772074360463)
• File sizes of corrupted backups vary from 38 bytes to 16KB, confirming mid-write truncation
• 14+ corrupted backups accumulated in a single day of normal multi-terminal usage

Impact

• Forces re-authentication on every corrupted startup
• Trust dialogs must be re-accepted per project
• Erodes user confidence in the tool
• Particularly bad for users who routinely work across multiple repos simultaneously

Suggested Fix

Atomic writes: Write config to a temp file in the same directory, then rename() to .claude.json. Rename is atomic on both POSIX and NTFS. This is a well-established pattern for concurrent config file access.

Alternatively, use LockFileEx (Windows) / flock (POSIX) to serialize writes.

Workaround

Stagger terminal launches by 3-5 seconds. Once sessions are running, write collisions are rare.

Related Issues

This appears related to #28813, #28809, #28806, #26667, and #3117 (Mac equivalent with 5+ sessions).