[BUG] VSCode extension: External/ArrayBuffer memory leak ~2 MB/sec during heavy tool use

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?

Description

Claude Code's VS Code extension process exhibits rapid external memory growth (~6,970 MB/hour / ~2 MB/sec) during sessions with active tool use. The leak is in native/external ArrayBuffer allocations, not the V8 managed heap.

Environment

• Claude Code: VS Code extension (latest as of 2026-03-30)
• Runtime: Bun (bundled with extension)
• OS: Windows 11 Home 10.0.26200
• Model: claude-opus-4-6 (1M context)
• MCP servers connected: 3 (Gmail, Google Calendar, custom stdio server)

Reproduction

1. Open Claude Code in VS Code
2. Run a session with heavy tool use:

• Multiple Bash tool calls with large stdout (>100 KB)
• Read tool on large files
• Several Write/Edit tool calls
• MCP tool calls over stdio transport

1. Monitor process.memoryUsage() via diagnostics

Memory reaches multiple GB within 10-15 minutes of active use.

Diagnostics

Captured at ~10 minutes uptime:

| Metric | Value |
|--------|-------|
| Heap used (V8) | 82 MB |
| RSS | 1.22 GB |
| External | 4.06 GB |
| ArrayBuffers | 3.46 GB |
| Growth rate | ~6,970 MB/hour (~2 MB/sec) |
| Heap size limit | 12.9 GB |
| Peak malloc | 1.29 GB |

Heap Snapshot Analysis

Captured a .heapsnapshot (42 MB on disk, V8 heap only — does not include the 3.46 GB external memory):

• V8 heap self-size: 115.7 MB (healthy)
• 2x WebAssembly.Memory: 32 MB (16 MB each, retained by JSLexicalEnvironment closures)
• 87 active stream readers with #pull, #onClose, #onDrain closures — each holding 256 KB Uint8Array read buffers
• 7 Blobs: 9.7 MB held in a single Array(6)
• 432 MCP-related strings in heap

Key Observation

The bulk of memory (3.46 GB / 85%) is in external and arrayBuffers, NOT the V8 managed heap (82 MB). This means:

• The leak is in native C++ buffer allocations managed by Bun's I/O layer
• Standard V8 heap snapshots cannot fully capture the leaked memory
• GC cannot reclaim these buffers — they require explicit deallocation

Suspected Cause

Stdio pipe read buffers from tool call results and MCP JSON-RPC communication are not being released after consumption. Each tool call's stdout/stderr response appears to allocate ArrayBuffers that persist beyond the tool call lifecycle. With 87 active stream readers each holding 256 KB buffers, plus accumulated large tool results, the external memory grows monotonically.

Sessions with minimal tool use do not exhibit the same growth rate.

Workaround

Restarting the session reclaims all memory. Reducing connected MCP servers and avoiding large tool outputs slows the growth rate.

What Should Happen?

Expected Behavior

• ArrayBuffers allocated for tool call stdout/stderr should be released after the

response is consumed and delivered to the conversation context. A tool result
read → parsed → delivered pipeline should not retain the underlying read buffers.

• MCP stdio pipe read buffers should be recycled or deallocated between JSON-RPC

messages, not accumulated across the session lifetime.

• External memory should follow a sawtooth pattern (allocate on tool call, release

after delivery) and plateau at steady-state, not grow monotonically.

• A 30-minute session with heavy tool use should stabilize well under 1 GB total

RSS, not reach 4+ GB in 10 minutes.

• Blob objects cached for plugin/skill content should have a bounded lifecycle

(TTL or LRU eviction), not persist indefinitely in a single growing array.

Error Messages/Logs

Steps to Reproduce

Reproduction

1. Open Claude Code in VS Code
2. Run a session with heavy tool use:

• Multiple Bash tool calls with large stdout (>100 KB)
• Read tool on large files
• Several Write/Edit tool calls
• MCP tool calls over stdio transport

1. Monitor process.memoryUsage() via diagnostics

Memory reaches multiple GB within 10-15 minutes of active use.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Opus 4.6 (1M context)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Regression Status

Unknown whether this is a regression or a longstanding issue. The external memory
growth may have been masked by shorter sessions or lighter tool use patterns.

Factors that may make this more visible now:

• Opus 4.6 (1M context) enables longer, heavier sessions than previous models
• Multiple MCP servers connected simultaneously (stdio transport multiplies buffer

allocations per tool call)

• Bun runtime (vs. Node.js in earlier versions?) may handle ArrayBuffer lifecycle

differently

If the team has internal telemetry on RSS/external memory over session lifetime,
comparing current builds against builds from before the Bun migration (or before
MCP stdio transport was added) would isolate when this started.