Config file corruption from concurrent write race condition

Resolved 💬 5 comments Opened Feb 26, 2026 by SlothKing16 Closed Feb 27, 2026

Description

~/.claude.json is repeatedly corrupted when multiple Claude Code instances run simultaneously. The file gets truncated mid-write, producing JSON Parse error: Unexpected EOF.

Evidence

Over a single day, 34 corrupted backup files were generated, with corruption occurring in bursts:

  • Pairs of corruptions detected milliseconds apart (e.g., two at the same second, 37ms apart)
  • Corrupted file sizes range from 77 bytes to ~10KB — truncated at random points
  • Each corrupted snapshot has a different regenerated userID, suggesting each instance generates its own and races to write
  • Smallest corrupted files contain only { "userID": "..." } — a fresh instance overwrote mid-write

Example burst at 09:40 — six corruptions within one second:

1772120431503  (10020 bytes)
1772120431600  (215 bytes)
1772120431660  (321 bytes)
1772120431688  (424 bytes)
1772120431712  (497 bytes)
1772120431738  (532 bytes)

At time of investigation, 15 claude.exe processes were running concurrently.

Root Cause

Multiple Claude Code processes read/modify/write ~/.claude.json without file locking. Classic read-modify-write race condition:

  1. Process A reads file, modifies in memory, begins writing
  2. Process B reads file (or stale version), modifies, begins writing
  3. One write truncates/overwrites the other → invalid JSON

Expected Behavior

Concurrent Claude Code instances should safely share the config file, using atomic writes (write to temp file + rename) or file locking to prevent corruption.

Environment

  • OS: Windows 11 Home 10.0.22631
  • Claude Code version: 2.1.59
  • Install method: Native
  • Shell: Git Bash

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