[BUG] Claude Code v2.1.9 OOM Crash During Parallel Explore Agents

Resolved 💬 3 comments Opened Jan 16, 2026 by coygeek Closed Jan 19, 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?

Claude Code crashes with a fatal JavaScript heap out of memory error when running parallel Explore agents that perform extensive file searches across large directories. The application aborts after the V8 heap reaches ~4GB.

The crash occurs during ArrayPrototypeJoin operations, suggesting the memory exhaustion happens when assembling or concatenating search results from multiple parallel agents.

What Should Happen?

Claude Code should:

  1. Handle large search operations without exhausting heap memory
  2. Apply memory limits or pagination to agent results
  3. Gracefully degrade or warn before reaching OOM conditions
  4. Not crash and lose the user's session/work

Error Messages/Logs

<--- Last few GCs --->

[59531:0xc36800000]   206660 ms: Mark-Compact 4068.7 (4151.3) -> 4044.3 (4126.9) MB, pooled: 1 MB, 930.08 / 0.00 ms  (average mu = 0.296, current mu = 0.017) allocation failure; scavenge might not succeed
[59531:0xc36800000]   207421 ms: Mark-Compact 4099.1 (4181.7) -> 4062.6 (4145.2) MB, pooled: 1 MB, 737.04 / 0.00 ms  (average mu = 0.296, current mu = 0.031) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x104b5225c node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/user/.pocket-server/bin/node]
 2: 0x104d284fc v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/user/.pocket-server/bin/node]
 3: 0x104f37c24 v8::internal::Heap::stack() [/Users/user/.pocket-server/bin/node]
 4: 0x104f35fc4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/user/.pocket-server/bin/node]
 5: 0x104f2a5ac v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/user/.pocket-server/bin/node]
 6: 0x104f2ade4 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/user/.pocket-server/bin/node]
 7: 0x104f0e104 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/user/.pocket-server/bin/node]
 8: 0x105329bb4 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/user/.pocket-server/bin/node]
 9: 0x1057edaf4 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/user/.pocket-server/bin/node]
10: 0x1058147e8 Builtins_ArrayPrototypeJoin [/Users/user/.pocket-server/bin/node]
...
[1]    59531 abort      claude --dangerously-skip-permissions


Key observations:
- Heap reached 4068MB before crash
- GC efficiency dropped to mu = 0.017 (very poor)
- Crash in `ArrayPrototypeJoin` suggests string/array concatenation of large results
- One agent had earlier logged: `Error: File content (3.4MB) exceeds maximum allowed size (256KB)`

Steps to Reproduce

  1. Start Claude Code v2.1.9 with a non-git working directory (e.g., home directory)
  2. Enter plan mode (shift+tab to cycle to plan mode)
  3. Issue a prompt that triggers multiple parallel Explore agents searching large directories:
research all of my working projects to see which ones mention [search term].
meaning some projects were put on hold. now we can implement,
reanalyze all working projects to see where this makes sense.
  1. Claude launches parallel Task(subagent_type="Explore") agents that:
  • Search /Users/user/Desktop/@DONE (contains many projects)
  • Search /Users/user/.claude/hooks (contains many files)
  • Each agent performs multiple grep/search operations with patterns
  • Agents read multiple CLAUDE.md and other files
  1. After ~1.5 minutes of parallel agent activity, Claude Code crashes with OOM

Environment details from session:

  • Model: Opus 4.5
  • Context at crash: 39.7k tokens (19.9%)
  • Session duration: ~1m 28s
  • Platform: macOS (Darwin)
  • Node binary: /Users/user/.pocket-server/bin/node

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.9

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Contributing Factors

  1. Parallel agents: Two Explore agents running simultaneously, each accumulating results
  2. Large search scope: Searching across directories with many projects/files
  3. No apparent memory limits: Agents don't appear to have result size limits
  4. Large file rejection but continued execution: One agent hit the 256KB file size limit but the session continued until OOM

Session State at Crash

From the status line captured before crash:

cwd: /Users/user
Session: 1m  Block: 0hr 46m
no git  (no git)
[Timeout]
Model: Opus 4.5  v2.1.9
Ctx: 39.7k  Ctx: 19.9%  Ctx(u): 24.8%
plan mode on

Note the [Timeout] indicator appeared before the crash, suggesting timing issues before the OOM.

Suggested Mitigations

  1. Add memory monitoring and graceful degradation before OOM
  2. Implement result pagination/streaming for agent outputs
  3. Add aggregate size limits for parallel agent results
  4. Consider running agents with constrained memory budgets
  5. Implement emergency session save before crash detection

Hooks Active During Session

Multiple SessionStart and PreToolUse hooks were running, including a constrain_task_output.py hook that was supposed to limit output size (but may not have been sufficient to prevent the OOM).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