Skip to content

[BUG] Claude Code Configuration File Corruption #2810

Open

Description

@pm0code

Summary

Claude Code experiences configuration file corruption that causes repeated crashes and requires manual
intervention to resolve.

Environment

  • Claude Code Version: Latest
  • Operating System: Linux (Ubuntu-based)
  • Node Version: v18+
  • Project Type: TypeScript/Node.js application using MCP (Model Context Protocol)

Description

The Claude Code configuration/state files become corrupted during normal operation, leading to:

  1. Repeated crash loops (1200+ restarts observed)
  2. Service unavailability
  3. Manual file deletion required to restore functionality

Steps to Reproduce

  1. Run Claude Code in a project with active file monitoring
  2. Allow it to run continuously for several hours/days
  3. Perform normal development activities (file changes, analysis, etc.)
  4. Configuration file eventually becomes corrupted
  5. Service enters crash loop state

Expected Behavior

  • Configuration files should remain valid during normal operation
  • Service should handle corrupted files gracefully with automatic recovery
  • No manual intervention should be required for continuous operation

Actual Behavior

  • Configuration/state files become corrupted (invalid JSON)
  • Service crashes when attempting to read corrupted files
  • PM2 or process manager enters infinite restart loop
  • Manual deletion of corrupted files required to restore service

Error Messages

SyntaxError: Unexpected token in JSON at position X
Error: Failed to parse configuration file
Process crashed with exit code 1
PM2: Process restarted 1200+ times

Workaround

Currently requires manual intervention:

Stop the service

pm2 stop claude-code

Remove corrupted files

rm -f /tmp/claude-code-state/.json
rm -f ~/.claude/config/
.json

Restart service

pm2 restart claude-code

Impact

  • Severity: High
  • Frequency: Intermittent but recurring
  • Service becomes completely unavailable
  • Requires manual intervention defeating 24x7 operation goals
  • Loss of productivity during downtime

Suggested Fix

  1. Implement robust error handling for configuration file parsing
  2. Add file validation before parsing (check file size, basic structure)
  3. Implement automatic backup/restore mechanism
  4. Add corruption detection and self-healing
  5. Use atomic file writes to prevent partial/corrupted writes

Additional Context

  • Issue occurs more frequently under high load
  • Large project analysis seems to correlate with corruption
  • Files grow unbounded until corruption occurs
  • No built-in monitoring alerts when corruption happens

Reproduction Files

