[BUG] Desktop app OOM on /compact with a much smaller transcript (~40MB) than previously reported crash threshold

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 28, 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?

Related to #69009, #67594, #50238, #48210 — all closed/locked (duplicate, not-planned, or completed-without-a-linked-fix) with no shipped-fix reference in any of the threads. Filing a new report per the auto-lock bot's own instruction ("if you're experiencing a similar issue, please file a new issue and reference this one").

All four linked issues report OOM crashes triggered by transcripts in the hundreds-of-MB to multi-GB range. This report adds a data point at a much lower threshold: a 40.7MB main session transcript, alongside 358 subagent transcript files totaling ~98MB in the same project, was enough to crash the app when running /compact on it — not just on desktop-app launch/Code-tab open as in the other reports.

This suggests the OOM isn't purely a "someone let a file reach 700MB+" edge case; the same unbounded full-materialization behavior described in #67594 (the /stats scan pushing every parsed entry into memory instead of folding during the streaming readline pass) likely applies to whatever /compact does internally, and it starts biting at file sizes an order of magnitude smaller.

Root cause isolation, done before concluding it was the transcript load:

  • Machine RAM: 48GB free at time of crash — not a host memory-pressure issue.
  • Not browser-related (no browser pane open in that session).
  • Not a mid-session model switch.
  • ~/.claude had grown to 2.1GB total over about 3 weeks: 438MB in main session transcripts, ~1.6GB in subagent transcripts + cached PDFs from WebFetch calls. No retention/cleanup policy had been set (cleanupPeriodDays was unset, i.e. default).

What Should Happen?

/compact (not just app launch / Code-tab /stats scan) should stream-parse and bound its memory use instead of loading the full transcript into the V8 heap, consistent with the fix direction already proposed in #67594.

Error Messages/Logs

No captured OOM stack trace / crash dump for this specific incident — the process exited during /compact without a diagnostic report being generated locally.

Steps to Reproduce

  1. Accumulate a session transcript in ~/.claude/projects/<project>/ that reaches roughly the low tens of MB (a few hundred subagent calls will get you there faster than main-thread turns alone).
  2. Run /compact on that session.
  3. App crashes with a V8 heap OOM.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Version 1.37937.3 (28dcf5)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Workaround applied:

  • Set cleanupPeriodDays: 7 in ~/.claude/settings.json.
  • Manually archived 1,736MB of old session/subagent data out of ~/.claude/projects/ to an external folder (reversible — just move back) to get back to a working state.
  • Going forward: once a session transcript reaches tens of MB, start a fresh session instead of running /compact on it.

View original on GitHub ↗