[BUG] Claude Code Desktop is crashing with new version

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48276
2. https://github.com/anthropics/claude-code/issues/48273
3. https://github.com/anthropics/claude-code/issues/46713

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

Bug Report: Claude Desktop — Code Tab Causes OOM Crash on Launch

Summary

Claude Desktop crashes with a V8 JavaScript heap out-of-memory (OOM) error every time the Code tab is opened. The Chat and Cowork tabs work normally. The issue persists across macOS versions and clean reinstalls.

Environment

• App version: Claude Desktop 1.2581.0 (installed via Homebrew)
• macOS: Tahoe 26.4.1 (also reproduced on 26.2 / build 25C56)
• Hardware: Mac mini (2024), Apple M4, 16 GB RAM
• Installation method: brew install --cask claude

Steps to Reproduce

1. Launch Claude Desktop
2. Sign in to account
3. Chat and Cowork tabs load and function correctly
4. Click on the Code tab
5. Interface shows placeholder blocks (gray skeleton UI), content fails to render
6. App freezes with 100% CPU usage
7. App crashes within ~8–90 seconds

Error Log (from terminal launch)

[28579:0415/165812.961578:ERROR:electron/shell/common/node_bindings.cc:185]
OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

<--- Last few GCs --->
Mark-Compact (reduce) 2697.4 (2764.3) -> 2697.4 (2763.3) MB, pooled: 0.0 MB,
38.07 / 0.00 ms (average mu = 0.703, current mu = 0.000) last resort;
GC in old space requested

The heap consistently maxes out at ~2697 MB regardless of configuration.

Troubleshooting Already Attempted

• ✅ Clean reinstall of Claude Desktop (deleted app + all data in ~/Library/Application Support/Claude/)
• ✅ Cleared Cache, GPUCache, Local Storage, Session Storage, IndexedDB
• ✅ Removed vm_bundles directory (was 10 GB)
• ✅ Removed claude_desktop_config.json
• ✅ Upgraded macOS from 26.2 to 26.4.1 — issue persists
• ✅ Attempted NODE_OPTIONS="--max-old-space-size=8192" — not effective (Electron ignores it)
• ✅ Attempted --disable-gpu — app errors due to GPU dependency
• ✅ Attempted --disable-gpu-compositing — still OOM
• ✅ Attempted --use-gl=swiftshader — still OOM

Key Observation

• Chat tab: Works normally ✅
• Cowork tab: Works normally ✅
• Code tab: Immediate OOM crash ❌

This strongly suggests the issue is isolated to the Code tab's initialization or data loading logic, not the Electron shell or rendering pipeline.

Expected Behavior

The Code tab should load and function normally without exceeding memory limits on a 16 GB machine.

Additional Notes

Prior to the crash, the ~/Library/Application Support/Claude/vm_bundles directory had accumulated ~10 GB of data, suggesting the Code module may not be cleaning up old VM bundles properly. Even after removing this directory and performing a completely clean install, the OOM crash persists.

Reproducing on macOS with Homebrew install
Environment:

Claude Desktop: 1.2581.0 (f10398) 2026-04-14T17:16:40.000Z
macOS: Apple Silicon (MacBook Pro)
Claude Code CLI: 2.1.109 (installed via npm + Homebrew Node 25.9.0)
CLI path: /opt/homebrew/bin/claude (symlinked to /usr/local/bin/claude)

Steps to reproduce:

Open Claude Desktop app
Click the "Code" tab/button
App immediately crashes

What happens:
App exits with SIGTRAP (signal 5) — confirmed via macOS Console logs. The crash reporter (chrome_crashpad_handler) attempts to capture a dump but is denied by AMFI: AMFI: Denying core dump for pid 15842 (Claude).
What I've tried:

Cleared ~/Library/Application Support/Claude and ~/Library/Caches/com.anthropic.claudefordesktop
Confirmed Claude Code CLI is installed and functional from terminal (claude --version returns 2.1.109)
Created symlink at /usr/local/bin/claude pointing to /opt/homebrew/bin/claude in case of PATH issue
Fresh reinstall of the desktop app

None of the above resolved the crash. Claude Code works fine directly from terminal.
Workaround: Use claude directly from terminal.

From the terminal it works fine, but I have the same error — I open it and the Claude app closes if I'm in Claude Code. In the normal chat it works without any problem.

Same issue unusable on Mac, no option to roll back no fix for so long

Same issue here. Claude Desktop 1.2581.0, crashes immediately when clicking on Code — Chat and Cowork work fine.

This is really frustrating because it completely breaks the workflow I'm paying for. I rely on Claude Code daily for an active project and having to work around this disrupts productivity significantly.

Looking forward to a fix.

Bug persists in v1.2773.0 (884b37), released 2026-04-15. Code tab still crashes immediately on selection. macOS 26.5 beta 2. Chat and Cowork work fine.

Bug persists in v1.2773.0 (884b37)

Auf #48281 einen 👍 geben und einen kurzen Kommentar posten: "Same issue on Windows 11 with v1.2581.0 (Desktop build f10398). Crash is silent, occurs ~60s after opening Code tab. See #48553 for full Windows details."

Yes, the issue still persists. I will unsubscribe to Claude.

Issue still persists on Claude Code after the latest update

Solution: Claude Desktop Crashes on Code Tab (OOM) — Root Cause Found

Summary

Claude Desktop crashes immediately when switching to the Code tab, while Chat and Cowork tabs work normally. The root cause is not a bug in the desktop app itself, but oversized transcript files under ~/.claude/projects/ that cause the V8 JavaScript heap to run out of memory (OOM) during Code tab initialization.

Environment

• macOS: Tahoe 26.x (Apple Silicon)
• Claude Desktop: v1.2581.0+
• Symptom: App silently exits within ~8 seconds of clicking the Code tab. No error dialog. No crash report in ~/Library/Logs/DiagnosticReports/.

Root Cause

The Code tab scans all transcript files under ~/.claude/projects/ on startup. If a single session has accumulated a very large .jsonl transcript (especially sessions with many embedded base64 images such as PDF page screenshots), the file can grow to multiple gigabytes. Loading it into memory exceeds V8's heap limit (~2.7 GB by default) and crashes the app.

Diagnosis Steps

1. Confirm the OOM error

App logs under ~/Library/Logs/Claude/ typically show nothing useful. To capture the real error, launch Claude from the terminal:

/Applications/Claude.app/Contents/MacOS/Claude > /tmp/claude_stdout.log 2> /tmp/claude_stderr.log &

Click the Code tab, wait for the crash, then check stderr:

cat /tmp/claude_stderr.log

You should see something like:

<--- Last few GCs --->
[PID:0x...] ... ms: Scavenge 2267.2 (3452.1) -> 2267.0 (3452.1) MB
[PID:0x...] ... ms: Scavenge 2267.0 (3452.1) -> 2266.9 (3452.1) MB

OOM error in V8: MarkCompactCollector: young object promotion failed
Allocation failed - JavaScript heap out of memory

The heap consistently maxing out around ~2.7 GB confirms the OOM.

2. Locate the oversized transcript files

# Check total size of .claude directory
du -sh ~/.claude/

# Find transcript files larger than 100 MB, sorted by size
find ~/.claude -name "*.jsonl" -size +100M -exec du -sh {} \; | sort -rh | head -10

In one confirmed case, a single .jsonl file was 17 GB, containing ~70,000 base64-encoded images from a session that ran continuously for 30 days.

Solution

Move the oversized transcript files out of ~/.claude/ (don't delete directly, in case you need them later):

# Create an archive folder
mkdir -p ~/Desktop/claude_archive

# Move oversized session files (replace <project-name> and <session-id> with actual values from the find command above)
mv ~/.claude/projects/<project-name>/<session-id>.jsonl ~/Desktop/claude_archive/
mv ~/.claude/projects/<project-name>/<session-id>/ ~/Desktop/claude_archive/

Restart Claude Desktop. The Code tab should now load normally.

Once you confirm everything works, you can delete the archived files to free up disk space.

What Does NOT Fix It

These common troubleshooting steps will not resolve this issue because the problem is in ~/.claude/, not in the app's own data directory:

• ❌ Reinstalling Claude Desktop
• ❌ Clearing ~/Library/Application Support/Claude/ (Cache, GPUCache, Local Storage, etc.)
• ❌ Removing vm_bundles directory
• ❌ Upgrading macOS
• ❌ Disabling GPU acceleration (--disable-gpu, --use-gl=swiftshader, etc.)
• ❌ Setting NODE_OPTIONS="--max-old-space-size=8192" (Electron ignores this)

Prevention

• Start new sessions periodically, especially for tasks involving many images or PDFs. A single session running for days or weeks can balloon to several GB.
• Monitor ~/.claude/ size regularly:

``bash
du -sh ~/.claude/
``

• Set up a cleanup reminder for old sessions you no longer need.

Tips for Debugging Similar Crashes

When Claude Desktop crashes without any visible error:

1. Launch it from the terminal and redirect stderr to a file — this captures V8 errors that never show up in the app logs.
2. Check ~/.claude/ directory size — if it's unexpectedly large (tens of GB), transcript bloat is likely the cause.
3. Look for individual .jsonl files over 100 MB with find ~/.claude -name "*.jsonl" -size +100M.

---

Hope this helps others running into the same issue. Credit to the community members who traced it down to the transcript file size.

Thank you I could fix my issue thanks to you. I had the CLI move things for me.

Fix: archive oversized transcripts in ~/.claude/

In Terminal, check for large transcript files:

du -sh ~/.claude/
find ~/.claude -name "*.jsonl" -size +100M -exec du -sh {} \; | sort -rh

If you see multi-GB .jsonl files, quit Claude Desktop and archive the folder containing them:

mv ~/.claude/projects/<large-project-folder>/ ~/Desktop/claude_transcripts_archive/

Relaunch Claude Desktop. The Code tab should load normally with "sidebarMode": "code" restored in ~/Library/Application Support/Claude/claude_desktop_config.json.

Written by Claude .

Confirming this bug on Windows 11 x64 — the platform:macos label should be broadened.

Environment

| Field | Value |
|---|---|
| OS | Windows 11 x64 (not ARM64) |
| Claude Desktop | 1.3883.0 (current as of 2026-04-24) |
| Last known good | 1.3561.0 (installed side-by-side in %LOCALAPPDATA%\AnthropicClaude\app-1.3561.0\) |
| Plan | Max |

Reproduction

5 renderer crashes in 12 hours (3 within one hour of active use), each correlating 1:1 with an entry in %APPDATA%\Claude\logs\claude.ai-web.log:

<details>
<summary>Crash log excerpt (timestamps + IPC error)</summary>

2026-04-23 22:11:32 [error] Uncaught (in promise) Error: Error invoking remote method
  '$eipc_message$_<uuid>_$_claude.buddy_$_BuddyBleTransport_$_reportState':
  Error: No handler registered for '...BuddyBleTransport_$_reportState'
2026-04-24 00:43:56 [error] ... (same)
2026-04-24 01:11:22 [error] ... (same)
2026-04-24 09:23:09 [error] ... (same)
2026-04-24 09:30:13 [error] ... (same)

Each entry is followed by a cleanupVMBundleIfUnsupported sequence in cowork_vm_node.log, indicating the renderer was torn down and re-initialized.
</details>

Diagnostic findings (Windows)

• Crashpad/reports/ folder is empty — Electron does not dump renderer crashes of this kind, which is why no native crash report is filed.
• Windows Application Event Log has no matching Application Error / WER entries for claude.exe in the last 24 h — this is not a hard OS-level crash, it's an unhandled promise rejection inside the renderer.
• Hyper-V, HypervisorPlatform, and VirtualMachinePlatform are all enabled on the host, so the virtualization stack is not the cause.
• The yukonSilver not supported log line in cowork_vm_node.log is unrelated noise (feature is intentionally disabled on this config).

Workaround (confirmed)

Downgrading to 1.3561.0 eliminates the crashes:

Get-Process -Name "claude" -ErrorAction SilentlyContinue | Stop-Process -Force
& "$env:LOCALAPPDATA\AnthropicClaude\app-1.3561.0\claude.exe"

Previous versions are preserved by Squirrel under %LOCALAPPDATA%\AnthropicClaude\app-*\ after auto-update.

Pattern (cross-reference)

This looks like the same class of bug as:

• #48261 — same BuddyBleTransport_$_reportState error, co-occurring with V8 OOM on macOS 1.2581.0
• #37346 — closed as stale, but the underlying issue (ComputerUseTcc_$_getState — "No handler registered") is the identical pattern on Windows 1.1.7714.0 during the Cowork persistent-thread rollout

In all three cases, the renderer bundle calls an @electron/remote-style IPC method that the main process never registers, producing an unhandled promise rejection that kills the renderer.

Request

1. Broaden this issue's labels to include platform:windows — the root cause is platform-agnostic.
2. Consider reopening #37346 as a duplicate of this issue — it documents the same failure mode (missing IPC handler) that was never structurally addressed.
3. If the claude.buddy / BuddyBleTransport feature is not shipped on the renderer for all users yet, gating the frontend call-site behind a feature flag (or a if (ipcRenderer.has(...)) guard) would stop the bleeding without waiting for the handler to be wired up on every platform.

Happy to provide the full claude.ai-web.log, main.log, and cowork_vm_node.log bundle via the in-app "Send feedback" flow if helpful — let me know and I'll attach with a reference to this issue number.

Per Anthropic Support's suggestion, I filed a Windows-specific sibling report with the same root-cause analysis and additional Windows-only diagnostics: #52738.

Cross-linking so triagers can fold them together (or apply platform:windows here) — the underlying missing-IPC-handler is clearly platform-agnostic.

Confirming the fix works for a related crash trigger (worktree-session SIGTRAP, not just the Code tab)

The accepted fix in this thread — archive oversized ~/.claude/projects/*.jsonl transcripts — also resolves a different surface symptom of the same underlying bug. Posting in case it helps others searching for it.

My symptom

Claude Desktop 1.4758.0 on macOS, renderer crashing 7 times in ~7 hours with Main webview render process gone, exitCode: 5 (SIGTRAP). My Code tab worked fine — crashes happened when opening a session inside an existing .claude/worktrees/<name> directory. Every crash was preceded within 1–2 seconds by LocalSessions.getPrStateForBranch against that worktree path. Filed separately as #54369.

Why this thread's fix applies

Same renderer OOM, just hit through a different code path. Both this issue's "click Code tab" and my "open worktree session" funnel into the same renderer that loads project transcripts from ~/.claude/projects/, and both hit the V8 ~2.7 GB heap ceiling when the project has accumulated large .jsonl files.

My data before applying the fix

• ~/.claude/projects/ total: ~1.5 GB
• Largest single project (the one in 100% of my crashes): ~566 MB of transcripts
• Several individual .jsonl files in the 15–51 MB range; thousands of small files summing into the danger zone

Not as extreme as the 17 GB case originally documented here, but still enough to OOM the renderer.

Fix applied

Two-pass archive of ~/.claude/projects/ to a backup folder outside ~/.claude/:

1. Files >10 MB modified more than 24h ago — 13 files, ~223 MB.
2. All .jsonl older than 14 days regardless of size — 3,294 files, ~896 MB.

After: ~/.claude/projects/ = ~371 MB (75% reduction). Largest project = ~129 MB. Restarted Claude Desktop. The previously-crashing worktrees now open cleanly. No SIGTRAP since.

Practical takeaway for others hitting this on newer builds

If you are on a recent Claude Desktop (e.g. 1.4758.0+) and seeing exitCode: 5 / SIGTRAP renderer crashes that the rest of this thread's "click the Code tab" repro doesn't quite match, still check du -sh ~/.claude/projects/ first. If it is anywhere north of ~500 MB on a single project, the fix here (archive, don't delete) is highly likely to resolve it regardless of whether your trigger is the Code tab or worktree session opening.

Getting an immediate fix for this in Thursday's desktop release.

Still having the same issue in the MacOS Desktop Client on version Claude 1.9659.4 (8cc655) 2026-06-02T02:30:57.000Z.