### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ### Environment - Claude Desktop: 1.11847.5 - macOS: 26.5 (build 25F71), MacBook Air, Apple Silicon (arm64), 16 GB RAM - Claude Code CLI: 2.1.165 (works f

[BUG] Code tab crashes the app (V8 OOM) when a ~/.claude/projects session .jsonl is very large (macOS 26.5)

Status Fixed / completed

Reported on v2.1.165

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 3 comments · opened Jun 11, 2026 · closed Jun 22, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Environment

Claude Desktop: 1.11847.5
macOS: 26.5 (build 25F71), MacBook Air, Apple Silicon (arm64), 16 GB RAM
Claude Code CLI: 2.1.165 (works fine)

Summary

Opening the Code tab fully quits the app after ~5–13s. Chat and Cowork work.
Root cause: the Code tab loads a Claude Code session transcript into memory, and a single
2.4 GB .jsonl in ~/.claude/projects/<project>/ pushes the renderer past V8's heap
limit → OOM → the whole app dies.

Steps to reproduce

Have a large session file, e.g. ~/.claude/projects/<project>/<uuid>.jsonl ≈ 2.4 GB.
Launch the desktop app, open the </> Code tab.
App quits after a few seconds. No .ips crash report is generated.

Actual behavior (from launching the binary in Terminal)

What Should Happen?

The ~2.65 GB ceiling is hit regardless of --js-flags="--max-old-space-size=8192/12288",
so the OOM is in the Code renderer process, not the main process.

What I ruled out

Local VM: after moving vm_bundles aside, it still crashes and no rootfs.img is

recreated → crash happens before any VM init.

Disk space: 307 GB free.
Reinstall / fresh config: crash persists, because ~/.claude/projects is never reset

by those operations. This is why the bug looked "unkillable".

Workaround (confirmed)

Quit the app, move the oversized .jsonl out of ~/.claude/projects/..., relaunch → Code
tab opens normally.

Suggested fix

Load Code history lazily / paginated, or add a size guard, so the Code tab never maps an
entire session transcript into memory and can't be killed by a large local .jsonl.

Error Messages/Logs

Steps to Reproduce

Have a large Claude Code session file, e.g. ~/.claude/projects/<project>/<uuid>.jsonl around 2.4 GB (check with: du -sh ~/.claude/projects/* | sort -rh).
Launch the Claude Desktop app.
Click the </> Code tab.
The entire app quits after ~5–13 seconds. No .ips crash report is generated.
Quit the app, move that large .jsonl out of ~/.claude/projects, relaunch, open the Code tab → it now works. This confirms the large session file is the trigger.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.11847.5 · macOS 26.5 (25F71) · MacBook Air, Apple Silicon (arm64), 16 GB RAM · Claude Code CLI 2.1.165

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] · 4 months ago

Found 2 possible duplicate issues:

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

junaidtitan · 4 months ago

A 2.4 GB .jsonl is the exact root cause of what you're seeing — the Code tab loads the entire file into the renderer's V8 heap, and at that scale it hits Electron's per-process memory ceiling before any app logic runs. Which is also why --max-old-space-size flags don't help (they tune the old-generation GC limit, not the virtual address space ceiling).

The Anthropic fix — lazy/paginated transcript loading — is the right permanent answer and worth keeping on this tracker.

But if you want to get back into that session now without permanently sidelining the .jsonl, cozempic (github.com/Ruya-AI/cozempic) prunes bloated session files directly on disk, no running app needed:

pip install cozempic
cozempic current --diagnose        # shows what's eating bytes — usually accumulated tool outputs, base64 image payloads, oversized shell output blocks
cozempic treat current -rx aggressive --execute   # prunes in place; dry-run by default without --execute

On a heavily bloated session the aggressive prescription typically gets 60–80% reduction. At 2.4 GB that might land you around 500 MB – 1 GB, which the V8 renderer can usually handle.

Honest caveat: if the session is large because it had hundreds of screenshot or image-heavy tool turns, there's a floor on how small it gets (the conversation history itself can't be pruned). But on most sessions the bulk is overhead — duplicate tool outputs, base64 blobs written twice, accumulated shell output — and that's what cozempic strips. It should stop the crash.

The guard daemon (cozempic guard) also prevents this from recurring — it monitors context and prunes automatically at a configurable threshold before the JSONL can grow unbounded.

github-actions[bot] · 1 month ago

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.