Skip to content

Memory leak: 14K ArrayBuffers accumulate from streaming responses (~480 MB/hour) #32920

Closed as not planned

Description

@kevin-tcircuits

Description

Claude Code accumulates ArrayBuffer objects over time, leading to significant memory growth. After ~14.5 hours of uptime, the process consumed ~7 GB of RAM with a steady growth rate of ~480 MB/hour.

Environment

  • Claude Code version: 2.1.71
  • Node.js: v24.3.0
  • Platform: Linux (Ubuntu 22.04, WSL2, x86_64)

Heap Dump Analysis

Captured a V8 heap snapshot (/heapdump) and diagnostics JSON. Key findings:

Memory Breakdown

Metric Value
RSS 6.9 GB
V8 Heap (JS objects) 70 MB
External/Native memory 7.56 GB
ArrayBuffers 6.83 GB
Growth rate 478.6 MB/hour
Uptime at capture ~14.5 hours

Heap Snapshot Object Breakdown

Object Type Count Aggregate Size
ArrayBuffer 14,002 6,512 MB
Response (native HTTP) 2 446 MB
Uint8Array (views) 14,228 ~2 MB (metadata)
Blob (native) ~5 ~7 MB
All other JS objects ~640K ~57 MB

The V8 JS heap itself is tiny (70 MB). Nearly all memory is in external/native allocations backing ArrayBuffer objects.

Pattern

  • ~14,000 ArrayBuffers, mostly 0.5 MB each, with a few at 16-32 MB
  • Two retained native Response objects at 223 MB each (HTTP API responses)
  • 14,228 Uint8Array views corresponding to the ArrayBuffers
  • Growth rate of ~16 new 0.5 MB buffers per minute, consistent with streaming API token delivery

Diagnostics JSON Summary

{
  "memoryUsage": {
    "heapUsed": 7613741617,
    "heapTotal": 70292480,
    "external": 7562328657,
    "arrayBuffers": 6829807179,
    "rss": 7256211456
  },
  "memoryGrowthRate": {
    "bytesPerSecond": 139398.6,
    "mbPerHour": 478.6
  },
  "analysis": {
    "potentialLeaks": ["High memory growth rate: 478.6 MB/hour"]
  }
}

Likely Cause

Streaming API response chunks (ArrayBuffers) and/or their backing native Response objects are not being released after consumption. The steady linear growth rate and uniform ~0.5 MB buffer size point to per-chunk allocations from the Anthropic API streaming responses that are retained indefinitely.

Workaround

Restart Claude Code periodically (every few hours) to reclaim memory.

Activity

  1. added
    bugSomething isn't working
    duplicateThis issue or pull request already exists
    has reproHas detailed reproduction steps
    platform:wslIssue specifically occurs on WSL
    platform:linuxIssue specifically occurs on Linux
    on Mar 10, 2026
  2. kevin-tcircuits commented on Mar 10, 2026

    @kevin-tcircuits
    Author

    Possible Duplicates

    This appears to be a widely reported issue on v2.1.71. Related reports with the same ArrayBuffer accumulation pattern:

    Older related reports:

    This issue's heap snapshot data (14K x 0.5 MB ArrayBuffers + 2x 223 MB retained native Response objects) may help pinpoint the specific retention path.

  3. TweedBeetle commented on Mar 12, 2026

    @TweedBeetle

    Adding a finding from independent heap snapshot analysis (v2.1.72, Node v24.3.0, macOS) that may point to a separate, smaller leak:

    Unconsumed HTTP Response retained by pending Promise chain (181 MB)

    A single native::Response object (181.59 MB) is kept alive by an unconsumed stream whose onend callback never fires:

    Response (181 MB)
      <- IncomingMessage via "FetchAPI"
      <- JSLexicalEnvironment via "response"
        <- closures via "stream"/"src"
          <- Generator
            <- PromiseReaction
              <- Promise (pending)
                <- Object via "end"  (onend never fired)
    

    This is distinct from the ArrayBuffer accumulation -- it's a single HTTP response body that was never fully consumed/drained, so the stream holds the entire body in memory indefinitely via a pending Promise.

    Additionally, 46 Readable streams hold remainingChunk references to Uint8Array views backed by leaked ArrayBuffers, confirming the stream/transport origin of the main leak:

    Uint8Arrays >= 1KB: 58
      46 refs | Readable [remainingChunk]
      46 refs | JSLexicalEnvironment [chunk]
      4 refs  | NativeReadableStreamSource [data]
    

    Closed #33570 in favor of this issue.

  4. github-actions commented on Apr 10, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  5. github-actions commented on Apr 18, 2026

    @github-actions

    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.

  6. locked as resolved and limited conversation to collaborators on Apr 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingduplicateThis issue or pull request already existshas reproHas detailed reproduction stepsperf:memoryplatform:linuxIssue specifically occurs on Linuxplatform:wslIssue specifically occurs on WSLstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions