Windows + OneDrive: .claude.json corruption cascade from concurrent writes

Description

On Windows 11 with the home directory on OneDrive, ~/.claude.json experienced a cascading corruption event that resulted in complete config loss and a login loop.

Environment

• OS: Windows 11 Pro 10.0.26200
• Install method: Native
• Home directory: OneDrive-synced (OneDrive - OI Ventures)
• Claude Code version: 2.1.59

What happened

1. At ~10:18 AM, the 35KB .claude.json (52 startups, 14+ projects, MCP configs, GitHub repo mappings) was flagged as corrupted
2. Recovery attempts began producing progressively smaller files (35KB → 9KB → 1.5KB → 77 bytes)
3. At ~2:46 PM, dozens of .corrupted backup files were created within the same second — classic race condition signature
4. Each recovery attempt read the partially-written output of a concurrent write, producing smaller and more broken files
5. Eventually Claude Code gave up and created a fresh config (numStartups: 1), losing all project data
6. This fresh config triggered a login loop since session state was missing

Evidence

The ~/.claude/backups/ directory contained 106 files documenting the cascade:

• 19 .corrupted files with timestamps showing sub-second write contention
• 7 .backup files, all invalid
• Files created at the same second (e.g., multiple at 1772135200*) confirm concurrent process writes

File size progression during the cascade:

35519 bytes  .claude.json.corrupted.1772119094767  (10:18 AM - last good copy)
 9724 bytes  .claude.json.corrupted.1772135178821  (2:46 PM)
 1505 bytes  .claude.json.corrupted.1772135200496  (2:46 PM)
   77 bytes  .claude.json.corrupted.1772135208848  (2:46 PM)
  157 bytes  .claude.json.corrupted.1772135208870  (2:46 PM)

Root cause

Non-atomic writes to ~/.claude.json combined with:

1. Multiple Claude Code processes (or rapid restart loop) reading/writing the same file concurrently
2. OneDrive file sync adding additional write contention / momentary file locks

Suggested fix

• Atomic writes: Write to .claude.json.tmp then rename() over the original (rename is atomic on both Windows and POSIX)
• File locking: Prevent concurrent processes from writing simultaneously
• Safer recovery: Don't read-and-rewrite during an active corruption cascade — detect rapid repeated failures and pause

Workaround

Manual recovery by finding the largest valid .corrupted file in ~/.claude/backups/ and copying it back as ~/.claude.json. The backup files are valid JSON despite the .corrupted naming — Claude Code was correctly saving snapshots before each recovery attempt, it just couldn't stop the cascade.