[BUG] Critical memory regression in 2.1.27 - OOM crash on simple input

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21220
2. https://github.com/anthropics/claude-code/issues/21403
3. https://github.com/anthropics/claude-code/issues/21378

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

Update: Potential Node.js version correlation

After further investigation, I have another VM running 2.1.27 without the memory issue. Key difference:

| Environment | Node.js | Claude 2.1.27 Behavior |
|-------------|---------|------------------------|
| VM with crash | v24.12.0 | OOM killed at 7.5GB |
| VM without crash | v22.22.0 | Stable at ~557MB |

Both VMs have similar Claude configs and project context sizes (~1.1-1.3GB). The crashing VM has 8GB RAM, the stable one has 39GB - but the stable one isn't even approaching the memory levels seen on the crashing VM.

This may be a Node.js 24 compatibility issue rather than a universal 2.1.27 regression.

Update: Confirmed 2.1.27 specific, not Node.js related

Further testing:

• Downgraded Node.js from v24.12.0 to v22.22.0 - still crashed on 2.1.27
• Cleared all session state (~/.claude/session-env) - still crashed on 2.1.27
• Rolled back to 2.1.25 - stable at ~470MB

The issue is definitively 2.1.27 on this specific VM. Another VM (39GB RAM, same Node 22) runs 2.1.27 fine at ~557MB, so there may be an environmental factor triggering the regression, but it's not Node version or session state.

Staying on 2.1.25 as workaround.

It happens to me with the native binary as well. Once claude is launched, CPU is skyrocketing to 100%. What I can do is to force close it via Activity Monitor.

Update: Confirmed - bug is triggered by SECOND concurrent session

After extensive testing across two different VMs:

| Scenario | Result |
|----------|--------|
| First Claude session (any directory) | ✅ Stable ~500MB |
| Second concurrent session | ❌ Memory balloons to 7.5GB+, OOM/freeze |

This reproduces on:

• 8GB VM (OOM killed)
• 39GB VM (freezes, had to manually kill)

Both VMs running 2.1.27. The issue is not related to:

• Node.js version (tested v22 and v24)
• Project context size
• Session history
• MCP servers

The bug is specifically triggered when launching a second Claude Code instance while another is already running.

Single-session usage appears stable. Multi-terminal workflows are broken.

can confirm, wont even get an output, it just hangs

Update: Additional bug - 3rd concurrent session hangs (affects 2.1.25 AND 2.1.27)

After further testing, there's a separate issue from the memory explosion:

Reproduction:

1. Launch Claude Code session #1 → ✅ Works
2. Launch Claude Code session #2 → ✅ Works
3. Launch Claude Code session #3 → ❌ Hangs at 90-100% CPU indefinitely

This affects both 2.1.25 and 2.1.27 - tested after fresh VM reboot with clean memory state.

Characteristics:

• Memory stays normal (~400-500MB)
• CPU pegs at 90-100%
• Process never becomes responsive
• Network connections are established but process spins
• Not directory-dependent (tested from different paths)
• Not related to usage limits (plenty of quota remaining)

Summary of bugs found:

1. 2.1.27 only: Memory balloons to 7.5GB on second session → OOM killed
2. 2.1.25 + 2.1.27: Third concurrent session hangs in CPU spin loop

Current workaround: Maximum 2 concurrent Claude Code sessions per machine, running 2.1.25.

ROOT CAUSE IDENTIFIED: Corrupted saved_hook_context records in session files

After extensive binary search debugging, found that session files containing saved_hook_context records cause Claude Code to hang in a CPU spin loop on startup.

Corrupted files found:

• One file had 502 saved_hook_context entries
• Another had 53
• Several others had 6-25

Pattern: All corrupted files were created/modified today after updating the Anthropic plugin marketplace and enabling the playground plugin. Files with 0 saved_hook_context records work fine.

The bug appears to be:

