Repository navigation
[Bug] Memory Leak When Initializing Sub-Agent Orchestration #7020
Description
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
[]
Activity
github-actions commentedon Sep 2, 2025
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
hughescr commentedon Sep 2, 2025
Here's an example of the crash:
hughescr commentedon Sep 2, 2025
Note: the crash seems to happen whether running under nodejs directly, under
bunx, and underbunx --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 commentedon Sep 2, 2025
Here's the crash running under
bunx --bun:rdparker commentedon Sep 16, 2025
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 --resumeI didAll 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 commentedon Sep 16, 2025
While writing the above, it looks to have gotten killed by the system.
rdparker commentedon Sep 16, 2025
Copied the same project to my much larger Linux system and it ran flawlessly never exceeding 200-300MB.
efstathiosntonas commentedon Sep 22, 2025
1.0.120 is killing Jetbrains
mnadler commentedon Oct 1, 2025
I'm experiencing this issue on Mac OS 15.6.1 (24G90).
This issue occurs every time and also appears on
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⚠️ SPIKE BEGINS
────────────────────────────────────────
0:00 242 0.7% Starting
0:06 268 0.8% Normal operation
0:08 546 1.6%
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::DirectHandlev8::internal::Object, v8::internal::DirectHandlev8::internal::Object, v8::base::Vector<v8::internal::DirectHandlev8::internal::Object const>) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
42: 0x1011bfe68 v8::Function::Call(v8::Isolate*, v8::Localv8::Context, v8::Localv8::Value, int, v8::Localv8::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::Localv8::Object, v8::Localv8::Object, v8::Localv8::Function, int, v8::Localv8::Value, node::async_context, v8::Localv8::Value) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
45: 0x100fcb684 node::AsyncWrap::MakeCallback(v8::Localv8::Function, int, v8::Localv8::Value) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
46: 0x101130844 node::StreamBase::CallJSOnreadMethod(long, v8::Localv8::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 commentedon Oct 4, 2025
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
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
Command That Triggers Crash
Orchestrator successfully:
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 -----
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]
...
50: 0x101b36a50 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/24.7.0/bin/node]
51: 0x101b067b0 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/24.7.0/bin/node]
52: 0x1012e37ac v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous
namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/24.7.0/bin/node]
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:
Critical Finding
The crash happens during sub-agent initialization ("Warping"), not during:
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:
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
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 commentedon Oct 17, 2025
It appears that this behavior is triggered whenever THINK Mode is active. Without it, everything works as expected.
#8836 #1421 #4953 #9690
lifegenieai commentedon Oct 25, 2025
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:
Behavior:
--max-old-space-size=8192(8GB)Error logs showing progression:
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 commentedon Nov 27, 2025
The issue is pretty easy to reproduce,
Instant crash 10gb of ram taken
towry commentedon Dec 10, 2025
same issue, happens a lot with latest claude
kherchel commentedon Dec 21, 2025
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:
hughescr commentedon Jan 13, 2026
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 commentedon Feb 2, 2026
My session 4bfc397a-6cc9-42d9-8617-6c1165a4d5e8 crashed because of this bug.
github-actions commentedon Feb 15, 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.