.claude.json becomes corrupted (Unexpected EOF) during tool use — non-atomic config writes

Live Reproduction — Within Minutes of Filing This Issue

Reproduced immediately. During a normal tool use (adding a BYPASS_RTH command to ibkr_data_service, running a Python ZMQ one-liner via Bash tool):

1. Task running normally: "Adding BYPASS_RTH command to ibkr_data_service" (1m 42s in)
2. Config corruption hits at ~2m 54s
3. Error: \JSON Parse error: Unexpected EOF\
4. Corrupted file backed up to: \C:\Users\Cassie\.claude\backups\.claude.json.corrupted.1772070805188\
5. Backup exists at: \C:\Users\Cassie\.claude\backups\.claude.json.backup.1772070766357\
6. Suggested restore path is still wrong: \C:\Users\Cassie\.claude.json\ (should be inside \.claude/\ directory)

No Bun crash this time — this was during normal, healthy operation. The config file was corrupted by the write pattern itself, not by a crash interrupting a write.

Environment: Claude Code v2.1.58, Windows 11 Pro Build 26200, Bun v1.3.10

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28806
2. https://github.com/anthropics/claude-code/issues/3117
3. https://github.com/anthropics/claude-code/issues/26717

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Massive New Evidence: 80+ Corrupted Backups in 1 Week

The scope of this bug is far worse than initially reported. Investigation of ~/.claude/backups/ reveals:

• 80+ corrupted .claude.json files accumulated Feb 18-25, 2026
• Clusters of 10-20 corrupted files within the SAME MINUTE (e.g., 20:27-20:29 on Feb 25 produced 40+ corrupted files)
• Corrupted files range from 77 bytes to 11KB (full valid file is ~11KB) — consistent with truncation at random write positions
• Auto-recovery sometimes restores a minimal ~1.7KB version instead of the full ~11KB file, silently losing:
• Project-specific allowed tools
• MCP server configurations
• Trust dialog state
• Tool usage history
• Tip history

Root Cause Confirmed: Race Condition

The clustering pattern (10-20 corruptions within one minute) proves this is a concurrent write race condition, not just crash-related truncation. Multiple Claude Code processes read/write ~/.claude.json without file locking. One process truncates the file mid-write while another reads.

Reproduction

Open a new Claude Code window while another session is active. The corruption frequently triggers on startup when the new process writes to the config while existing processes are also accessing it.

Impact

Every upgrade or crash forces re-authorization of ALL permissions across ALL windows. On a machine running 8+ Claude Code sessions (common for power users), this is catastrophic — the config gets corrupted multiple times per hour.

This user is now paying extra usage tokens to repeatedly re-authorize permissions, re-set configurations, and file bug reports about config corruption caused by the product itself.

Environment: Claude Code v2.1.59, Windows 11 Pro Build 26200, 8+ concurrent sessions

Root Cause Found: BOM Encoding + Race Condition = Config Death Spiral

Investigation of 80+ corrupted backups in ~/.claude/backups/ revealed TWO interacting bugs:

Bug 1: BOM Encoding Kills the JSON Parser

Some .claude.json writes include a UTF-8 BOM (byte order mark, \ufeff). Bun's JSON parser cannot handle BOMs — it throws "Unrecognized token" or "Unexpected EOF" on perfectly valid JSON. The 11KB "corrupted" files in the backup directory are actually completely valid JSON — they just have a BOM prefix.

Verified: opening the largest "corrupted" file (11,073 bytes) with encoding='utf-8-sig' parses perfectly. All 47 keys intact. The backup system marked a valid config as corrupt because of a 3-byte BOM.

Bug 2: Recovery Creates a Death Spiral

When the parser fails on the BOM:

1. It backs up the "corrupted" file (which is actually valid)
2. It writes a minimal 262-byte skeleton as the new .claude.json
3. The next process reads the skeleton — it's valid but tiny
4. That skeleton gets backed up as a "good backup"
5. Now the backup pool is polluted with 262-byte skeletons
6. The original 11KB config is in the "corrupted" pile, unreachable by auto-recovery
7. All project settings, allowed tools, MCP configs, trust state — gone

Evidence