Example of corrupted configuration structure:
{
"version": "1.0",
"projects": [
{
"path": "/path/to/project",
"analysis": {
// File cuts off here - incomplete JSON

Related Issues

  • Service reliability for production use
  • Need for high availability architecture
  • Lack of automatic recovery mechanisms

Note: This issue prevents Claude Code from being used as a reliable 24x7 service without constant manual
monitoring and intervention.

Activity

  1. pauljm commented on Jul 2, 2025

    @pauljm

    I'm seeing this as well. Seems likely to be a concurrency issue as it happens when I run multiple instances of Claude Code in parallel.

  2. steipete commented on Jul 7, 2025

    @steipete

    I run around 5-10 instances concurrently and see this happen almost every day. It seems once that json file goes >8MB claude craps out.

  3. haasonsaas commented on Jul 7, 2025

    @haasonsaas

    Echoing the above — I typically run no more than 2–4 instances at a time. However, every command input is being captured. Since I work extensively with cloud tooling, this results in a wide variety of commands being logged. When I mark these as "always allow," the configuration file quickly fills up and becomes corrupted once it hits around 8MB.

    (Running on CC latest on 26.0 Beta)

  4. mitsuhiko commented on Jul 7, 2025

    @mitsuhiko

    I run around 2-4 agents concurrently, but usually in different places, so I don't have to run on the same repository/folder. It's on Mac, and I see this failure mode of it corrupting the file. I think that it has to do with file size. I'm noticing this really only when the file gets very large that it will happen.

  5. mergesort commented on Jul 8, 2025

    @mergesort

    I usually run about 2-3 instances at a time, but I'm trying to run just one and still running into this bug. Since I saw a spate of logs ever time I launch Claude Code it asks me to reconfigure my environment, starting with light/dark mode, terminal setup, etc.

  6. jfuginay commented on Aug 14, 2025

    @jfuginay

    I've implemented a fix for this configuration corruption issue. The solution includes atomic writes, automatic backups, and recovery mechanisms to prevent crash loops.

    PR: #5798

    The fix has been tested locally and all tests pass successfully.

  7. steipete commented on Aug 14, 2025

    @steipete

    lol. I also got a few such PRs from him. Complete untested nonsense.

  8. 6 remaining items

  9. flcl0213-ship-it commented on Dec 4, 2025

    @flcl0213-ship-it
    1. Restart VSCode
    2. Login to Claude Code again

    Root Cause:
    The .claude.json configuration file became corrupted (similar to #5655). Deleting and letting VSCode recreate it resolved the issue immediately.

    This solution worked on Windows 11 with the latest Claude Code extension.

  10. jfuginay commented on Dec 4, 2025

    @jfuginay

    SOLVED: Deleting corrupted ~/.claude.json file fixed the issue. Steps:

    1. Close VSCode
    2. Delete %USERPROFILE%.claude.json
    3. Restart VSCode

    Depends on your definition of solved.

    Some power users rely on saving and reusing things in their .claude.json

    Having many claude code sessions makes the file become too large and corrupt much faster.

  11. github-actions commented on Jan 4, 2026

    @github-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.

  12. georgiai1 commented on Jan 5, 2026

    @georgiai1

    I just got my file corrupted and have to start a new. Windows user here

  13. llioor commented on Jan 28, 2026

    @llioor
    drwxrwxr-x 12 lior lior     4096 Jan 28 01:12 .claude
    -rw-------  1 lior lior     3385 Jan 26 19:51 .claude.json
    -rw-------  1 lior lior     3385 Jan 26 19:51 .claude.json.backup
    

    remove those files and try to login again

  14. meesp123 commented on Feb 26, 2026

    @meesp123

    this issue happened to me lately.

  15. usl-cto commented on Feb 26, 2026

    @usl-cto

    Reproduction on Windows — v2.1.59 with Task tool subagents

    Environment:

    • OS: Windows 10 (MSYS_NT-10.0-19045), Git Bash
    • Claude Code: v2.1.59 (latest)
    • Shell: bash (MSYS2)

    Trigger: Running a session that spawns 2+ parallel Task tool subagents (e.g., an Explore agent + a research agent). The main process + subagents = 3 concurrent writers to ~/.claude.json.

    Result: 36 corrupted backup files generated in a single session (~2 minutes), all with JSON Parse error: Unexpected EOF. The corrupted files show:

    • Truncated writes (157–504 bytes vs full ~1758 bytes)
    • Different userID hashes across files (each partial write produces inconsistent state)
    • All timestamps within seconds of each other (concurrent writes confirmed)

    Interesting finding from cross-referenced issue #26717: The logs show that atomic write-rename was attempted but fails on Windows:

    [ERROR] Failed to save config with lock: Error: Lock file is already being held
    [DEBUG] Failed to write file atomically: Error: EPERM: operation not permitted, rename '.claude.json.tmp' -> '.claude.json'
    [ERROR] Config file corrupted, resetting to defaults: JSON Parse error: Unexpected EOF
    

    So the fix (atomic rename) exists in the codebase but is broken on Windows — EPERM on rename suggests another process has the file open, and Windows doesn't allow renaming over open files (unlike POSIX). The lock file approach also fails because the lock is already held by a sibling process.

    Suggested fix for Windows: Use fs.rename with retry logic + exponential backoff, or use proper-lockfile with retries option. Alternatively, have subagents delegate all config writes to the parent process via IPC rather than writing directly.

    Question: Is there a previous version of Claude Code that did not exhibit this issue? Would like to know if downgrading is a viable temporary workaround while this is being fixed.

  16. DmitriyYukhanov commented on Feb 26, 2026

    @DmitriyYukhanov

    Is there a previous version of Claude Code that did not exhibit this issue?

    I think 2.1.50 doesn't corrupt configs as per #28847 (comment)

    Struggling from 2.1.59 ruining processes too.

  17. patrikhuber commented on Feb 26, 2026

    @patrikhuber

    The same is happening to me too on Windows. Running multiple Claude Code CLI instances was always fine, but since a restart this evening, the second terminal triggers

    Claude configuration file at C:\Users\.....\.claude.json is corrupted: JSON Parse error: Unexpected EOF
    The corrupted file has been backed up to: C:\Users\......\.claude\backups\.claude.json.corrupted.1772142835854
    A backup file exists at: C:\Users\.....\.claude\backups\.claude.json.backup.1772142829621
    

    I'm on 2.1.59 as well, I've been for a day or so but it's possible I haven't opened multiple terminals until now.

  18. duaneking commented on Feb 28, 2026

    @duaneking

    I'm getting this all over the place for the last couple days and I absolutely hate it

  19. patrikhuber commented on Feb 28, 2026

    @patrikhuber

    It's fixed in the latest version, I haven't had it again since updating yesterday.

  20. junaidtitan commented on Mar 3, 2026

    @junaidtitan

    We kept hitting this with multiple Claude instances. Built cozempic to detect and auto-repair .claude.json corruption — open source.

    pip install cozempic
    cozempic doctor        # detects truncated JSON, missing auth, corruption cascades
    cozempic doctor --fix  # restores from most recent valid backup

    Scans for invalid JSON, numStartups anomalies, and rapid backup file creation (the cascade pattern). Feedback welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:corebugSomething isn't workinghas reproHas detailed reproduction stepsplatform:linuxIssue specifically occurs on Linux

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions