[BUG]

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?

I read the diagnostics. Both warnings are false positives — there's no leak here.

Why the warnings fired:

1. "High memory growth rate: 274,747 MB/hour" — this is bytesPerSecond × 3600 extrapolation, but uptimeSeconds: 3.589. The process is 3.6 seconds old. The script is dividing fresh-startup allocation (~287MB RSS) by 3.6s and projecting linearly — meaningless on a young process. A real growth metric needs at least two snapshots minutes apart.

1. "Native memory > heap — leak may be in node-pty/sharp" — the runtime here is Bun, not Node (Bun: 1 in objectTypeCounts, mimalloc.mimalloc_version: 30301, nodeVersion field is ignored — Bun ships its own JSC + mimalloc). Bun reserves a 1GB virtual arena up front (mimalloc.reserved.total: 1,076,166,656) but only commits ~87MB (mimalloc.committed.current: 86,507,520). The smapsRollup confirms real RSS is 271MB, of which only 197MB is private dirty (actually used). The "native > heap" heuristic was written for Node + V8 and doesn't apply to Bun's allocator.

What the snapshot actually shows (after 3.6s of life):

• activeHandles: 0, activeRequests: 0 — nothing pinned to the event loop right now
• JS heap: 76MB / 51MB used — normal for the CLI's bundle size
• 161,618 Functions / 36,458 FunctionExecutables — that's the loaded bundle, not a leak

One thing mildly worth noting (not a leak, just an observation): protectedObjectTypeCounts shows 73 GC-rooted ReadableStreams, 79 Responses, 208 Headers. If a long-running session accumulated fetch responses without draining their bodies, that would leak — but at 3.6s of uptime it's just the in-flight startup fetches. Re-snapshot after 5–10 minutes of active use; if those numbers grow monotonically, that's the real signal.

Recommendation: no fix needed. If you want to actually validate, run the heap dump twice with several minutes of usage between, then diff protectedObjectTypeCounts and objectTypeCounts. A flat or oscillating count is healthy; monotonic growth on ReadableStream / Response / Promise / Timeout is a real lead.

What Should Happen?

I read the diagnostics. Both warnings are false positives — there's no leak here.

Why the warnings fired:

1. "High memory growth rate: 274,747 MB/hour" — this is bytesPerSecond × 3600 extrapolation, but uptimeSeconds: 3.589. The process is 3.6 seconds old. The script is dividing fresh-startup allocation (~287MB RSS) by 3.6s and projecting linearly — meaningless on a young process. A real growth metric needs at least two snapshots minutes apart.

1. "Native memory > heap — leak may be in node-pty/sharp" — the runtime here is Bun, not Node (Bun: 1 in objectTypeCounts, mimalloc.mimalloc_version: 30301, nodeVersion field is ignored — Bun ships its own JSC + mimalloc). Bun reserves a 1GB virtual arena up front (mimalloc.reserved.total: 1,076,166,656) but only commits ~87MB (mimalloc.committed.current: 86,507,520). The smapsRollup confirms real RSS is 271MB, of which only 197MB is private dirty (actually used). The "native > heap" heuristic was written for Node + V8 and doesn't apply to Bun's allocator.

What the snapshot actually shows (after 3.6s of life):

• activeHandles: 0, activeRequests: 0 — nothing pinned to the event loop right now
• JS heap: 76MB / 51MB used — normal for the CLI's bundle size
• 161,618 Functions / 36,458 FunctionExecutables — that's the loaded bundle, not a leak

One thing mildly worth noting (not a leak, just an observation): protectedObjectTypeCounts shows 73 GC-rooted ReadableStreams, 79 Responses, 208 Headers. If a long-running session accumulated fetch responses without draining their bodies, that would leak — but at 3.6s of uptime it's just the in-flight startup fetches. Re-snapshot after 5–10 minutes of active use; if those numbers grow monotonically, that's the real signal.

Recommendation: no fix needed. If you want to actually validate, run the heap dump twice with several minutes of usage between, then diff protectedObjectTypeCounts and objectTypeCounts. A flat or oscillating count is healthy; monotonic growth on ReadableStream / Response / Promise / Timeout is a real lead.

Error Messages/Logs

I read the diagnostics. Both warnings are **false positives** — there's no leak here.

**Why the warnings fired:**

1. **"High memory growth rate: 274,747 MB/hour"** — this is `bytesPerSecond × 3600` extrapolation, but `uptimeSeconds: 3.589`. The process is **3.6 seconds old**. The script is dividing fresh-startup allocation (~287MB RSS) by 3.6s and projecting linearly — meaningless on a young process. A real growth metric needs at least two snapshots minutes apart.

2. **"Native memory > heap — leak may be in node-pty/sharp"** — the runtime here is **Bun**, not Node (`Bun: 1` in objectTypeCounts, `mimalloc.mimalloc_version: 30301`, `nodeVersion` field is ignored — Bun ships its own JSC + mimalloc). Bun reserves a 1GB virtual arena up front (`mimalloc.reserved.total: 1,076,166,656`) but only commits ~87MB (`mimalloc.committed.current: 86,507,520`). The smapsRollup confirms real RSS is **271MB**, of which only **197MB is private dirty** (actually used). The "native > heap" heuristic was written for Node + V8 and doesn't apply to Bun's allocator.