1. Plugin hooks (like explanatory-output-style) are writing duplicate saved_hook_context records to session files
2. When Claude Code loads these sessions on startup, it gets stuck processing these records

Workaround: Delete session files containing saved_hook_context records, or nuke ~/.claude entirely and start fresh.

Affected: This explains both the memory explosion (trying to process hundreds of hook contexts) and the CPU spin (infinite loop processing them).

This is NOT a duplicate of the linked issues.

The suggested duplicates are different problems:

| Issue | Root Cause | Timing |
|-------|------------|--------|
| #21220 | Project indexing memory leak (110K+ files) | During indexing |
| #21403 | Gradual memory leak over 30min-2hr sessions | During operation |
| #21378 | Cache/history accumulation (9.6M tokens) | After weeks of use |
| #22042 (this) | Corrupted saved_hook_context in session files | Instant on startup |

Key differences:

1. This issue causes immediate hang/OOM on startup, not gradual memory growth
2. Root cause is corrupted session JSONL files containing duplicate saved_hook_context records
3. Triggered by plugin marketplace update (specifically after enabling plugins today)
4. Workaround identified: Delete session files containing saved_hook_context records
5. Affects any version (tested 2.1.23, 2.1.25, 2.1.27) if corrupted files are present

The other issues are gradual memory leaks during normal operation. This issue is a parsing/loading bug that causes instant CPU spin loops when loading session history with malformed hook context data.

This needs separate tracking as it has a distinct root cause and fix path.

can confirm this bug, hope they will fix asap.

Diagnostic for others experiencing this issue:

If you're seeing 100% CPU on startup or instant memory explosion, check if you have corrupted session files:

# Find session files with saved_hook_context records
find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \;

# Count how many hook contexts are in each file (healthy files should have 0-2)
for f in $(find ~/.claude/projects -name "*.jsonl"); do
  count=$(grep -c "saved_hook_context" "$f" 2>/dev/null || echo 0)
  if [ "$count" -gt 5 ]; then
    echo "$f: $count hook contexts (CORRUPTED)"
  fi
done

Fix: Delete any files with excessive saved_hook_context records, or if you want a clean slate:

mv ~/.claude ~/.claude.backup

Diagnostic for others experiencing this issue: If you're seeing 100% CPU on startup or instant memory explosion, check if you have corrupted session files: # Find session files with saved_hook_context records find ~/.claude/projects -name ".jsonl" -exec grep -l "saved_hook_context" {} \; # Count how many hook contexts are in each file (healthy files should have 0-2) for f in $(find ~/.claude/projects -name ".jsonl"); do count=$(grep -c "saved_hook_context" "$f" 2>/dev/null || echo 0) if [ "$count" -gt 5 ]; then echo "$f: $count hook contexts (CORRUPTED)" fi done Fix: Delete any files with excessive saved_hook_context records, or if you want a clean slate: mv ~/.claude ~/.claude.backup

I'm not having the CPU issue. It's just not responding, it just hangs.

It's just not responding, it just hangs.

that's the cpu issue :)

> It's just not responding, it just hangs. that's the cpu issue :)

Activity Monitor shows otherwise. weird

> > It's just not responding, it just hangs. > > > that's the cpu issue :) Activity Monitor shows otherwise. weird

use btop

This is also killing our automated PR review processes which are crashing midway through sessions since this version was released.

Tip for those still on the npm version:

You can disable auto-updates and pin to a working version:

1. Disable auto-updates by adding this to ~/.claude/settings.json:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

(Merge with your existing settings if you have them)

2. Reinstall the last working version:

npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code@2.1.25

3. Verify:

claude --version  # should show 2.1.25

New sessions will now stay pinned. When a fix is released, remove the env var and restart claude

Update: Confirmed the root cause on my end too

@Profreshor thanks for the incredible detective work on this - your diagnostic saved me a lot of headache.

