Skip to content

[BUG] Session files grow unboundedly, causing OOM crash on startup ("Aborted (core dumped)") #20367

Closed as not planned

Description

@LorenzoNava99

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

  1. Run a long multi-agent session using subagents (e.g., batch orchestration with 100+ subagent tasks)
  2. Let the session run until it becomes very long
  3. Try to restart Claude Code from any directory
  4. 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 -20

Workaround:

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):

  1. Immediate: Add a file size check on startup; skip or warn about sessions > 100MB
  2. Short-term: Implement session compaction (summarize old tool outputs, keep recent messages)
  3. 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)

Image

Activity

  1. github-actions commented on Jan 23, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. Claude Code crashes with SIGABRT when session JSONL files exceed V8 heap limit #19025
    2. [BUG] Session files grow to multi-GB due to normalizedMessages duplication in subagent progress entries #19040
    3. [BUG] FileHistory bug: 4.2GB crash from parallel agents (Jan 2026) #18687

    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

  2. ianbmacdonald commented on Jan 23, 2026

    @ianbmacdonald

    Fits inside #19025 IMHO

  3. w0lf69 commented on Feb 21, 2026

    @w0lf69

    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_boundary events. Each compaction creates a new segment file (~2-5MB). The compaction summary at the start of the new file is already self-contained — --resume only 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.

  4. junaidtitan commented on May 21, 2026

    @junaidtitan

    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 (install uvx 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.

  5. rcgonzalezf commented on May 21, 2026

    @rcgonzalezf

    related? #29573

  6. github-actions commented on Jun 20, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  7. github-actions commented on Aug 23, 2026

    @github-actions

    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.

  8. locked as resolved and limited conversation to collaborators on Aug 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions