[BUG] FileHistory bug: 4.2GB crash from parallel agents (Jan 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?

Summary

Experiencing FileHistory session bloat 3 months after #9736/#9890 were reported and closed. Session grew to 4.2GB and crashed Claude with SIGTRAP. Filing new issue per bot guidance on #9736.

My Workflow (What Triggers This)

• Spawn multiple parallel agents to save main session context during research
• Example: "Spin up 5 agents to research different subsystems in parallel"
• Research-intensive sessions with many file reads over multiple days
• This feels like a legitimate use of the agent feature?

What Happened (Date: 2026-01-16)

• Session file grew to 4.2GB (4,205,949,251 bytes)
• Claude crashed on startup: zsh: trace trap claude (SIGTRAP)
• 100% reproducible in affected directory
• Session file located in ~/.claude/projects/

Session Analysis

Statistics:

• 643 lines total
• Longest single line: 107MB (contained 16 nested messages with 12 tool results)
• 20+ lines over 85MB each
• 80 file-history-snapshot entries
• 5,453 message entries

Comparison to #9736:

• #9736: 222MB session, 981,140 snapshots
• This bug: 4.2GB session (19x larger), different symptom pattern but same root cause

Root Cause (Hypothesis)

Two bugs working together:

1. FileHistory bug (#9736): Tracks deleted files forever, creates infinite snapshots
2. Agent transcript embedding: Parallel agents' full transcripts embed in parent session
3. Combined effect: FileHistory snapshots + massive agent transcripts = 107MB lines → 4.2GB crash

Parallel agent workflow appears to amplify the FileHistory bug significantly.

Note: This is my inference from bug reports and session analysis, not confirmed by Anthropic

Impact

• Session became unloadable, crashed on startup
• Spent ~1 hour during lunch debugging the issue
• During debugging, agent misdiagnosed issue as "nested Claude session" and ran git init, destroying 3 days of local git history
• (Note: git init is an expected risk when using agents with dangerous permissions)
• Had to debug from outside affected directory
• Lost local version history (wasn't backed up remotely, just used for local versioning)

More concerning: Bug causes cascading failures in Claude's debugging logic - agent misdiagnosed the problem and took destructive action based on incorrect analysis.

Current Workaround

Monitor session sizes ~daily. MY GUESS at safe thresholds (based on this crash):

• Normal: 4K-500K
• Large but OK: 1-10MB
• Wrap up: >100MB
• Stop using: >500MB
• Will crash: >1GB

Related Issues

• #9736 - FileHistory bug (closed "not planned" due to inactivity)
• #9890 - Duplicate of #9736 (closed, locked)
• #8829 - Parallel agents crashes
• #10107 - File-history disk exhaustion

Filing new issue per bot guidance on #9736: "If you're still experiencing this issue, please open a new issue"

What Should Happen?

Expected behavior:

1. Session files should not grow to multi-GB sizes under normal usage
2. Parallel agent workflows should be supported without exponential growth
3. FileHistory should stop tracking deleted files (not create infinite snapshots)
4. Claude should warn users before sessions become problematic (specific threshold TBD)
5. If crash inevitable, debugging agents should probably get better about misdiagnosing/destructive action, though I do accept this as a risk when en masse approving actions/skipping permissions

Assumed normal session sizes:

• Typical sessions (no heavy agent work): 4K-500K
• Sessions with some agent work: 1-25MB range
• Corrupt session: 4.2GB (roughly 200x-1000x larger than normal)

Note: I don't know what the "correct" size should be for parallel agent workflows post-fix - that's for Anthropic to determine based on their architecture.

---

ERROR MESSAGES/LOGS

When: On startup when opening Claude in affected directory:

zsh: trace trap claude

Error type: SIGTRAP (signal 5)

100% reproducible until corrupt session file removed

Error Messages/Logs

zsh: trace trap claude

Error type: SIGTRAP (signal 5)

Steps to Reproduce

Observed pattern (may help reproduce):

1. Use Claude Code in a git repository over multiple days
2. Frequently spawn parallel agents for research/sub-tasks

• Example: "Spin up 5 agents to research these subsystems: [areas]"

1. Create and delete files during sessions (triggers FileHistory tracking)
2. Continue pattern across multiple sessions

Observed outcome:

• Session file grew from normal size (4K-500K) to 4.2GB
• Crash occurred on next startup after reaching ~4GB

Detection commands:

# Find large session logs
find ~/.claude/projects -name "*.jsonl" -size +10M -exec ls -lh {} \;

# Check specific session size
du -h ~/.claude/projects/<your-project>/*.jsonl | sort -h

Note: Cannot provide minimal reproducible example. Bug appears to require combination of time, parallel agents, and FileHistory bug. Exact reproduction steps unknown.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.9 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Request

This bug is still active as of Jan 2026 (3 months after #9736). I feel my workflow using parallel agents for research/context management is a legitimate use case, so fixing the FileHistory bug so this workflow can be safely supported would be appreciated!

Other Asks/Observations

I wanted to add some context that might help with prioritization and preventing future incidents:

Documentation gap: Claude helped me search for official documentation on FileHistory, session storage limits, or parallel agent best practices before filing this report. The only references to FileHistory it found were in bug reports (#9736, #9890) - not in official docs. Users/Claude can't avoid issues they have no way to know exist.

Feature usage: Parallel agents are an advertised feature in Claude Code 2.1.x release notes. I used them for their intended purpose (maintaining context while delegating research sub-tasks). This seems like a reasonable use case the tool should support.

Lack of guardrails: The tool allowed my session to grow from normal size (4K-500K) to 4.2GB without any warnings, then crashed. Good engineering would include progressive warnings as sessions grow unusually large, with specific thresholds determined by the system's capabilities.

Why this matters: I don't think users should need to understand internal logging mechanisms to safely use advertised features. The cascading failure (session bloat → crash → agent misdiagnosis → data loss) suggests this bug could affect others using research-intensive workflows.

Not a complaint - trying to provide context that might help prioritize the fix and prevent similar issues for other users. Happy to discuss further or provide additional details. :)