Ran your check and found 4 corrupted session files on my machine (macOS). The worst one had 254
saved_hook_context entries, others had 28, 13, and 7.

In my case, I have custom hooks configured globally in ~/.claude/settings.json that listen to multiple
events - SessionStart, SessionEnd, Stop, Notification, UserPromptSubmit, and a PreToolUse with matcher: "*".
That PreToolUse wildcard hook fires on every single tool call Claude makes, so the saved_hook_context
records were accumulating at a much faster rate than a typical setup. A single session with heavy tool usage
was enough to balloon a session file to hundreds of duplicate hook context entries.

The result was exactly what you described - CPU spin on startup as Claude Code tried to parse and process
these bloated session JSONL files. Deleted the corrupted files and everything is back to normal on 2.1.25.
Staying pinned there until this gets a proper fix upstream.

npm install -g @anthropic-ai/claude-code@2.1.25

Thank you for the temporary fix. It works perfectly. No issues. Everybody should follow ths for the time being and downgrade to 2.1.25.

find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \;

confirming by deleting this the hang goes away. I used superpowers which added a session start hook. by disabling it temporarily fixed it.

same issue, disabled superpowers plugin but didn't help. With 2.1.25 works fine

This worked for me:

find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \;

# it returned 2 paths, I rm'ed both and back in business

This worked for me: find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \; it returned 2 paths, I rm'ed both and back in business

This actually worked for 2.1.27 Thanks

Additional data point: macOS Tahoe (26.x) + Apple Silicon

Confirming this issue on macOS:

• OS: macOS 26.2 (Tahoe) Build 25C56, arm64 (Apple Silicon)
• Broken version: 2.1.27 (hung on startup, 100% CPU, no output)
• Working version: 2.1.17 (via "autoUpdatesChannel": "stable")
• Installation: Native (~/.local/share/claude/)

Corrupted files found:

• 879, 281, 230, 142, 49 saved_hook_context entries across 5 session files
• Deleting these files resolved the issue on 2.1.17

Plugins with hooks enabled:

• superpowers (SessionStart hook only)
• ralph-loop (Stop hook only)
• ralph-wiggum (Stop hook only)

Key observation: These are simple lifecycle hooks (SessionStart, Stop), NOT wildcard PreToolUse hooks. The accumulation is happening
even with hooks that should only fire once per session, suggesting the bug may be in how Claude Code persists hook context rather than
how often hooks fire.

Confirming 2.1.27 regression on low-RAM system

Environment:

• Hetzner VPS: 3.7GB RAM + 2GB swap
• Linux (Ubuntu)

Behavior on 2.1.27:

• claude --resume triggered OOM killer on 5-7MB session files
• dmesg: Out of memory: Killed process (claude) total-vm:79GB
• Initially thought it was session file size (commented on #18682)

Fix:

• Rolled back to 2.1.25 → /resume now works fine on same session files

This confirms the regression is version-specific, not just session size or RAM amount.

Can't run it via terminal on MacOS anymore, the VSCode extension still works

This worked for me: find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \; # it returned 2 paths, I rm'ed both and back in business

Confirmed this works on v2.1.27 x MacOS Sequoia 15.7

> This worked for me: > find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} ; > # it returned 2 paths, I rm'ed both and back in business Confirmed this works on v2.1.27 x MacOS Sequoia 15.7

✅ Confirmed working on Claude Code 2.1.27 and macOS Tahoe 26.2 (25C56).

To be safe, I quarantined the matching files instead of deleting them:

# create a backup folder
mkdir -p ~/.claude/projects/_quarantine

# move only the jsonl files that contain `saved_hook_context`
find ~/.claude/projects -name '*.jsonl' -type f \
  -exec sh -c 'grep -q "saved_hook_context" "$1" && mv "$1" "$HOME/.claude/projects/_quarantine/"' sh {} \;

Cleared <user>//projects files (jsonl) - there were over 1.2GB worth of files which were slowing it down. Once done, I asked Claude itself to clear the rest.

