Repository navigation
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
Claude Code crashes with "Aborted (core dumped)" on startup when large session files exist in ~/.claude/projects/.
The process memory climbs continuously (visible in btop/htop) until it reaches ~20GB, then gets OOM-killed. This happens regardless of which directory you start Claude Code from, because the session index is loaded globally on startup.
Session .jsonl files can grow to multiple gigabytes with no size limit, rotation, or compaction. In my case:
- One session file reached 2.1 GB
- Another reached 1.7 GB
These were multi-agent sessions using subagents for batch processing. The parent session file logs all subagent outputs, causing exponential growth.
Workaround: Manually move the large .jsonl files out of ~/.claude/projects/ to restore functionality.
What Should Happen?
Session files should have a size limit with indexing - not implemented for single session tracking
Error Messages/Logs
Aborted (core dumped)
No stack trace or error message is shown - the process simply gets killed by the OOM killer after memory usage reaches system limits.Steps to Reproduce
- Run a long multi-agent session using subagents (e.g., batch orchestration with 100+ subagent tasks)
- Let the session run until it becomes very long
- Try to restart Claude Code from any directory
- Observe memory usage climbing in htop/btop until OOM kill
To identify problematic files:
find ~/.claude -name "*.jsonl" -type f -exec du -h {} + 2>/dev/null | sort -rh | head -20Workaround:
mkdir -p ~/claude-session-backup
mv ~/.claude/projects/*/LARGE_SESSION_ID.jsonl ~/claude-session-backup/Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
2.1.17 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Terminal.app (macOS)
Additional Information
Root cause analysis:
Session files are append-only JSONL with no size management. The structure is:
~/.claude/projects/{project-path}/{session-id}.jsonl- main session log~/.claude/projects/{project-path}/{session-id}/subagents/- subagent logs
When using multi-agent workflows, the parent session records ALL subagent output in its own .jsonl file, in addition to the subagent's own log. This causes rapid growth.
Suggested fixes (in order of impact):
- Immediate: Add a file size check on startup; skip or warn about sessions > 100MB
- Short-term: Implement session compaction (summarize old tool outputs, keep recent messages)
- Long-term: Stream session data instead of loading entirely into memory; implement log rotation
Attached: Screenshot showing session file sizes (2.1GB and 1.7GB files)

Activity
github-actions commentedon Jan 23, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
ianbmacdonald commentedon Jan 23, 2026
Fits inside #19025 IMHO
w0lf69 commentedon Feb 21, 2026
Experiencing this as well — 386MB session JSONL with 142 compactions. Bun crashes with SIGABRT from memory pressure.
The root cause is that compaction appends to the same file instead of rotating. I've proposed a fix in #27505: rotate the JSONL at
compact_boundaryevents. Each compaction creates a new segment file (~2-5MB). The compaction summary at the start of the new file is already self-contained —--resumeonly needs the latest segment. Old segments stay on disk for history but aren't loaded at runtime.This would bring runtime memory from O(session_lifetime) to O(1) — in my case, 386MB → ~3MB.
junaidtitan commentedon May 21, 2026
The append-on-every-compaction behavior described in the thread is what produces these multi-hundred-MB files that OOM on load. Pruning the JSONL offline brings it back to a loadable size — on sessions like this the compact-summary-collapse pass alone removes the bulk of it. cozempic is built for exactly this:
cozempic treat <session-id> -rx aggressive --execute(installuvx cozempic; it writes a backup first), with a guard daemon to keep it from regrowing. Open source. Segment rotation would be the real fix, but this is what unblocks the crashed session today.rcgonzalezf commentedon May 21, 2026
related? #29573
github-actions commentedon Jun 20, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Aug 23, 2026
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.