claude-code - 💡(How to fix) Fix [BUG] Memory leak, Claude Code CLI sessions persist for days in VSCode integrated terminal, each consuming up to 1.25 GB until host runs out of RAM [1 comments, 2 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?

Environment

CLI invocation (full args from ps):

claude --output-format stream-json --verbose --input-format stream-json \
  --effort max --model claude-opus-4-7[1m] --permission-prompt-tool stdio \
  --allowedTools mcp__computer-use,mcp__ccd_session__spawn_task,...  \
  --setting-sources=user,project,local --permission-mode default \
  --allow-dangerously-skip-permissions --include-partial-messages \
  --plugin-dir ... --replay-user-messages --settings {}

Summary

When running claude inside the VSCode integrated terminal across multiple project folders over time, CLI sessions are not cleaned up when their hosting terminal panel is closed or when the user walks away. Each session continues to grow in memory footprint, monotonically, until the system is exhausted.

On 2026-05-05 my Mac became completely unresponsive (WindowServer watchdog timeout) and required a hard reset. Forensic analysis of the macOS spin report (/Library/Logs/DiagnosticReports/WindowServer_2026-05-05-100644_MacBook-Air.userspace_watchdog_timeout.spin) revealed 23 zombie claude Node processes consuming a combined 19.47 GB of memory footprint on a 16 GB machine.

Evidence: full process table from spin report

Source: macOS userspace_watchdog_timeout spin report captured 2026-05-05 10:06:17 UTC-4, ~4 minutes before forced reboot at 10:10.

Filter: only node processes from /opt/homebrew/*/node with footprint > 100 MB. (All instances confirmed identical via UUID 4EC815EE-775A-3897-BA9A-A5C28EB9D16D and same Codesigning ID.)

Aggregate: 23 sessions, 19.47 GB total, average 866.9 MB/session, max 1256.2 MB.

What Should Happen?

The two critical observations

1. Sessions persist for days

Five sessions were running for 6.77 days continuously. These were started on 2026-04-28 and survived through:

• Multiple VSCode window closes
• VSCode itself restarting (the integrated terminals would have closed)
• A laptop sleep/wake cycle

This indicates the CLI is not receiving or honoring SIGHUP when its parent terminal closes, OR is detaching from the parent.

2. Memory grows monotonically with time

Plotting footprint vs. uptime shows a clear correlation:

The 6.8-day cohort is anomalously lower than the 20-hour cohort. One hypothesis: those older sessions were spawned by an older Claude Code version (2.1.126) which may have had different memory characteristics, while the newer 20-hour cohort uses 2.1.128. Still, the within-cohort consistency (all 20-hour sessions converge to ~1.1–1.25 GB regardless of actual usage) strongly suggests an internal cap or growth pattern that doesn't release.

Error Messages/Logs

Steps to Reproduce

Reproduction steps

1. Install Claude Code extension in VSCode (anthropic.claude-code v2.1.128).
2. Open a workspace, launch claude in the integrated terminal, have a brief conversation (does not need to be heavy).
3. Open a different project in a new VSCode window. Repeat step 2.
4. Continue this pattern across ~5–10 projects over a week of normal work.
5. Periodically: close VSCode windows, switch projects, let the laptop sleep overnight.
6. After several days, run:

   ps aux | grep "claude.*stream-json" | grep -v grep

   Observe many surviving sessions, each consuming hundreds of MB to >1 GB.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.126 and 2.1.128

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Expected behavior

• When the hosting terminal panel/tab is closed, the claude process should receive SIGHUP and exit cleanly within a reasonable timeout.
• Per-session memory should be bounded; an idle session should not grow over time.
• If a session must persist across UI closures, there should be a clear mechanism to discover and terminate them (a claude --list-sessions / claude --kill-orphans would be ideal).

Actual behavior

• Sessions survive for days regardless of UI state.
• Memory grows from ~100 MB at fork time toward what appears to be a ~1.25 GB plateau within ~20 hours of being alive (even when idle / not in foreground).
• No user-visible inventory of running sessions; the only way I discovered this was via post-mortem of a kernel watchdog timeout.

Impact

System hard-locked, requiring forced reboot. Lost in-flight work in multiple applications. Workflow on a 16 GB machine becomes essentially unsustainable: 23 idle Claude Code sessions consumed 122% of physical RAM, before counting VSCode itself (~9 GB across 37 helper processes), Chrome (~3 GB), and Podman/krunkit (3.9 GB).

This is not a "machine is underspecced" issue — 16 GB is the most common configuration for Apple Silicon Macs sold in 2024–2026 and a fully supported developer environment per Anthropic docs.

Suggested investigation paths

1. Signal handling: verify the CLI's SIGHUP/SIGTERM behavior in stream-json mode — does the --input-format stream-json mode change parent-death handling?
2. Detachment: check whether the CLI is calling setsid() or otherwise dissociating from its controlling terminal.
3. Memory growth: profile a long-lived idle session (e.g., 24h) to identify what's growing — likely candidates are transcript buffers, MCP server response cache, or accumulating event listeners on the streaming JSON parser.
4. Self-cleanup: consider an idle-timeout that terminates sessions inactive for >N hours, with a clear UX signal (banner / log line) before exit.

Workaround for affected users (in the meantime)

# Identify zombie sessions
ps -eo pid,etime,rss,command | grep "claude.*stream-json" | grep -v grep

# Kill all zombie Claude Code CLI sessions
pkill -f "claude.*--output-format stream-json"

Adding this to a daily launchd job is a reasonable mitigation while the underlying issue is investigated.