<img width="1046" height="587" alt="Image" src="https://github.com/user-attachments/assets/d96d99d2-8942-414d-b20d-d627475a5bd1" />

This worked for me: find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \; # it returned 2 paths, I rm'ed both and back in business

Worked for me as well, thank you!

To work uninterrupted I made a wrapper shell script (around claude) that moves problematic
jsonl to backup dir (maybe I can restore later).

Works well because:

• Bug doesn't affect the running session when it becomes corrupted, it only

affects new instances

• The broken session rewrites its jsonl frequently so it isn't broken if

one wrapped claude deletes (or moves in this case) the log of another.

Apologies if already mentioned here TLDR.

(Note: The following is entirely prepared by Claude Code, and my role is nothing more than reproducing the symptoms and directing Claude Code as a non-technical guy. Please take everything with an extra grain of salt.)

(Note 2: Using random UUID seems prevent 100% CPU usage or hanging AFTER you clean or remove those messy JSONL files, whereas putting the two little circuit breakers might help you keep going even with those problematic JSONL files residing in .claude folder, but don't ask me anything about the unexpected consequences - chats shouldn't be that messy in the first place.)
___

Suspect: saved_hook_context UUID reuse → circular parentUuid → infinite loop in ft()

Building on @Profreshor's finding regarding saved_hook_context. All references to minified cli.js in @anthropic-ai/claude-code@2.1.27.

What changed in 2.1.27

insertMessageChain (cli.js:5198) gained a new branch that persists hook context to the session JSONL:

// cli.js:5198, offset ~415
if (_.type === "attachment" && _.attachment.type === "hook_additional_context") {
    let j = {
        type: "saved_hook_context",
        uuid: _.uuid,            // reuses the attachment's fixed UUID
        parentUuid: J ? null : X, // X = previous chain tail, changes each invocation
        ...
    };
    await this.appendEntry(j);
}

The attachment is created once at SessionStart with a fixed UUID. Each subsequent hook invocation (UserPromptSubmit, PostToolUse, Stop) passes the same object through, writing the same UUID with a different parentUuid each time. In 2.1.25, this attachment was ephemeral — never written to JSONL.

How the cycle forms (example)

Say the hook attachment has UUID aaa. After a few hook invocations, the JSONL contains:

Line 10: { type: "saved_hook_context", uuid: "aaa", parentUuid: "bbb" }
Line 15: { type: "assistant",          uuid: "ccc", parentUuid: "aaa" }
Line 20: { type: "saved_hook_context", uuid: "aaa", parentUuid: "ccc" }  ← same UUID, new parent

ft() (cli.js:5212) builds a Map keyed by UUID — last write wins. After processing:

"aaa" → { parentUuid: "ccc" }   (line 20 overwrote line 10)
"ccc" → { parentUuid: "aaa" }

Two-node cycle: aaa → ccc → aaa → ccc → ...

Why it hangs

There are two parentUuid-walking loops without cycle detection that both hit the same cycle.

Loop 1 — ft() leaf finder (cli.js:5212, offset ~3866):

// Inside ft(), finding leaf user/assistant messages
for (let W of M) {
    let G = W;
    while (G) {
        if (G.type === "user" || G.type === "assistant") { P.add(G.uuid); break; }
        G = G.parentUuid ? q.get(G.parentUuid) : void 0;
        // no visited set — cycles loop forever at 100% CPU
    }
}

Loop 2 — UW1() chain builder (cli.js:5211, offset ~1034):

// Builds ordered message array by walking parent chain
function UW1(A, q) {
    let K = [], Y = q;
    while (Y)
        K.unshift(Y), Y = Y.parentUuid ? A.get(Y.parentUuid) : void 0;
        // no visited set — also loops forever
    return K;
}

UW1 is called from 6 different locations including CeY() (conversation chain builder) and pL() (session hydration), making it a wider attack surface.

