claude-code - 💡(How to fix) Fix [BUG] Claude Code parent process consumes ~143 GB of RAM during a long multi-agent iOS/Swift/backend session [2 comments, 3 participants]

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?

Summary

The Claude Code desktop application consumed 143.52 GB of resident memory and triggered macOS's "Your system has run out of application memory" dialog during a prolonged development session involving multiple background subagents, iterative xcodebuild test runs, and a long-lived backend dev server run via the Bash tool. The machine reached a state where all user apps were paused and Claude was flagged for Force Quit.

This reproduces reliably near the end of a long session and has now required the user to force-quit + restart Claude Code twice within the same day.

Environment

• OS: macOS (Apple silicon; Xcode 26.2 simulator runtime, iPhone 16 Pro simulator).
• Claude Code version: current as of 2026-04-20.
• Session type: single long conversation thread, 4+ hours of active use.
• Experimental flags set earlier in the session: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in .claude/settings.local.json (team was created, failed to wake, then abandoned; session was kept running).
• Permission model: Bash(*) blanket-allowed in .claude/settings.local.json.

Observed

macOS's Force Quit dialog shows:

Screenshot attached in session.

Workload during the session

The parent Claude Code session was orchestrating three iOS-app tracks with several amplifying patterns that probably compound memory use:

1. ~12–15 background subagents spawned over the course of the session via the Agent tool, some re-used via SendMessage. Each produces a JSONL transcript written to /private/tmp/claude-501/<session-uuid>/tasks/*.output. Some of those files are 100+ KB.
2. Repeated xcodebuild test runs after iterative source changes. One specific failure mode amplifies output: an XCTAssertEqual on a complex NatalChart struct produces a single-line ~30 KB struct dump. I reran this test several times while iterating on a fix; each run returned the same giant-line output.
3. Long-running npm run dev backend server launched in the background (run_in_background: true) and deliberately kept running so an iOS simulator could hit it. Its stdout streams continuously to the harness's output file.
4. Large Python outputs from an ephemeris extractor that wrote ~23 K terms of generated Swift. The extractor runs quickly but produces long stdout listing all 36 file parse counts.
5. git diff / git status / git log runs on a working tree that has multiple large generated files (a 1.7 MB generated ELP2000Data.swift, a 3 MB JSON test corpus in tools/test_corpus.json).

Expected

Claude Code's parent process should stay in "usable desktop app" territory — hundreds of MB, not hundreds of GB — regardless of:

• How many subagents have been spawned in a session
• How long background Bash commands have been running
• How large a single tool result is (with persisted-to-disk fallback for oversized outputs — which the harness seems to try for some outputs already)
• How many repeated identical-output tool calls have been made

Hypotheses about the root cause

Listed by likelihood (without access to Claude Code internals):

1. Per-tool-call output retained in-memory even when persisted to disk. Several tool results during this session printed Output too large (NNKB). Full output saved to: /Users/<user>/.claude/projects/.../tool-results/<id>.txt — suggesting the harness has offload logic. But memory kept growing anyway. Possibly the offloaded content is still held in some other structure (UI history, undo buffer, rendered message DOM).

2. Subagent transcript files opened but not closed. A dozen+ background subagent outputs were created under /private/tmp/claude-501/<session>/tasks/. If the harness mmaps or opens those transcripts and holds them for the lifetime of the session, that compounds.

3. Streaming stdout from long-running background processes is buffered without a cap. The backend npm run dev ran for hours, emitting a steady stream of request-response JSON logs. If its output file isn't periodically truncated from the harness's perspective, the in-memory tail grows without bound.

4. Rendered conversation turns retain raw tool-result payloads (not just references). A long session with many tool calls each emitting kilobytes of output would accumulate. The 30KB-per-failing-test dump reran N times is a clear amplifier.

5. Electron / renderer process leak unrelated to content size — e.g. DOM nodes for long-scrollback, syntax-highlighted monospace blocks, or message-list virtualization that doesn't recycle off-screen nodes.

Reproduction sketch

Not deterministic but reliably reproduces in my workflow. Approximate recipe:

1. Open a fresh Claude Code session in a real repo.
2. Spawn 3–4 background subagents via the Agent tool with run_in_background: true.
3. Start a long-running background process via Bash(run_in_background: true) — e.g. a Node dev server or tail -f.
4. Run a heavy tool repeatedly (e.g. xcodebuild ... test) 5–10 times, especially where one test case emits a large diff output.
5. Send 5–10 SendMessage calls to agents across iterations.
6. Watch macOS Activity Monitor → the Claude Code process.

Expected within 1–3 hours of active iteration: Claude Code memory rises into the tens of GB and eventually triggers the Force Quit prompt.

Impact

• Forces the user to Force Quit and restart Claude Code, losing in-flight agent work that wasn't yet committed (mitigable by the agent aggressively committing — but that adds ceremony).
• Machine becomes unresponsive for minutes during swap thrash.
• Discourages long-session workflows that Claude Code is otherwise well-suited for.

Mitigations tried / discovered

• Restart. Reclaims memory fully; session context survives via committed files + a written plan + memory files the agent maintains.
• Avoid re-running failing tests with large dumps. Filter output with grep -E "(Executed|error:)" before streaming back.
• Kill long-running background shells between uses rather than leaving them up.
• Commit more frequently so a Force Quit costs less work.

None of these are satisfying; they're workarounds for a harness-level issue.

Requested

• Confirmation whether this is a known issue with a tracking number.
• Ideally: a per-session memory cap with a visible indicator + graceful warning before macOS takes over.
• Harness-level backpressure: when a tool result exceeds N KB, persist to disk AND drop it from the active memory representation of the turn (keep only the pointer).
• An explicit --debug-memory mode that dumps growth hotspots (per-turn, per-tool, per-subagent).

Notes for maintainers

• Session uuid visible in task paths: 97187ef7-dba2-430a-b7ea-ec281e1680be (from /private/tmp/claude-501/-Users-<user>-Documents-GitHub-SkyWiserApp/97187ef7-dba2-430a-b7ea-ec281e1680be/tasks/). If Anthropic wants to inspect the transcript(s) server-side, that id + a rough wall-clock window should be enough to locate them.
• Happy to capture an Activity Monitor "Sample" of the runaway process on the next repro if a memory-growth profile would help — just let me know where to send it.

What Should Happen?

Claude Code's parent process should stay in "usable desktop app" territory — hundreds of MB, not hundreds of GB — regardless of:

• How many subagents have been spawned in a session
• How long background Bash commands have been running
• How large a single tool result is (with persisted-to-disk fallback for oversized outputs — which the harness seems to try for some outputs already)
• How many repeated identical-output tool calls have been made

Error Messages/Logs

Steps to Reproduce

Reproduction sketch

Not deterministic but reliably reproduces in my workflow. Approximate recipe:

1. Open a fresh Claude Code session in a real repo.
2. Spawn 3–4 background subagents via the Agent tool with run_in_background: true.
3. Start a long-running background process via Bash(run_in_background: true) — e.g. a Node dev server or tail -f.
4. Run a heavy tool repeatedly (e.g. xcodebuild ... test) 5–10 times, especially where one test case emits a large diff output.
5. Send 5–10 SendMessage calls to agents across iterations.
6. Watch macOS Activity Monitor → the Claude Code process.

Expected within 1–3 hours of active iteration: Claude Code memory rises into the tens of GB and eventually triggers the Force Quit prompt.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.90

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response