• 80+ corrupted files in backups directory (Feb 18-25)
• Clusters of 10-20 corruptions within the same minute (concurrent process writes)
• "Corrupted" files at 11,073 bytes: VALID JSON (just BOM-prefixed)
• "Backup" files at 262 bytes: minimal skeleton (the ACTUAL data loss)
• Auto-recovery restores from the 262-byte skeleton instead of the 11KB "corrupted" file

Fixes Needed

1. Handle BOMs in JSON parsing — strip \ufeff before parsing, or use a BOM-aware parser
2. Atomic writes — write to temp file, then rename (prevents partial writes from concurrent processes)
3. File locking — prevent concurrent read/write from multiple Claude Code sessions
4. Smarter recovery — prefer the LARGEST valid backup, not the most recent (which may be a skeleton)

Impact

User had to manually dig through "corrupted" backups to find their real config. Every version upgrade triggers re-authorization of ALL permissions across ALL windows because the config keeps getting replaced with empty skeletons. User is paying extra usage tokens to repeatedly re-authorize and file bug reports about config corruption.

Environment: Claude Code v2.1.59, Windows 11 Pro Build 26200, 8+ concurrent sessions

Repro 33: .claude.json Corruption Death Spiral — STILL happening on v2.1.59

This is the 33rd crash/corruption event in 32 days. Escalating because nothing has changed.

What happened today

Multiple windows simultaneously throwing:

JSON Parse error: Unrecognized token ''
JSON Parse error: Unexpected EOF

The "backup" file Claude Code offers to restore? 234 bytes. A skeleton. It's restoring from its own corruption artifact — the exact death spiral I documented in my previous comment on this issue.

Result: forced re-sign-in and re-accept of every single permission, in every single window. Again.

The compound failure with #21576 (Bun crashes)

These two bugs are not independent — they form a feedback loop:

1. Bun crash (#21576) kills a Claude Code process mid-operation
2. The TUI escape sequence corruption forces me to close and reopen terminal windows
3. Multiple windows attempt recovery simultaneously
4. Every recovering window reads and writes .claude.json at the same time — no file locking, no atomic writes
5. Race condition produces a truncated/BOM-corrupted .claude.json
6. The "recovery" logic backs up the 11KB valid config as "corrupted" and replaces it with a 234-byte skeleton
7. Now the skeleton IS the latest backup, so future recovery restores the skeleton
8. All settings, MCP configs, tool permissions, trust state — gone
9. Repeat across every open window

This is not a theoretical race condition. I have 80+ corrupted backup files in ~/.claude/backups/ as physical evidence. They cluster 10-20 at a time within the same minute — concurrent writes, clear as day.

What I'm doing to survive this

I should not have to do any of this:

• Golden backup committed to git — because the built-in backup system actively destroys valid configs
• Watchdog script running 24/7 — detects when .claude.json drops below a sane size and auto-restores from the git backup
• Manual monitoring — I check file sizes after every Bun crash because I know the corruption is coming

A paying Max subscriber is running a cron job to protect a config file from the application that owns it. That is the state of things.

The four fixes I identified (still unfixed)

From my root cause analysis posted previously on this issue:

1. Strip BOM before JSON parsing — the "corrupted" 11KB files are valid JSON with a 3-byte BOM prefix. Bun can't parse them. This is a one-line fix.
2. Atomic writes — write to .claude.json.tmp, then rename(). Prevents partial writes from being visible to concurrent readers. This is OS-101 stuff.
3. File locking — flock() or equivalent to prevent concurrent read/write across multiple sessions. Standard practice for shared config files.
4. Smarter recovery — restore from the LARGEST valid backup, not the most recent. The most recent is almost certainly a 234-byte skeleton that the corruption cycle produced.

None of these are architectural changes. None require refactoring. They are straightforward fixes to a data-destroying bug that hits multi-window users on every Bun crash.

By the numbers

| Metric | Value |
|--------|-------|
| Corruption events | 33 |
| Days tracked | 32 |
| Corrupted backups in ~/.claude/backups/ | 80+ |
| Size of "backup" being restored | 234 bytes (skeleton) |
| Size of actual valid config | ~11,073 bytes |
| Re-sign-ins forced | 33+ (once per event, per window) |
| Subscription tier | Max (paying for extra usage) |
| Version | 2.1.59 |

Ask

Please prioritize this. The root cause is documented. The fix is known. The reproduction is trivially reliable — open 3+ windows and wait for a Bun crash. The config file will be destroyed within seconds.

Every day this ships unfixed is another day I'm paying for a tool that deletes its own configuration and then "recovers" by restoring an empty file.

Cross-ref: #21576 (Bun crashes that trigger this), this issue's previous comments for full root cause analysis with evidence.

269 Corrupted Config Files in a Single Day — Feb 25, 2026

I need to report what I believe is the worst single-day incident documented for this bug.

Today's numbers:

• 269 corrupted/backup files created in .claude/backups/ in ONE DAY
• 18 Bun crashes triggering the corruption cycle each time
• .claude.json reduced to a 234-byte skeleton after every crash — all auth tokens, permissions, tool allowlists, and project settings destroyed
• Had to re-sign-in and re-accept all settings 18 separate times today

The death spiral — this is the core architectural problem:

The auto-recovery system is actively making this worse. Here is what happens:

1. Bun crashes mid-operation
2. .claude.json gets corrupted to a 234-byte skeleton (just {} with a version field)
3. The "recovery" system sees this skeleton and backs it up as a valid config
4. On next launch, it restores from the most recent backup — which is the skeleton
5. Config is now permanently destroyed until manually replaced
6. Repeat 18 times in one day

The recovery system has no concept of config validity. It treats a 234-byte skeleton the same as a 15KB fully-configured file. There is no checksum, no minimum-size validation, no schema check — nothing to distinguish a healthy config from a corrupted one.

What I have had to build myself to keep this product functional:

• A PowerShell watchdog script that runs on a 30-second timer
• A git-committed "golden backup" of .claude.json that the watchdog restores from
• File size validation (reject anything under 5KB as corrupted)
• Logging of every corruption event for bug reports like this one

I am paying for a Max subscription plus additional usage credits. I should not need to build infrastructure around a commercial product to prevent it from destroying its own configuration file.

Cumulative damage this month: 34 crashes across 32 days, 80+ config corruptions prior to today, 269 corruptions today alone, 4 full system lockups requiring hard power-off. Version v2.1.59.

The fix is straightforward:

1. Validate config before writing (minimum size, required fields present)
2. Never back up a file that fails validation
3. Use atomic writes (write to temp file, validate, then rename)
4. Keep the last N validated backups, not just the last N files

Zero Anthropic staff have responded to this issue despite months of reports from multiple users. At what point does config corruption on every crash become a P0?

Update: 276 Config Corruption Events Today. Auto-Recovery Is Actively Harmful.

Date: 2025-02-25
Version: v2.1.59
Corruption events today: 276
Crashes today: 18+

It Happened Again — In This Very Session

The .claude.json corruption occurred again during today's crash (Repro 35, see #21576). The file was truncated from its full 11,442-byte configuration to a 234-byte skeleton — the same pattern as every previous report.

276 Corruption Events Today

The backup directory contains 276 corrupted/backup files created just today. This is not an occasional glitch. This is a systematic, repeated failure occurring roughly once every 2-3 minutes of active use.

The Auto-Recovery Is An Anti-Pattern

Here is the critical problem that makes this worse than just a crash:

1. Claude Code crashes and corrupts .claude.json to a 234-byte skeleton
2. Claude Code creates a "backup" file: .claude.json.backup.1772086898114
3. Claude Code suggests running: cp .claude.json.backup.1772086898114 .claude.json
4. That backup file is ITSELF a 234-byte corrupted skeleton
5. Following the suggested recovery command restores corrupted data, not the real config

The recovery mechanism is not just useless — it is actively harmful. It gives the user false confidence that their config has been restored, when in reality they are copying a corrupted skeleton over a corrupted skeleton. The only way to actually recover is to have an independent, manual backup that was never touched by Claude Code's backup system.

What Should Happen Instead

1. Backup BEFORE writing, not after corruption is detected. The backup should be the last-known-good state, not a snapshot of the already-corrupted file.
2. Validate backup integrity before suggesting restore. A 234-byte file is obviously not a valid backup of an 11,442-byte config. The restore command should refuse to run if the backup is smaller than a reasonable threshold.
3. Atomic writes. Write to a temp file, validate it, then rename. This is filesystem 101. The corruption pattern (truncated file) is textbook "process died mid-write."
4. Stop creating hundreds of backup files per day. 276 files in one day is not a backup strategy, it's a filesystem pollution problem.

Evidence

Expected .claude.json size: 11,442 bytes
Actual .claude.json after crash: 234 bytes
Backup file size: 234 bytes (ALSO CORRUPTED)
Backup files created today: 276

This is the same corruption pattern reported in every previous update on this issue. The file is being truncated during a crash, and the "backup" is being created from the already-truncated state.

Cross-Reference

• #21576 — Repro 35 (full crash details, 18 crashes today)
• #21875 — N-API crash dumping TUI state into terminal
• #16157 — Mega-thread

278 Config Corruption Events in ONE DAY — Corruption Getting WORSE (Feb 25, 2026)

The corruption is accelerating and the nature of it is changing. This is no longer "just" replacing configs with clean skeletons. It's now producing malformed partial writes.

Today's Numbers

• 278 config corruption events on February 25, 2026 alone
• Backup files accumulating in ~/.claude/backups/
• This is alongside 20+ Bun/TUI crashes in the same day (see #21576)

New Corruption Pattern: Malformed Partial Writes

Previous corruption behavior: config file gets replaced with a clean skeleton (annoying but recoverable).

New behavior as of today: Config went from 11,442 bytes to 1,252 bytes — this is neither the original file nor a clean skeleton. It's a partially corrupted write. The file was truncated mid-write, producing a malformed JSON fragment that isn't even valid.

To make it worse: the auto-recovery mechanism suggested restoring from a backup file that is itself corrupted. The corruption is poisoning the backup chain. When your recovery mechanism points you to a corrupt backup, you have no safety net left.

Timeline

This has been documented for 32 days. The corruption rate is increasing:

• Early days: occasional corruption, maybe a few per session
• Last week: dozens per day
• Today: 278 in a single day

The pattern is clear — this is getting worse with each release, not better.

Impact

Every corruption event requires manual intervention. With 278 in one day, that's approximately one every 3 minutes during active use. Combined with the 20+ Bun crashes (#21576) that are now cascading into crashing other applications (IB Gateway trading platform had to be restarted), this tool is actively hostile to sustained use.

Support ticket #215473249874164 — open for weeks with zero response.

Cross-ref: #21576 (20+ crashes today, repros 35-36), #21875, #16157

Contesting Duplicate Label

The suggested duplicates (#28806, #3117, #26717) do not cover this issue. Here's why:

This issue documents a specific, actionable root cause that none of the suggested duplicates identify:

1. BOM (Byte Order Mark) encoding corruption — We traced the corruption to BOM bytes being prepended to .claude.json, causing JSON parse failures. None of the suggested duplicates mention BOM encoding as a root cause.

1. Non-atomic write race condition — We documented that concurrent Claude Code sessions perform non-atomic writes to the same config file, creating a race condition. We have 278 corruption events in a single day as evidence of the failure rate. None of the suggested duplicates quantify this or identify the write pattern as the cause.

1. Auto-recovery death spiral — This is a critical finding unique to this issue: when corruption is detected, the auto-recovery mechanism backs up the corrupted skeleton and writes a new minimal config, but subsequent sessions then pick up the corrupted backup, causing a cascading failure that wipes permissions and settings repeatedly. None of the suggested duplicates document this feedback loop.

1. Proposed fix — We provided a concrete fix: write-to-temp → fsync → atomic rename, which is the standard pattern for preventing exactly this class of corruption. None of the suggested duplicates propose a root cause fix.

The suggested duplicates are generic "config file issues" or "settings not persisting" reports. This issue is the only one with:

• A traced root cause (BOM + non-atomic writes + race condition)
• Quantified failure rate (278 events/day)
• Documentation of the cascading permission wipe via the recovery death spiral
• An actionable proposed fix

Please remove the duplicate label. Closing this as a duplicate of issues that don't identify the root cause means the actual bug will never be fixed.

Duplicate of #28847

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.