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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   platform:macosIssue specifically occurs on macOSIssue specifically occurs on macOS

   area:core

   on Jul 7, 2025
2. rboyce-ant

   assigned

   ashwin-ant

   on Jul 7, 2025
3. terryso commented on Jul 9, 2025

   

   terryso

   on Jul 9, 2025

   More actions

   same issue

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

   not work
4. tomnewton commented on Jul 14, 2025

   

   tomnewton

   on Jul 14, 2025

   Last edited by tomnewton

   More actions

   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.
5. mintmcqueen commented on Jul 17, 2025

   

   mintmcqueen

   on Jul 17, 2025

   More actions

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

   

   noops888

   on Jul 24, 2025

   More actions

   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
7. sfearl1 commented on Jul 26, 2025

   

   sfearl1

   on Jul 26, 2025

   More actions

   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.
8. dprkh

   marked [BUG] Claude Code created a shitload of .claude.json.corrupted.00000000 files #5841 as a duplicate of this issue on Aug 15, 2025
9. torronen commented on Aug 19, 2025

   

   torronen

   on Aug 19, 2025

   Last edited by torronen

   More actions

   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

   

   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.
10. louis030195 commented on Oct 2, 2025

    

    louis030195

    on Oct 2, 2025

    More actions

    

    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
11. lulzkiller666 commented on Oct 9, 2025

    

    lulzkiller666

    on Oct 9, 2025

    More actions

    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 ?
12. github-actions commented on Dec 7, 2025

    

    github-actionsBot

    on Dec 7, 2025 – with GitHub Actions

    More actions

    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.
13. github-actions

    added

    autocloseIssue will be closed automaticallyIssue will be closed automatically

    on Dec 7, 2025
14. brennon commented on Dec 11, 2025

    

    brennon

    on Dec 11, 2025

    More actions

    This isn't stale! Happens for me consistently, too.
15. github-actions

    removed

    autocloseIssue will be closed automaticallyIssue will be closed automatically

    on Dec 11, 2025
16. pentafive commented on Dec 19, 2025

    

    pentafive

    on Dec 19, 2025

    Last edited by pentafive

    More actions

    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)
    3. 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.
17. nathanschram commented on Jan 18, 2026

    

    nathanschram

    on Jan 18, 2026

    More actions

    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
18. yokoya1006 commented on Feb 26, 2026

    

    yokoya1006

    on Feb 26, 2026

    More actions

    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

    👍React with 👍7Reacted by Benoit durant de la Pastellière, benjaminhdd, chickenputty, WallnerRepo, yegorandrosov, triciajam and Logan Li
19. chrislloyd

    closed this as completedon Feb 26, 2026
20. Emmanuel-Samuel commented on Feb 26, 2026

    

    Emmanuel-Samuel

    on Feb 26, 2026

    More actions

    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.
21. nicoarcu11 commented on Feb 27, 2026

    

    nicoarcu11

    on Feb 27, 2026

    More actions

    Still having this issue
22. kvirani commented on Feb 27, 2026

    

    kvirani

    on Feb 27, 2026

    Last edited by kvirani

    More actions

    Same.
    ENV: Windows 11. pwsh. Claude CLI. Multi-project and about 5-6 sessions open across 2 projects. 2.1.62 (Claude Code)
23. github-actions commented on Mar 7, 2026

    

    github-actionsBot

    on Mar 7, 2026 – with GitHub Actions

    More actions

    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.
24. github-actions

    locked as resolved and limited conversation to collaborators on Mar 7, 2026