[Bug] Memory Leak When Initializing Sub-Agent Orchestration

Resolved 💬 18 comments Opened Sep 2, 2025 by hughescr Closed Feb 7, 2026

Bug Description
If I continue this session by issuing an instruction like "Continue as an orchestrator, directing sub-agents to perform the necessary work." claude code will start allocating memory until all system memory is exhausted and the process crashes. In a newly-launched claude session, Activity Monitor shows that the claude process has about 450MB allocated (once I resume the session); when I issue the command, I can watch it start allocating massive amounts of memory almost right away, growing to 500, 1GB, 1.5GB, 2GB, 4GB, 4.5GB, 6GB,....30GB, ...crash

It doesn't always begin the massive allocations immediately. Sometimes, it'll run a prompt for a while, seeming normal, but within a prompt or two it will innevitably get into the massive allocation state and crash.

Environment Info

Platform: darwin
Terminal: iTerm.app
Version: 1.0.100
Feedback ID: 5e71aaf2-81fd-47bb-b0a9-8a15b230127c

Errors

[]

View original on GitHub ↗

18 Comments

github-actions[bot] · 10 months ago

Found 3 possible duplicate issues:

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

hughescr · 10 months ago

Here's an example of the crash:

<--- Last few GCs --->

[43988:0x128008000]  1369682 ms: Scavenge (interleaved) 4057.2 (4096.9) -> 4056.4 (4100.9) MB, pooled: 0 MB, 4.33 / 0.00 ms  (average mu = 0.249, current mu = 0.192) allocation failure;
[43988:0x128008000]  1370434 ms: Mark-Compact 4059.9 (4100.9) -> 4051.3 (4101.4) MB, pooled: 0 MB, 749.25 / 0.00 ms  (average mu = 0.148, current mu = 0.020) allocation failure; scavenge might not succeed

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x1003d7814 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 2: 0x10051697c v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 3: 0x100516934 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 4: 0x1006f3550 v8::internal::Heap::stack() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 5: 0x1006f5c90 v8::internal::Heap::OldGenerationConsumedBytes() const [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 6: 0x1006f5b30 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector, v8::base::TimeTicks) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 7: 0x1007034bc v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::$_1::operator()() const [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 8: 0x100703160 void heap::base::Stack::SetMarkerAndCallbackImpl<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::$_1>(heap::base::Stack*, void*, void const*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
 9: 0x100e4b658 PushAllRegistersAndIterateStack [/opt/homebrew/Cellar/node/24.7.0/bin/node]
10: 0x1006f1b10 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
11: 0x1006e9718 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
12: 0x1006d13a4 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
13: 0x100a43f78 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
14: 0x100f0df74 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node/24.7.0/bin/node]
15: 0x100f18834 Builtins_CreateDataProperty [/opt/homebrew/Cellar/node/24.7.0/bin/node]
16: 0x100ea4a80 Builtins_CopyDataPropertiesWithExcludedPropertiesOnStack [/opt/homebrew/Cellar/node/24.7.0/bin/node]
17: 0x100ea4f4c Builtins_CopyDataPropertiesWithExcludedProperties [/opt/homebrew/Cellar/node/24.7.0/bin/node]
18: 0x1406a26e4
19: 0x1406a0f14
20: 0x140c28ea4
21: 0x140667284
22: 0x1407a8dd0
23: 0x140557384
24: 0x14078b344
25: 0x140684a14
26: 0x140b5fbf0
27: 0x100eaf648 Builtins_AsyncFunctionAwaitResolveClosure [/opt/homebrew/Cellar/node/24.7.0/bin/node]
28: 0x100f845f8 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/24.7.0/bin/node]
29: 0x100e9ea50 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/24.7.0/bin/node]
30: 0x100e6e7b0 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/24.7.0/bin/node]
31: 0x10064b7ac v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
32: 0x10064be58 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
33: 0x10064bf48 v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
34: 0x100670b44 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
35: 0x100670960 v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
36: 0x100e7294c Builtins_CallApiCallbackOptimizedNoProfiling [/opt/homebrew/Cellar/node/24.7.0/bin/node]
37: 0x140b76f84
38: 0x100e6e8cc Builtins_JSEntryTrampoline [/opt/homebrew/Cellar/node/24.7.0/bin/node]
39: 0x100e6e570 Builtins_JSEntry [/opt/homebrew/Cellar/node/24.7.0/bin/node]
40: 0x10064b7dc v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
41: 0x10064b1cc v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>, v8::base::Vector<v8::internal::DirectHandle<v8::internal::Object> const>) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
42: 0x100527e68 v8::Function::Call(v8::Isolate*, v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
43: 0x100324960 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
44: 0x100324b98 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context, v8::Local<v8::Value>) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
45: 0x100333684 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
46: 0x100498844 node::StreamBase::CallJSOnreadMethod(long, v8::Local<v8::ArrayBuffer>, unsigned long, node::StreamBase::StreamBaseJSChecks) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
47: 0x100499df4 node::EmitToJSStreamListener::OnStreamRead(long, uv_buf_t const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
48: 0x1004fa0b0 node::crypto::TLSWrap::ClearOut() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
49: 0x1004f9548 node::crypto::TLSWrap::Cycle() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
50: 0x1004fbd00 node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
51: 0x10049c5c4 node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
52: 0x10049ca80 node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, long, uv_buf_t const*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
53: 0x1055b3af0 uv__stream_io [/opt/homebrew/Cellar/libuv/1.51.0/lib/libuv.1.dylib]
54: 0x1055baca8 uv__io_poll [/opt/homebrew/Cellar/libuv/1.51.0/lib/libuv.1.dylib]
55: 0x1055aab58 uv_run [/opt/homebrew/Cellar/libuv/1.51.0/lib/libuv.1.dylib]
56: 0x1003253cc node::SpinEventLoopInternal(node::Environment*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
57: 0x100406cfc node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
58: 0x100406a90 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
59: 0x1003ad03c node::Start(int, char**) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
60: 0x1904beb98 start [/usr/lib/dyld]

hughescr · 10 months ago

Note: the crash seems to happen whether running under nodejs directly, under bunx, and under bunx --bun. I've tried deleting ~/.claude.json and starting afresh - crash still happens.

I'd ba happy to provide my settings.json, mcp.json etc if helpful.

hughescr · 10 months ago

Here's the crash running under bunx --bun:

Aborted()
============================================================
Bun v1.2.21 (7c45ed97) macOS Silicon
macOS v15.6.1
CPU: fp aes crc32 atomics
Args: "node" "/private/tmp/bunx-501-@anthropic-ai/claude-code@latest/node_modules/.bin/claude" "--mcp-config" "/Users/craig/.claude/mcp.json"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) bunfig fetch(81) jsc spawn(38) transpiler_cache tsconfig
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:console" "node:constants" "node:crypto" "node:dns" "node:domain" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/win32" "node:perf_hooks" "node:process" "node:querystring" "node:stream" "node:string_decoder" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:util/types" "node:zlib" "node:worker_threads" "node:inspector" "node:http2" "node:diagnostics_channel"
Elapsed: 180859ms | User: 136216ms | Sys: 14365ms
RSS: 0.08TB | Peak: 0.09TB | Commit: 0.02ZB | Faults: 81 | Machine: 0.14TB

panic(main thread): Segmentation fault at address 0x0
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.2.21/Mn17c45ed9YukkwggC_mq811C2hh41C291s1CmpvqsBmulqsBm79itBmiyitB2u4itBuw2/pBA2AA

rdparker · 10 months ago

Hitting what looks like the same issue on macOS with 1.0.115. I am developing some subagents for my workflows. When it didn't finish running over night I did a pkill -9 claude. Didn't think to check memory usage first.

After a claude --resume I did

```> /context
⎿ ⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ ⛁
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛶ Context Usage
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ claude-sonnet-4-20250514 • 35k/200k tokens (18%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System prompt: 3.2k tokens (1.6%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System tools: 12.0k tokens (6.0%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Custom agents: 350 tokens (0.2%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Memory files: 2.1k tokens (1.0%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Messages: 17.6k tokens (8.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Free space: 164.9k (82.4%)

Custom agents · /agents
└ devenv-expert (User): 46 tokens
└ auto-fixer (User): 41 tokens
└ pre-commit-validator (User): 49 tokens
└ smart-committer (User): 39 tokens
└ documentation-generator (User): 25 tokens
└ agent-builder (User): 44 tokens
└ workflow-orchestrator (User): 30 tokens
└ code-reviewer (User): 51 tokens
└ domain-research-patterns (User): 25 tokens

Memory files · /memory
└ User (/Users/<elided>/.claude/CLAUDE.md): 64 tokens
└ Project (/Users/<elided>/Source/agent-forge/CLAUDE.md): 2.0k tokens

I ran out of memory and disk space testing the workflow orchestrator and had to restart. Continue what you were doing.

⏺ workflow-orchestrator(Test workflow orchestrator)
⎿ Done (38 tool uses · 46.4k tokens · 18m 8.8s)

⏺ Test 2.7 Results: ✅ SUCCESS

The workflow-orchestrator performed exceptionally:

✅ Orchestrated complete 3-agent workflow (validator → fixer → committer)
✅ Coordinated agents with 66% cache hit rate
✅ Handled workflow state management across 19+ minutes
✅ Successfully committed fixes (commit e2caa95)
✅ Demonstrated error recovery capabilities

Phase 2 Complete! 🎉

All 7 agents tested successfully:

✅ agent-builder
✅ pre-commit-validator
✅ auto-fixer
✅ smart-committer
✅ documentation-generator
✅ domain-research-patterns
✅ workflow-orchestrator

Next: Phase 3 - Integration Testing (Test 3.1: Full Commit Workflow)

Ready to proceed with integration testing?

Ask workflow orchestrator what workflows exist

⏺ workflow-orchestrator(Query available workflows)
⎿ Done (19 tool uses · 35.8k tokens · 1m 7.8s)

⏺ The workflow-orchestrator has extensive capabilities! It can orchestrate:

Core Patterns:

Sequential, Parallel, Conditional, and Hybrid workflows

Pre-built Workflows:

Commit Validation (validator → fixer → committer)
Parallel Validation (concurrent linting/testing)
Agent Creation (builder → research → validation)

Available Agents:

All 7 core agents plus specialized validators
Multi-language support (JS/TS, Python, Rust, Shell, Markdown)

Advanced Features:

Intelligent caching with .claude/ directory
Real-time monitoring and performance analytics
Dynamic workflow selection based on project type
Error recovery with exponential backoff

Command Interface:
workflow_orchestrator --pattern=commit
workflow_orchestrator --workflow=parallel_validation
workflow-monitor status

The system is designed for comprehensive workflow automation with intelligent optimization!

Perform commit validation

⏺ workflow-orchestrator(Execute commit validation workflow)
⎿ Starting Commit Validation Workflow - Phase 1: Pre-commit Validation
+9 more tool uses

✶ Performing commit validation workflow… (esc to interrupt · ctrl+t to hide todos)
⎿ ☒ Execute Phase 1: Agent Availability Verification
☒ Check agent registration with /agents command
☒ Verify all 7 agents are visible
☒ Proceed to Phase 2: Individual Agent Functionality Tests
☒ Test 2.1: Agent Builder functionality
☒ Test 2.2: Pre-commit Validator functionality
☒ Test 2.3: Auto-fixer functionality
☒ Test 2.4: Smart Committer functionality
☒ Test 2.5: Documentation Generator functionality
☒ Test 2.6: Domain Research Patterns functionality
☒ Test 2.7: Workflow Orchestrator functionality
☐ Perform commit validation workflow


All the other agents work fine and are quick enough, but the workflow administrator struggles.

Currently 1.0.115 is at 35GB and growing while swapping like a mad man. If it would help I can push these to a public repo for reproduction.

rdparker · 10 months ago

While writing the above, it looks to have gotten killed by the system.

  agent-forge git:master+?↑4 Sonnet 4 09:19
  ⏵⏵ accept edits on (shift+tab to cycle)
Aborted()
[1]    98034 killed     claude --continue

rdparker · 10 months ago

Copied the same project to my much larger Linux system and it ran flawlessly never exceeding 200-300MB.

efstathiosntonas · 9 months ago

1.0.120 is killing Jetbrains

mnadler · 9 months ago

I'm experiencing this issue on Mac OS 15.6.1 (24G90).

This issue occurs every time and also appears on

Ubunutu 24.3 (running through Parallels on my M1 Mac)
Older version of Claude code (I specifically tested 1.0.80)

As soon as my orchestrator agent A calls sub-agent B the memory usage blows up and I have have to kill claude code. According the my logs, the code that agent B was supposed to call first thing was not entered. This points to the agent blowing up during initialization.

Here's the memory blow up over time:

Time RSS(MB) %MEM State
────────────────────────────────────────
0:00 242 0.7% Starting
0:06 268 0.8% Normal operation
0:08 546 1.6% ⚠️ SPIKE BEGINS
0:11 1,130 3.4%
0:20 2,737 8.2% Exponential growth
0:40 5,595 16.7%
1:00 6,980 20.8%
1:30 9,131 27.2% Peak
2:15 8,168 24.3% 💥 CRASH

Here's The Stack Trace
<--- Last few GCs --->

[72406:0x138008000] 58025 ms: Mark-Compact 4003.5 (4113.2) -> 3994.1 (4120.2) MB, pooled: 0 MB, 855.54 / 0.00 ms (average mu = 0.194, current mu = 0.097) allocation failure; scavenge might not succeed
[72406:0x138008000] 58941 ms: Mark-Compact 4011.2 (4121.2) -> 4001.1 (4127.5) MB, pooled: 0 MB, 899.04 / 0.00 ms (average mu = 0.111, current mu = 0.019) allocation failure; scavenge might not succeed

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0x10106f814 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
2: 0x1011ae97c v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
3: 0x1011ae934 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
4: 0x10138b550 v8::internal::Heap::stack() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
5: 0x10138dc90 v8::internal::Heap::OldGenerationConsumedBytes() const [/opt/homebrew/Cellar/node/24.7.0/bin/node]
6: 0x10138db30 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector, v8::base::TimeTicks) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
7: 0x10139b4bc v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::$_1::operator()() const [/opt/homebrew/Cellar/node/24.7.0/bin/node]
8: 0x10139b160 void heap::base::Stack::SetMarkerAndCallbackImpl<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::$_1>(heap::base::Stack, void, void const*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
9: 0x101ae3658 PushAllRegistersAndIterateStack [/opt/homebrew/Cellar/node/24.7.0/bin/node]
10: 0x101389b10 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
11: 0x101381718 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
12: 0x1013693a4 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
13: 0x1016dbf78 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long, v8::internal::Isolate) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
14: 0x101ba5f74 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node/24.7.0/bin/node]
15: 0x1405782cc
16: 0x1404b3ab4
17: 0x1403bc524
18: 0x1404ba42c
19: 0x140262bac
20: 0x14061f0f4
21: 0x1405b8a50
22: 0x1404a0b88
23: 0x1401a75bc
24: 0x101b08bec Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/24.7.0/bin/node]
25: 0x1406246f4
26: 0x101b08bec Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/24.7.0/bin/node]
27: 0x101b47648 Builtins_AsyncFunctionAwaitResolveClosure [/opt/homebrew/Cellar/node/24.7.0/bin/node]
28: 0x101c1c5f8 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/24.7.0/bin/node]
29: 0x101b36a50 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/24.7.0/bin/node]
30: 0x101b067b0 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/24.7.0/bin/node]
31: 0x1012e37ac v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
32: 0x1012e3e58 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
33: 0x1012e3f48 v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate, v8::internal::MicrotaskQueue) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
34: 0x101308b44 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
35: 0x101308960 v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
36: 0x101b0a94c Builtins_CallApiCallbackOptimizedNoProfiling [/opt/homebrew/Cellar/node/24.7.0/bin/node]
37: 0x1404a4804
38: 0x101b068cc Builtins_JSEntryTrampoline [/opt/homebrew/Cellar/node/24.7.0/bin/node]
39: 0x101b06570 Builtins_JSEntry [/opt/homebrew/Cellar/node/24.7.0/bin/node]
40: 0x1012e37dc v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
41: 0x1012e31cc v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>, v8::base::Vector<v8::internal::DirectHandle<v8::internal::Object> const>) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
42: 0x1011bfe68 v8::Function::Call(v8::Isolate, v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
43: 0x100fbc960 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
44: 0x100fbcb98 node::InternalMakeCallback(node::Environment, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>, node::async_context, v8::Local<v8::Value>) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
45: 0x100fcb684 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
46: 0x101130844 node::StreamBase::CallJSOnreadMethod(long, v8::Local<v8::ArrayBuffer>, unsigned long, node::StreamBase::StreamBaseJSChecks) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
47: 0x101131df4 node::EmitToJSStreamListener::OnStreamRead(long, uv_buf_t const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
48: 0x1011920b0 node::crypto::TLSWrap::ClearOut() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
49: 0x101191548 node::crypto::TLSWrap::Cycle() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
50: 0x101193d00 node::crypto::TLSWrap::OnStreamRead(long, uv_buf_t const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
51: 0x1011345c4 node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
52: 0x101134a80 node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s, long, uv_buf_t const) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
53: 0x10624baf0 uv__stream_io [/opt/homebrew/Cellar/libuv/1.51.0/lib/libuv.1.dylib]
54: 0x106252ca8 uv__io_poll [/opt/homebrew/Cellar/libuv/1.51.0/lib/libuv.1.dylib]
55: 0x106242b58 uv_run [/opt/homebrew/Cellar/libuv/1.51.0/lib/libuv.1.dylib]
56: 0x100fbd3cc node::SpinEventLoopInternal(node::Environment*) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
57: 0x10109ecfc node::NodeMainInstance::Run(node::ExitCode, node::Environment) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
58: 0x10109ea90 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/24.7.0/bin/node]
59: 0x10104503c node::Start(int, char**) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
60: 0x18f18eb98 start [/usr/lib/dyld]
zsh: abort claude

mnadler · 9 months ago

I've done some additional debugging. I have not been able to resolve, but I have ruled out a number of potential causes.

Here's a summary prepared by Claude Code:

Summary

Claude Code crashes with a JavaScript heap out of memory error when an agent uses the Task tool to spawn a
sub-agent. The crash occurs during the initialization phase, before the sub-agent executes any tools or
performs any work.

Environment

Claude Code Versions Tested:
1.0.80 ❌ (crashes)
1.0.88 ❌ (crashes)
2.0.5 ❌ (crashes)
Node.js Version: v24.7.0
Platforms Tested:
macOS Darwin 24.6.0 (ARM64) ❌ (crashes)
Ubuntu 24.3 (Linux) ❌ (crashes)
Shell: Terminal (zsh on macOS, bash on Linux)

Note: This issue affects all tested versions of Claude Code and all tested platforms, indicating a fundamental
issue in the agent orchestration system.

Reproduction Steps

Minimal Setup

Create an orchestrator agent with tools: TodoWrite, Task
Create a worker agent with tools: Read, Write, Edit, Bash, Grep, Glob, TodoWrite (no Task)
From Claude Code, invoke the orchestrator agent
Have orchestrator use Task tool to spawn the worker agent
Observe crash during worker agent initialization

Command That Triggers Crash

> run orchestrator for xxxxxx

Orchestrator successfully:

✅ Initializes
✅ Creates todo list with TodoWrite
✅ Invokes Task tool to spawn agent
⚠️ Shows "Warping... (15s - x 101 tokens - esc to interrupt)"
💥 Crashes with heap overflow

Error Output

<--- Last few GCs --->

[72406:0x138008000] 58025 ms: Mark-Compact 4003.5 (4113.2) -> 3994.1 (4120.2) MB, pooled: 0 MB, 855.54 / 0.00 ms
(average mu = 0.194, current mu = 0.097) allocation failure; scavenge might not succeed
[72406:0x138008000] 58941 ms: Mark-Compact 4011.2 (4121.2) -> 4001.1 (4127.5) MB, pooled: 0 MB, 899.04 / 0.00 ms
(average mu = 0.111, current mu = 0.019) allocation failure; scavenge might not succeed

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

The crash occurs in the microtask/promise fulfillment queue, suggesting an infinite or circular loading pattern
during agent initialization.

What Has Been Ruled Out

Through systematic debugging, we confirmed this is NOT caused by:

❌ Large project files - Crash occurs with empty/newly created projects with no content
❌ Log files - Moved all logs, still crashes
❌ Missing/or too verbose documentation - Docs referenced in agent instructions don't affect crash
❌ Image files - Crash occurs before any images are loaded (happens in empty projects)
❌ Tool access patterns - Explicitly restricting tools to exclude Task doesn't help
❌ Platform-specific issues - Reproduced on both macOS and Linux
❌ Version-specific regression - Affects versions 1.0.80, 1.0.88, and 2.0.5

Critical Finding

The crash happens during sub-agent initialization ("Warping"), not during:

Agent execution
Tool calls
File operations
Build pipeline execution

This suggests the issue is in Claude Code's agent metadata loading/preparation mechanism when spawning sub-agents
via the Task tool.

Hypothesis

When a sub-agent is spawned via Task:

Claude Code must initialize the sub-agent's context
This may involve loading all available agent definitions to populate tool options
Some circular reference, recursive loading, or memory leak occurs
Heap overflow happens before sub-agent can execute

Workarounds Attempted

❌ Increase Node.js heap limit (partial workaround)

export NODE_OPTIONS="--max-old-space-size=8192"
Result: May delay crash but doesn't fix root cause

❌ Reduce agent count/size

Result: Still crashes with 5 minimal agents (~45KB total)

❌ Avoid Task tool entirely

Result: Only workaround that works, but defeats purpose of agent orchestration

Expected Behavior

Sub-agent should initialize successfully and begin execution without memory issues.

Actual Behavior

Node.js heap overflow during sub-agent initialization, before any actual work is performed.

Impact

Severity: Critical - Makes agent orchestration patterns completely unusable
Scope: All Claude Code versions (1.0.80+), all platforms (macOS, Linux)
Workaround: None (except avoiding Task tool entirely)
Affected Features: Multi-agent workflows, agent delegation patterns

Additional Context

This affects production use of Claude Code's agent system. The orchestrator pattern (parent agent coordinating
multiple specialized sub-agents) is a documented feature but is currently completely unusable across all versions
and platforms due to this crash.

Project structure and agent definitions available upon request for reproduction.

sidikhanrei · 9 months ago

It appears that this behavior is triggered whenever THINK Mode is active. Without it, everything works as expected.

#8836 #1421 #4953 #9690

lifegenieai · 8 months ago

Windows System Confirmation - Crashes at 8GB with 3 Sub-Agents

Confirming this issue affects Windows systems as well. Same memory leak behavior when spawning sub-agents for research tasks.

System Specs:

OS: Windows 11
CPU: Intel i7-14700F (2.10 GHz)
RAM: 32GB (31.8 GB usable)
Claude Code version: [current production version]

Behavior:

Started with default Node heap limit (~4GB) - crashed immediately when spawning 3 research sub-agents
Increased NODE_OPTIONS to --max-old-space-size=8192 (8GB)
Process now reaches 8GB before crashing instead of 4GB - memory consumption jumps instantly when sub-agents spawn
Agent configuration: Simple research orchestrator spawning 3 parallel research agents (no complex file operations or large datasets)

Error logs showing progression:

First crash (4GB limit):
[29852:000001F38B161000] Mark-Compact 4042.1 (4129.8) -> 4036.6 (4140.1) MB
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Second crash (8GB limit):
[14108:000001EAB0A61000] Mark-Compact 8076.0 (8233.3) -> 8066.6 (8239.5) MB
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

The memory leak appears to scale with the increased limit - suggesting something in the sub-agent initialization is consuming unbounded memory rather than hitting a reasonable ceiling. On a 32GB RAM system, 3 research agents should not require anywhere near 8GB of heap.

Sceat · 7 months ago

The issue is pretty easy to reproduce,

Instant crash 10gb of ram taken

towry · 7 months ago

The issue is pretty easy to reproduce, <img alt="Image" width="1100" height="342" src="https://private-user-images.githubusercontent.com/11330271/519654684-0b280625-eb9d-465c-b821-a7c028f0cec3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjUzNTcxNTcsIm5iZiI6MTc2NTM1Njg1NywicGF0aCI6Ii8xMTMzMDI3MS81MTk2NTQ2ODQtMGIyODA2MjUtZWI5ZC00NjVjLWI4MjEtYTdjMDI4ZjBjZWMzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTEyMTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUxMjEwVDA4NTQxN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTAxMTFkMDA0YWUwZGVjNGM1NmJiYWFkYjliOWMwZTU2NmU2YzUzODA4ZDQ4MDU2ZjkxMTg3YmJlOGU1MmQxZDYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.0D8aMZjChOOd5UdD-GRBc0W6Sm4Ck9oZP7OU9U2AFuc"> Instant crash 10gb of ram taken

same issue, happens a lot with latest claude

kherchel · 6 months ago

Any update on this issue? I paid for the Max subscription specifically to be able to handle a huge amount of agents working in tandem, yet turns out Claude Code can't handle running even one or two subagents without going down.

Here's output from Claude Code 2.0.75 running on Linux. My CLAUDE.md instructs the agent to always delegate tasks to project-manager agent which is supposed to delegate the tasks to further subagents. This is the FIRST task I've given to Claude in that session too, and I've done it right after clearing all Claude Code cache and conversation files to make sure it's a clean slate:

```● I'll delegate these bug fixes to the project manager agent who will coordinate the specialist agents to fix them.

project-manager(Fix 3 frontend UI bugs)
⎿ Waiting… > /home/[redacted]/.claude/state/progress-ledger.json << 'EOF'
(No content)

+17 more tool uses (ctrl+o to expand)
ctrl+b to run in background

· Elucidating… (esc to interrupt · 1m 34s · ↓ 678 tokens)

<--- Last few GCs --->

[570173:0x45355000] 143550 ms: Mark-Compact 4026.8 (4134.1) -> 4017.9 (4141.4) MB, pooled: 0 MB, 1454.21 / 0.00 ms (average mu = 0.288, current mu = 0.130) allocation failure; scavenge might not
succeed
[570173:0x45355000] 145613 ms: Mark-Compact 4034.1 (4141.6) -> 4024.4 (4147.9) MB, pooled: 0 MB, 2029.39 / 0.00 ms (average mu = 0.152, current mu = 0.017) allocation failure; scavenge might not
succeed

<--- JS stacktrace --->

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

1: 0xe1603a node::OOMErrorHandler(char const*, v8::OOMDetails const&) [claude]
2: 0x11e3540 v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, v8::OOMDetails const&) [claude]
3: 0x11e3817 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, v8::OOMDetails const&) [claude]
4: 0x14110f5 [claude]
5: 0x142a989 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [claude]
6: 0x13ff038 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [claude]
7: 0x13fff65 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [claude]
8: 0x13d8c3e v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [claude]
9: 0x183a25c v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long, v8::internal::Isolate) [claude]
10: 0x7f4aaf66c476```

hughescr · 6 months ago

Might or might not be related to #17835 but I've not seen a crash since I added instructions to CLAUDE.md instructing the orchestrator to explicitly forbid sub-agents from ever calling skills

juanpablodlc · 5 months ago

My session 4bfc397a-6cc9-42d9-8617-6c1165a4d5e8 crashed because of this bug.

github-actions[bot] · 5 months ago

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.