Both are triggered on startup for every JSONL file in the project directory via:

Bp() → IZ6() → SeY() → ft()           (loop 1)
Bp() → IZ6() → SeY() → ... → CeY() → UW1()  (loop 2)

One corrupted file blocks all operations: new chat, /resume, session listing.

CPU profiling evidence: Attaching Node.js inspector (kill -USR1) to a hung process and capturing a 2-second CPU profile showed 1540/1540 samples (100%) in CeY → UW1. A Debugger.pause on a second hung process landed in ft() at the leaf-finder loop. Both loops confirmed spinning independently.

Suggested fixes

1. Generate fresh UUID per write (prevents the bug):

uuid: crypto.randomUUID()  // instead of _.uuid

2. Cycle detection in both loops (defense in depth):

// In UW1():
let visited = new Set();
while (Y) {
    if (visited.has(Y.uuid)) break;
    visited.add(Y.uuid);
    // ... existing logic
}

// In ft() leaf finder:
let visited = new Set();
while (G) {
    if (visited.has(G.uuid)) break;
    visited.add(G.uuid);
    // ... existing logic
}

3. Non-destructive repair script (preserves session history, unlike deleting the files):

# Dedup saved_hook_context entries — keeps first occurrence per UUID, removes later duplicates
for f in $(find ~/.claude/projects -name "*.jsonl" -exec grep -l "saved_hook_context" {} \;); do
  python3 -c "
import json
seen = set()
with open('$f') as fh:
    lines = fh.readlines()
with open('$f', 'w') as fh:
    for line in lines:
        try:
            entry = json.loads(line)
            if entry.get('type') == 'saved_hook_context':
                if entry['uuid'] in seen:
                    continue  # skip duplicate
                seen.add(entry['uuid'])
        except: pass
        fh.write(line)
"
  echo "Repaired: $f"
done

For those bumping into the same issue, run claude install --force 2.1.25 until it's ready

claude install --force 2.1.25

If you start Claude immediately afterwards, it's fine. Close it once and then restart Claude -> Claude code is back to the latest build 2.1.27.
Is there a way to keep the version at 2.1.25?

claude install --force 2.1.25 If you start Claude immediately afterwards, it's fine. Close it once and then restart Claude -> Claude code is back to the latest build 2.1.27. Is there a way to keep the version at 2.1.25?

This should work

# Add to your shell profile (~/.bashrc, ~/.zshrc, etc.)
export DISABLE_AUTOUPDATER=1

I had to downgrade to version 2.1.26 for this issue. I performed multiple tests, including disabling all hooks and individual hook groups, but nothing worked.

The only solution that allowed Claude to launch without maxing out 100% CPU at the very first command on version 2.1.27 was to clear the ~/.claude/projects/* folder. This allowed me a full conversation thread (single session).
[ As this is not a long term solution, I have downgraded to 2.1.26].

I believe the history, task logging, and transcription processing are causing the problems. It’s about time we had a clear debug log mode that would help us avoid wasting time on this.

I was experiencing the issue with 2.1.27, conistently freezing on first prompt and pushing CPU usage to 100% for the process. I'm not sure whether it's helpful RE finding the root cause, but anecdotally clearing Claude's cache with rm -rf ~/.claude/cache resolved the issue for me (without downgrading)

I had Gemini investigate and this is what it came up with:

The actual issue identified was a race condition in the claude binary's execution flow,
specifically in how it spawns a secondary process for MCP (Model Context Protocol)
support.

Here is the breakdown:

1. The Trigger: When you run claude (interactive mode), it automatically tries to spawn

a second instance of itself with the flag --claude-in-chrome-mcp.

1. The Failure: The parent process and this child process were entering a livelock—a

state where both were consuming 100% CPU waiting on each other or competing for the
same resource (file scanners in the deployment-log-checker skill), without making
progress.

1. The Root Cause: The binary lacks sufficient internal synchronization (mutexes) to

prevent this collision when the file system or skill state causes a delay.

We resolved this by:
Wrapping the binary with a script (claude_shim.sh) that implements an external mutex.
This ensures that if an MCP process is already running or being spawned, a second one
cannot start, effectively forcing sequential behavior and preventing the resource
collision.

Confirming this issue on WSL2 Ubuntu with VS Code extension v2.1.27

Same behavior - memory explodes within seconds of starting a chat session.

Environment:

• WSL2 Ubuntu on Windows 11
• 32GB RAM (16GB allocated to WSL)
• Claude Code Extension v2.1.27
• Claude CLI works fine (~300MB stable)

Observed behavior:

The VS Code extension spawns TWO claude processes simultaneously:

• --model default --max-thinking-tokens 0
• --model opus --max-thinking-tokens 31999

Memory growth over 15 seconds:

18:05:21 - default: 30.5% (4.9GB), opus: 26.7% (4.3GB)
18:05:26 - default: 33.0% (5.3GB), opus: 31.2% (5.0GB)
18:05:31 - default: 41.3% (6.7GB), opus: 40.6% (6.6GB)
18:05:36 - default: 51.8% (8.4GB), opus: 43.9% (7.1GB)
→ OOM kill, WSL crashes

Workaround: Using Claude CLI in terminal instead of VS Code extension - stable at ~300MB.

Hi all, Claude Code oncall is aware of the issue. We have identified the cause, related to the new saved_hook_context message type in transcript files, and will publish a new release imminently.

Same problem starting .27 freezing on mac

are they going to fix this? this went from the best coding agent to the worst in a day. frustrating.. hope they push .28 with a fix soon

My Claude Code seems to have updated itself to 2.1.29, no freezing so far

Version 2.1.29 is now out with a fix for this issue. To update, run claude update.

We apologize for the CPU loop and the disruption it caused. This was introduced by corrupted saved_hook_context log entries in 2.1.27.

We're adding safeguards to our codebase and feature rollout to avoid similar issues going forward.

Version 2.1.29 is now out with a fix for this issue. To update, run claude update. We apologize for the CPU loop and the disruption it caused. This was introduced by corrupted saved_hook_context log entries in 2.1.27. We're adding safeguards to our codebase and feature rollout to avoid similar issues going forward.

I can't seem to find this on the releases page: https://github.com/anthropics/claude-code/releases

Not sure what I'm missing.

BTW @Profreshor, I think Claude gets compiled down to a binary that is basically Bun (different JS runtime). So I don't think Node.js could be the issue ever (so that you won't waste time next time when doing debugging)

@CVirus it should be updated now!

@dicksontsai the https://status.claude.com/incidents/rl6pphjrc2r4 page lists version 2.0.27 as affected, and points to this github issue.

Can you make sure the status page provides the correct incident information?

<img width="1195" height="727" alt="Image" src="https://github.com/user-attachments/assets/7711af03-2e29-4ae4-b5c1-bef9f3a5e064" />

Still happening to me.

<img width="215" height="66" alt="Image" src="https://github.com/user-attachments/assets/0795aec6-16fd-4d5d-a24e-bcdd283f449e" />

@husniadil I can confirm.

Environment:

• Claude Code version: 2.1.29
• OS: macOS 26.2 (Build 25C56)
• Hardware: Mac mini, Apple M4 Pro, 64 GB RAM
• Node.js: v25.2.1

Description:
CPU usage progressively increases during a session until reaching 100%. The issue appears to be accumulative - it starts normal but gets worse the longer I work. This happens even before the first compaction occurs.

Steps to Reproduce:

1. Start a new Claude Code session
2. Work normally (reading files, making edits, running commands)
3. Observe CPU usage gradually increasing over time
4. Eventually CPU reaches 100% and the session becomes sluggish

Expected Behavior:
CPU usage should remain stable throughout the session, not accumulate over time.

Actual Behavior:

• Session starts with normal CPU usage
• CPU usage gradually increases with continued use
• Eventually reaches 100% CPU
• Performance degrades significantly
• Issue occurs before any compaction events

Additional Context:
This was also reported in earlier versions. The issue persists in 2.1.29. It feels like a memory leak or resource accumulation problem rather than a spike from specific operations.

They nerfed this release so bad. I'm having the same issues (failures on >1 active session and excess resource consumption). Hopefully they fix soon, this is ugly.

+1 for 2.1.29 also having the same bug. Reverting to 2.1.25 with npm install -g @anthropic-ai/claude-code@2.1.25 solves it for now but 2.1.27 and 2.1.29 are very broken. A single prompt, and it hangs with 12 GB of RAM consumed.

Oof, thanks okay. Alright, sounds like we will have to skip this update too. Hopefully someone can confirm that it doesn't freeze for them on the next patch update

also having the same bug, I removed Claude Code and reinstall (native, Mac) [Claude Code is up to date (2.1.29)] still - not working, Claude become not responsive very fast.

Same Issue. Using Macbook Air M4 2025.

<img width="723" height="76" alt="Image" src="https://github.com/user-attachments/assets/d8563c0f-ca71-42cd-ae78-17ae3bf0f894" />

Issue still persists on 2.1.29. I removed the ~/.claude folder (create a backup first). Which seems to resolve this issue for me.

Claude is unusable for me and has been for a while now. 29 does not appear to fix this. the memory issue is not as big of a problem, but there is serious latency on entering anything, and high CPU usage. even in simple sessions it shows this when resuming: (+50 other sessions) - not sure why this would be the case. it was a simple 5 minute claude session.

<img width="221" height="113" alt="Image" src="https://github.com/user-attachments/assets/7799267e-cacd-4a46-900f-6109100ec195" />

2.1.29 is not fixed, seeing 100% CPU usage, please reopen this issue

Entering a single prompt immediately consumes 100% CPU and never progresses on 2.1.29.

This fixed it for me.

See how many of your projects are large (>50 M):

find ~/.claude/projects -name "*.jsonl" -size +50M | wc -l

Nuke them if you don't need them:

find ~/.claude/projects -name "*.jsonl" -size +50M -delete

In case this helps others. I was getting 100 CPU usage and nothing was happening when I ran claude in terminal.

My version was 2.1.27

After upgrading to 2.1.29 it works now.

npm update -g @anthropic-ai/claude-code

Using 3 CPU now.

Still not fixed for me:

<img width="327" height="60" alt="Image" src="https://github.com/user-attachments/assets/8eef836f-bbd9-4c97-bffb-5074b808d022" />
<img width="355" height="59" alt="Image" src="https://github.com/user-attachments/assets/e1df404a-93d2-495a-821e-c4371c969f98" />

I ran the brand new /debug, and this is what I received before it froze.

⏺ Bash(grep -E "\[ERROR\]|\[WARN\]" /Users/husni/.claude/debug/199dfe84-fc1b-4a9e-a54a-71acbe6dd847.txt)
  ⎿  2026-02-04T01:36:28.085Z [ERROR] Error: Error: LSP server plugin:typescript-lsp:typescript failed to start: Executable not found in $PATH: "typescript-language-server"
     2026-02-04T01:36:28.086Z [ERROR] Error: Error: Executable not found in $PATH: "typescript-language-server"
     2026-02-04T01:36:28.086Z [ERROR] Error: Error: Failed to start LSP server plugin:typescript-lsp:typescript: Executable not found in $PATH: "typescript-language-server"
     2026-02-04T01:36:28.760Z [ERROR] Error: Error: LSP server plugin:rust-analyzer-lsp:rust-analyzer crashed with exit code 1

⏺ Read(~/.claude/debug/199dfe84-fc1b-4a9e-a54a-71acbe6dd847.txt)
  ⎿  Read 312 lines

I opened that txt file, and here is the snippet:

2026-02-04T01:36:28.084Z [DEBUG] LSP notification handlers registered successfully for all 2 server(s)
2026-02-04T01:36:28.085Z [ERROR] Error: Error: LSP server plugin:typescript-lsp:typescript failed to start: Executable not found in $PATH: "typescript-language-server"
    at start (/$bunfs/root/claude:2167:22315)
    at async H (/$bunfs/root/claude:2167:24763)
    at processTicksAndRejections (native:7:39)
2026-02-04T01:36:28.086Z [DEBUG] Applied queued notification handler for plugin:rust-analyzer-lsp:rust-analyzer.textDocument/publishDiagnostics
2026-02-04T01:36:28.086Z [DEBUG] Applied queued request handler for plugin:rust-analyzer-lsp:rust-analyzer.workspace/configuration
2026-02-04T01:36:28.086Z [DEBUG] LSP client started for plugin:rust-analyzer-lsp:rust-analyzer
2026-02-04T01:36:28.086Z [ERROR] Error: Error: Executable not found in $PATH: "typescript-language-server"
    at spawn (unknown)
    at spawn (node:child_process:667:35)
    at spawn (node:child_process:14:39)
    at start (/$bunfs/root/claude:2167:20845)
    at start (/$bunfs/root/claude:2167:22369)
    at H (/$bunfs/root/claude:2167:24763)
    at H (/$bunfs/root/claude:2167:25738)
    at _ (/$bunfs/root/claude:2167:32525)
    at processTicksAndRejections (native:7:39)
2026-02-04T01:36:28.086Z [DEBUG] [LSP PROTOCOL plugin:rust-analyzer-lsp:rust-analyzer] Sending request 'initialize - (0)'.
2026-02-04T01:36:28.086Z [ERROR] Error: Error: Failed to start LSP server plugin:typescript-lsp:typescript: Executable not found in $PATH: "typescript-language-server"
    at <anonymous> (/$bunfs/root/claude:2167:32547)
    at processTicksAndRejections (native:7:39)
2026-02-04T01:36:28.760Z [DEBUG] [LSP SERVER plugin:rust-analyzer-lsp:rust-analyzer] error: Unknown binary 'rust-analyzer' in official toolchain '1.88.0-aarch64-apple-darwin'.
2026-02-04T01:36:28.760Z [DEBUG] LSP server plugin:rust-analyzer-lsp:rust-analyzer connection closed
2026-02-04T01:36:28.760Z [ERROR] Error: Error: LSP server plugin:rust-analyzer-lsp:rust-analyzer crashed with exit code 1
    at <anonymous> (/$bunfs/root/claude:2167:21472)
    at emit (node:events:98:22)
    at #handleOnExit (node:child_process:520:14)
    at processTicksAndRejections (native:7:39)

Edit:
I disabled all of LSP server plugins, and the issue still persists.

Edit:
Ended up renaming the ~/.claude/projects to another name to start fresh. The workaround mentioned by people here is working! Thanks.

Edit:
After some conversations, it stuck again (on 2.1.31). Reverting back to 2.1.25.

I installed 2.1.31 with the same tactics and it's still doing the massive hang + 12 GB. The only command I ran was /debug, ironically.

In case it helps anyone else:

I'm on 2.1.31. Today Claude Code maxed the CPU (Mac M3 - native install) every time I tried to run it - regardless of what project/location I was in.

Found a JSONL file in one of the projects under .claude/projects that was 3GB - and most of it was garbage.

Some part of Claude's process had gone crazy, and I had repeating, duplicate file-history-snapshot and queue-operation entries - to the tune of ~30 entries per second for 11 hours straight

Once I truncated the file, the issue disappeared (unsurprisingly!)

This is no longer issue for me, so I believe it's fixed, at least for me.

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.