**What the snapshot actually shows (after 3.6s of life):**
- `activeHandles: 0`, `activeRequests: 0` — nothing pinned to the event loop right now
- JS heap: 76MB / 51MB used — normal for the CLI's bundle size
- 161,618 Functions / 36,458 FunctionExecutables — that's the loaded bundle, not a leak

**One thing mildly worth noting** (not a leak, just an observation): `protectedObjectTypeCounts` shows 73 GC-rooted `ReadableStream`s, 79 `Response`s, 208 `Headers`. If a long-running session accumulated fetch responses without draining their bodies, *that* would leak — but at 3.6s of uptime it's just the in-flight startup fetches. Re-snapshot after 5–10 minutes of active use; if those numbers grow monotonically, that's the real signal.

**Recommendation:** no fix needed. If you want to actually validate, run the heap dump twice with several minutes of usage between, then diff `protectedObjectTypeCounts` and `objectTypeCounts`. A flat or oscillating count is healthy; monotonic growth on `ReadableStream` / `Response` / `Promise` / `Timeout` is a real lead.

Steps to Reproduce

I read the diagnostics. Both warnings are false positives — there's no leak here.

Why the warnings fired:

1. "High memory growth rate: 274,747 MB/hour" — this is bytesPerSecond × 3600 extrapolation, but uptimeSeconds: 3.589. The process is 3.6 seconds old. The script is dividing fresh-startup allocation (~287MB RSS) by 3.6s and projecting linearly — meaningless on a young process. A real growth metric needs at least two snapshots minutes apart.

1. "Native memory > heap — leak may be in node-pty/sharp" — the runtime here is Bun, not Node (Bun: 1 in objectTypeCounts, mimalloc.mimalloc_version: 30301, nodeVersion field is ignored — Bun ships its own JSC + mimalloc). Bun reserves a 1GB virtual arena up front (mimalloc.reserved.total: 1,076,166,656) but only commits ~87MB (mimalloc.committed.current: 86,507,520). The smapsRollup confirms real RSS is 271MB, of which only 197MB is private dirty (actually used). The "native > heap" heuristic was written for Node + V8 and doesn't apply to Bun's allocator.

What the snapshot actually shows (after 3.6s of life):

• activeHandles: 0, activeRequests: 0 — nothing pinned to the event loop right now
• JS heap: 76MB / 51MB used — normal for the CLI's bundle size
• 161,618 Functions / 36,458 FunctionExecutables — that's the loaded bundle, not a leak

One thing mildly worth noting (not a leak, just an observation): protectedObjectTypeCounts shows 73 GC-rooted ReadableStreams, 79 Responses, 208 Headers. If a long-running session accumulated fetch responses without draining their bodies, that would leak — but at 3.6s of uptime it's just the in-flight startup fetches. Re-snapshot after 5–10 minutes of active use; if those numbers grow monotonically, that's the real signal.

Recommendation: no fix needed. If you want to actually validate, run the heap dump twice with several minutes of usage between, then diff protectedObjectTypeCounts and objectTypeCounts. A flat or oscillating count is healthy; monotonic growth on ReadableStream / Response / Promise / Timeout is a real lead.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

claude-code

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

I read the diagnostics. Both warnings are false positives — there's no leak here.

Why the warnings fired:

1. "High memory growth rate: 274,747 MB/hour" — this is bytesPerSecond × 3600 extrapolation, but uptimeSeconds: 3.589. The process is 3.6 seconds old. The script is dividing fresh-startup allocation (~287MB RSS) by 3.6s and projecting linearly — meaningless on a young process. A real growth metric needs at least two snapshots minutes apart.

1. "Native memory > heap — leak may be in node-pty/sharp" — the runtime here is Bun, not Node (Bun: 1 in objectTypeCounts, mimalloc.mimalloc_version: 30301, nodeVersion field is ignored — Bun ships its own JSC + mimalloc). Bun reserves a 1GB virtual arena up front (mimalloc.reserved.total: 1,076,166,656) but only commits ~87MB (mimalloc.committed.current: 86,507,520). The smapsRollup confirms real RSS is 271MB, of which only 197MB is private dirty (actually used). The "native > heap" heuristic was written for Node + V8 and doesn't apply to Bun's allocator.

What the snapshot actually shows (after 3.6s of life):

• activeHandles: 0, activeRequests: 0 — nothing pinned to the event loop right now
• JS heap: 76MB / 51MB used — normal for the CLI's bundle size
• 161,618 Functions / 36,458 FunctionExecutables — that's the loaded bundle, not a leak

One thing mildly worth noting (not a leak, just an observation): protectedObjectTypeCounts shows 73 GC-rooted ReadableStreams, 79 Responses, 208 Headers. If a long-running session accumulated fetch responses without draining their bodies, that would leak — but at 3.6s of uptime it's just the in-flight startup fetches. Re-snapshot after 5–10 minutes of active use; if those numbers grow monotonically, that's the real signal.

Recommendation: no fix needed. If you want to actually validate, run the heap dump twice with several minutes of usage between, then diff protectedObjectTypeCounts and objectTypeCounts. A flat or oscillating count is healthy; monotonic growth on ReadableStream / Response / Promise / Timeout is a real lead.