claude code corrupts ~/.claude.json on mac while running 5 concurrent sessions

same issue

You can manually restore it by running: cp "/Users/quentin/.claude.json.backup" "/Users/quentin/.claude.json"

not work

This popped up for us last week - really bad. Causing a lot of api key creation too for our team is which is less than ideal.

Same. Haven't confirmed the cause, but I've got a stack of 35 corrupted ~/.claude.json config files piled up over 3 weeks.

The same issue just randomly appeared for me in the last two days on both macOS and Linux. This is particularly infuriating because ~/.claude.json seems to be the only place to store global mcp server configurations where they will stick. They do not work in .mcp.json or settings.json

Related: #1788

Same happened to me yesterday around the same time the update for agents was pushed. IIRC, I ended a session and restarted a few minutes later and had to log back in. I tried to continue my previous session but there weren't any sessions to resume. Noticed all of my MCP servers were missing too so I tried to restore config from backup but it was just a copy of the corrupted one. Now I'm getting random messages it's still corrupted.

same on ubuntu 24.04 Claude configuration file at /home/{user}/.claude.json is corrupted: Unexpected end of JSON input

I am usnsure of the reason. I don't think there were multiple claude session executing (could have been open but should have been idle)

cp "/home/{user}/.claude.json.backup" "/home/{user}/.claude.json" ro selecting "reset with default settings" does not help

<img width="847" height="337" alt="Image" src="https://github.com/user-attachments/assets/9c263b76-02b7-476e-9f13-63a1ad46763e" />

claude doctor also opens the above screen and can't reset it with default configuration. No error messages after selecting that option, the same screen just shows up next time.

config file appears empty

EDIT: It could have been out of disk space. Unable to verify right now, but I will update if reappears.

<img width="1940" height="1069" alt="Image" src="https://github.com/user-attachments/assets/22e6572e-c6e9-43bf-a13a-6f9070b78ad4" />

same all break all the time

i looked into this file, such a bad design to put all the context and every single data in a json file ...

why is the config mixed with cache, and prompts and everything else? insane

I complete broke mine, and the backup is broken also - I tried removing claude, and the files, but when i reinstall claude the original (standard) file does not come back ?

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This isn't stale! Happens for me consistently, too.

Additional Evidence: Linux/WSL2 + Infinite Loop Symptom

I can confirm this issue occurs on Linux/WSL2 as well, with an additional symptom not yet documented: lock contention can cause the TUI to enter an infinite event loop.

Environment

• Platform: Linux (WSL2)
• OS Version: Linux 6.6.87.2-microsoft-standard-WSL2
• Claude Code Version: 2.0.72
• Session ID: 6f257eef-bc05-4588-aeac-7a818b3845d1

Reproduction Scenario

Setup: 4 concurrent Claude Code sessions running in different project directories (legitimate parallel workflow - PDF conversion, issue tracking, etc.)

Trigger Sequence:

1. One session experienced a connection error: Error streaming, falling back to non-streaming mode: Connection error.
2. Shortly after, lock acquisition began failing:

``
[ERROR] Failed to save config with lock: Error: Lock file is already being held
``
(This error appeared 5+ times in quick succession)

1. The TUI then entered a runaway event loop

Runaway Loop Symptoms

The session began cycling through these operations at ~6.6 ops/second (vs normal ~1.5/sec):

• LSP Diagnostics checking
• Hook command matching (UserPromptSubmit with query: undefined)
• FileHistory snapshots for every message
• Atomic writes to ~/.claude.json

Debug log evidence:

• Log grew to 6.3 MB / 76,519 lines in just 14 minutes
• 5,593 FileHistory: Making snapshot entries
• Constant temp file creation: .claude.json.tmp.<PID>.<timestamp>

Impact

• TUI completely unresponsive (ESC did not interrupt)
• Required kill -9 to recover
• CPU usage spiked to 24%+ on that process
• Session state lost

Connection to Settings Corruption

I believe this same lock contention mechanism may explain settings file corruption I documented in a separate issue (#14522). During a previous incident with the same multi-session setup, the permissions array in settings.local.json contained fragmented bash commands split across multiple JSON entries:

"Bash(for archive in /home/user/projects/*/Archives/2025-12-0[2-8]_*.md ...)",
"Bash(do if [ -f $archive ])",
"Bash(then echo '=== $(basename $archive) ===' head -50 $archive)",

This looks like a partial JSON write that got interrupted by lock contention, leaving a corrupted permissions array.

Suggested Fix

In addition to the file locking improvements discussed in this thread, the event loop should have:

1. Lock acquisition timeout - Don't spin forever if lock is held
2. Backoff strategy - Exponential backoff on lock contention
3. Loop detection - Detect rapid cycling and break out gracefully
4. Graceful degradation - Continue with stale state rather than infinite loop

Happy to provide the full debug log (sanitized) if helpful.

Additional evidence from Linux (Ubuntu, v2.1.12)

Confirming this issue on Linux with 5 concurrent Claude sessions. Debug logs show the root cause appears to be lock file contention:

[ERROR] Failed to save config with lock: Error: Lock file is already being held

Lock file location: ~/.local/state/claude/locks/2.1.12.lock

The lock errors occur repeatedly (10+ times per session) when multiple Claude instances are running, which likely causes session data to fail to save properly.

Environment:

• Platform: Linux (Ubuntu on VPS)
• Version: 2.1.12
• Terminal: tmux + multiple concurrent sessions

Still reproducing on v2.1.59 (Windows / Git Bash / MINGW64)

Running 2 terminal sessions (main + background agents from Task tool with run_in_background: true), the cascading
corruption loop appeared within minutes.

Evidence of sub-100ms write collisions:
.claude.json.corrupted.1772070379728
.claude.json.corrupted.1772070379760 (+32ms)
.claude.json.corrupted.1772070379786 (+26ms)
.claude.json.corrupted.1772070379834 (+48ms)

The corruption loop is self-reinforcing: Process A writes → Process B reads mid-write → B detects corruption → B backs
up & rewrites → Process C reads mid-write → repeat. All terminals become unusable until every process except one is
killed.

Note: v2.1.59 fixed the OAuth token race condition for multiple instances (per CHANGELOG), but .claude.json itself
still has no atomic write or file locking.

Environment: Windows 10 (MINGW64_NT-10.0-26100), Claude Code 2.1.59, 2 terminals + 3 background agents

Still reproducing on v2.1.59 (Windows 11 Pro / Git Bash).

Running multiple Claude Code sessions (including worktree-based sessions), the .claude.json corruption loop triggers repeatedly, forcing re-authentication on every new terminal.

Backup directory shows multiple corrupted files created within seconds of each other, confirming the concurrent write race condition.

Environment:

• Platform: Windows 11 Pro (10.0.26200)
• Claude Code: 2.1.59
• Shell: Git Bash (MINGW64)
• Auth: OAuth (claude.ai)
• Scenario: Multiple terminals + worktree sessions

This is a major UX issue — every new terminal requires a full re-login, breaking workflow continuity. Would appreciate atomic writes or file locking being prioritized.

Still having this issue

Same.
ENV: Windows 11. pwsh. Claude CLI. Multi-project and about 5-6 sessions open across 2 projects. 2.1.62 (Claude Code)

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.