[BUG] macOS 26.5.1 kernel zone leak (data.kalloc.1024) from Claude Code CLI — claude.exe panics at ~20GB, leak rate scales 21→1027/sec with agent load

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/44824

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

regression between 2.1.143 and 2.1.158, kalloc.1024 leak on macOS, clean
on 2.1.123.

Timeline — why this feels "new" despite an unchanged workflow

This machine has no kernel panic logs before May 31, 2026 — the acute phase is real, not imagined. But the underlying leak pattern matches #44824 (April 2026, macOS 15.7.x), so this is likely a long-standing Claude Code ↔ macOS kernel interaction that only became visible here once load and uptime crossed the ~20 GB kalloc.1024 ceiling.

Chronology on this hardware (Mac17,2, 32 GB):

┌───────────┬──────────────────────────────────────────┐
│ Date │ Event │
├───────────┼──────────────────────────────────────────┤
│ Apr 28, │ macOS 26.4.1 installed via Software │
│ 2026 │ Update │
├───────────┼──────────────────────────────────────────┤
│ May 31, │ First kernel panic ever on this machine │
│ 2026 13: │ — still on 26.4.1 (~33 days after the OS │
│ 00 │ update) │
├───────────┼──────────────────────────────────────────┤
│ Jun 2, │ Second panic — still 26.4.1 │
│ 2026 16: │ │
│ 39 │ │
├───────────┼──────────────────────────────────────────┤
│ Jun 2, │ macOS 26.5.1 installed (after the second │
│ 2026 17: │ panic) │
│ 10 │ │
├───────────┼──────────────────────────────────────────┤
│ Jun 4, │ Third and fourth panics — on 26.5.1 │
│ Jun 6 │ │
└───────────┴──────────────────────────────────────────┘

So 26.5.1 did not introduce this (two panics on 26.4.1 preceded it), and 26.5.1 has not fixed it (two more panics after).

Why "same workflow" can still trigger panics now:

1. Cumulative leak, hard ceiling. Zone count climbs from ~1,200 after reboot toward ~21M elements (~20 GB), then panics. At idle the measured rate is ~21 allocs/sec; under heavy parallel agent work it hits ~1,027/sec — time-to-panic drops from days/weeks to ~4 hours. Same habits, higher duty cycle or longer uptime between reboots, suddenly looks like "it started two weeks ago."

1. More concurrent claude.exe than intended. The May 31 panic snapshot lists 13+ claude.exe processes (multi-GB RSS each, tens of millions of page faults) — not just the 3–4 sessions I deliberately run. Stale terminals, worktree agents, or forgotten sessions may compound kernel allocations even when my intended workflow is unchanged.

1. Accumulated on-disk state. ~/.claude is ~25 GB on this machine (worktrees, session history, project caches). More files under agent-managed paths → more file/security events → more EndpointSecurity + APFS kernel traffic per agent turn. Spotlight Privacy on agent dirs reduced indexing pressure but did not stop active kalloc.1024 growth under load.

1. Not Grok/MCP fan-out. Early suspicion was Grok session shims or MCP multiplication (#64366). This setup has 1 MCP server (obsidian) and panic logs consistently name claude.exe as the panicked task, with EndpointSecurity + APFS in the kernel backtrace — pointing at file/sandbox monitoring, not hundreds of node MCP children.

Working hypothesis: Apple kernel leak in data.kalloc.1024 (likely EndpointSecurity/APFS path on macOS 26.x), triggered by Claude Code's sustained file I/O + agent shell churn. The bug was probably always present at low leak rates; May 31–Jun 6 is when parallel sessions + multi-day uptime + accumulated ~/.claude state pushed growth fast enough to hit the zone ceiling repeatedly. Requesting investigation of Claude's macOS file-access / sandbox / EndpointSecurity interaction on Tahoe 26.x, and a mitigation short of "never run concurrent sessions" (not viable for production deadlines).

Reproduced on macOS 26.x: kalloc.1024 kernel leak → hard panic,
regression bisected to late-May 2.1.14x builds

Adding hard data to this (saw it filed against macOS 15.7.x; I'm hitting
the same kalloc.1024 leak on macOS 26.5.1 / Apple Silicon, and it's now
causing full kernel panics, not just memory pressure).

Impact: Recurring kernel panics (data-loss-level, machine reboots)
roughly every 12–48h of normal use. Four captured in 7 days.

Panic signature (all 4 identical):
panic: zalloc[3]: zone map exhausted while allocating from zone
[data.kalloc.1024],
likely due to memory leak in zone [data.kalloc.1024] (20G,
~21,300,000 elements)
Panicked task: pid NNNN: claude.exe
Kernel Extensions in backtrace: com.apple.iokit.EndpointSecurity
~21.3M × 1024 B ≈ 20 GB = the zone-map cap, every time. The
EndpointSecurity kext is the allocator hitting the exhausted zone, not
the leaker.

Confirmed Claude Code is the producer — live zprint of data.kalloc.1024:

┌───────────────────────────────────┬────────────────────────┐
│ State │ Leak rate │
├───────────────────────────────────┼────────────────────────┤
│ Fresh boot, idle │ ~0 (~1,200 elements) │
├───────────────────────────────────┼────────────────────────┤
│ ~16 idle claude --resume sessions │ ~22/sec │
├───────────────────────────────────┼────────────────────────┤
│ Sessions actively "thinking" │ bursts 200 → 4,744/sec │
└───────────────────────────────────┴────────────────────────┘

Stops when Claude Code is killed. Not exec/file volume — 20k execs,
100-way concurrent bursts, and 20k file-opens all produced zero growth.
Only live TUI sessions leak.

Regression bisect (from local transcripts), same HW / workload / macOS
(26.4.1 throughout onset):

• 2.1.123–2.1.143 (May 1–18, incl. an 18-day continuous 2.1.123 session):

zero panics

• Converged to 2.1.144 on May 19; first panic May 31 on 2.1.154–158
• → Regression between 2.1.143 and ~2.1.154. Current 2.1.168 still leaks

despite the spinner color caps.

Plus the changelog ties it together (spinner color count, renderer style
pool, layout-engine JIT churn in 2.1.144→161), and asks: treat as high
severity (kernel panic), find/fix the rendering change, and ship an
interim flag to disable the animated spinner / reduce redraws.

Confirming this reproduces with concurrent opencode + Claude Code sessions on macOS 26.5.1 (25F80).

Setup:

• Claude Code 2.1.153 + oh-my-claudecode (autopilot mode)
• opencode 1.16.0 + oh-my-openagent (10 agents configured)
• Both running inside zellij sessions

Observed:

• 8 kernel panics in 5 days (Jun 8-12), all identical signature:
• zalloc[3]: zone map exhausted while allocating from zone [data.kalloc.1024] (20G, ~21M elements)
• Panicked process: always bash (via AMFI/EndpointSecurity path)
• Crash intervals: 9-23 hours, suggesting heavy parallel agent load accelerates the leak as noted in the report (21->1027/sec scaling).

When either tool runs alone, the leak rate is lower; running both together appears to叠加 the leak rate, reaching 20GB ceiling much faster than either individually.

Happy to provide panic logs or run any diagnostics if helpful.

Follow-up after reviewing @LeifErikH's detailed bisect data above:

The timeline clearly shows this is a Claude Code regression between 2.1.143 and 2.1.144–154, not a macOS issue. The same machine ran 2.1.123 for 18 days on the same macOS 26.4.1 without a single panic.

The 26.4.1 → 26.5.1 upgrade date (Jun 2) is a red herring — the first panic already occurred on May 31 with 2.1.154 on 26.4.1.

Action taken — personally downgrading to 2.1.143 to verify stability, and treating all _2.1.144+_ CI sessions as high-risk on any macOS 26.x.

This bifurcation data (clean before 2.1.144, leaking after) should narrow the search to the renderer change landed in that window: spinning spinner styling, layout-engine JIT, or style pool sizing. Hope the team can isolate from there.

If anyone else can reproduce: run 2.1.143 (Claude Code), and if you're on 2.1.144+, check if reverting to 2.1.143 brings your data.kalloc.1024 1024 0K 0K 0 0 594 0K 0 count back to idle.

Additional evidence: the leak is in the EndpointSecurity vnode-check path, and scales with file-open (vnode) volume — not GPU/WindowServer

I spent a long debugging session on this on an M1 MacBook Air (macOS 26.5.1 / 25F80, 16 GB). I can confirm the data.kalloc.1024 leak and the ~50 MB/h rate, but my DTrace evidence points to a different mechanism than the GPU/WindowServer pipeline hypothesized above. Sharing in case it helps narrow it down.

TL;DR

• The leaked 1 KB objects are EndpointSecurity per-message scratch buffers allocated on the mac_vnode_check_open path — i.e. one allocation per file-open (vnode open) event.
• The leak rate is directly proportional to vnode-open volume, not to GPU/TUI redraw.
• Claude Code is the trigger because it drives a very high sustained vnode-open rate (tool calls spawning shells, file reads, MCP polling), which the kernel ES subsystem processes — and the scratch buffer is not reclaimed.

Measurements (DTrace, SIP temporarily disabled for fbt probes)

1. The hot allocation stack (clean 20s aggregate, kalloc_type_impl entry):

EndpointSecurity`...PerMessageScratchSpaceTargetPathData::new_()
EndpointSecurity`EndpointSecurityEventManager::es_vnode_check_open(ucred*, vnode*, label*, int)
kernel`mac_vnode_check_open
...

The dominant 1 KB allocations come from the ES vnode-check path allocating a PerMessageScratchSpaceTargetPathData scratch buffer per event.

2. The leak scales with file-open volume (reproducible):

| State | data.kalloc.1024 growth |
|---|---|
| True idle (no activity at all) | ~0 elem/s (zone stable / shrinks) |
| Normal activity | ~14 elem/s (~55 MB/h) |
| Heavy file-open load (find /System \| head -c1) | ~321 elem/s (~22× idle) |

Generating a burst of file opens spikes the leak ~22×, then it returns to baseline. This is the single most decisive result: the leak tracks vnode-open count.

3. Ruled out (by SIGSTOP / removal + re-measure): 3rd-party audio HAL plugins, coreaudiod, Hammerspoon, Karabiner, iStat Menus, Tailscale, capture-card/UVC pipeline, and IOUserClient leakage (IOUserClient count stayed flat while kalloc.1024 grew). None of these are the source.

4. Cross-machine corroboration: the same rate occurred on a second Mac (MacBook Pro) with no AdGuard and no Rogue Amoeba software installed, but with Claude Code. The common denominator across both machines is Claude Code.

Why this is consistent with "only Claude Code triggers it"

A normal desktop generates few vnode-opens. Claude Code generates a very high sustained vnode-open rate (each tool call spawns a shell that sources a ~6k-line shell snapshot, plus file reads, greps, MCP polling). Every vnode-open goes through the kernel's EndpointSecurity AUTH path (the always-on Apple ES clients — xprotectd, watchdogd — subscribe to vnode events), and the per-event scratch buffer leaks. On an average user's machine the rate is low enough to never hit the ceiling before a routine reboot — which is likely why this isn't a widely-reported universal Apple bug.

Suggested framing for a fix

• Claude Code side: reducing sustained vnode-open volume would directly slow the leak — fewer shell spawns per tool call, reusing a long-lived shell, avoiding re-sourcing the full snapshot each call, batching file reads.
• Apple side: this looks like an ES scratch-buffer not being reclaimed on the es_vnode_check_open path under high event volume (worth a Feedback Assistant report).

Caveats / what I did NOT prove

• I did not get a clean per-tool-call vnode-open attribution (the interactive vs non-interactive shell distinction matters and I ran out of clean measurement windows).
• The exact ES client whose un-acknowledged message leaks the buffer (xprotectd vs watchdogd) is not isolated — they are SIP-protected and survive SIGKILL, so I couldn't A/B them.
• "Idle Claude Code" alone (open but not working) did not drive the leak in my tests — it's the active file-I/O volume that matters.

Environment: M1 MBA, macOS 26.5.1 (25F80), 16 GB. Happy to run targeted DTrace if a maintainer wants a specific probe.

Independent reproduction here, with a few data points the original repro couldn't cover — most importantly that it persists with the fullscreen renderer active, which rules fullscreen out as a fix.

Environment

• macOS 26.5.1 (25F80), Mac14,2 (Apple M2 MacBook Air), 24 GB RAM
• Claude Code 2.1.197 (29 releases past the 2.1.168 in the OP — still present)
• Terminal: Ghostty 1.3.1 (contains Mitchell Hashimoto's PageList fix, so this is not the Ghostty userspace leak)
• 8 concurrent CLI sessions on a mid-size repo (git/file I/O/E2E), 0 MCP servers

What's new vs the OP

1. Reproduces in fullscreen / alt-screen mode. All 8 sessions confirmed on /tui fullscreen, yet data.kalloc.1024 still climbs monotonically. So the leak is independent of the renderer mode — fullscreen throttles the rate but does not stop it. (The OP was on Terminal.app and explicitly N/A on fullscreen.)
2. Terminal-independent. OP on Terminal.app, this on Ghostty — same zone, same behavior. Not terminal-specific.
3. Still present on 2.1.197.

Measurements (zprint)

• data.kalloc.1024 = ~4.15M elems ≈ 3.96 GB, which is the bulk of kernel zone TOTAL USED (~4.78 GB) and of 6.72 GB wired. Every other zone is normal-sized (APFS inodes ~100 MB, vm.objects ~90 MB) — the leak is singular to this zone.
• Leak rate ~13 elem/sec (~800/min) with 8 sessions mostly parked in fullscreen; consistent with the OP's "~21/sec idle → ~1,027/sec heavy" load-scaling. Monotonic, never plateaus (a balanced alloc/free would plateau).
• One controlled webkit E2E pass (spawns/kills many browser procs) did not grow wired (−0.13 GB) — confirming the leak is rendering/background-driven, not subprocess-spawn-driven.
• Reboot-only reclaim confirmed: killing claude halts growth but does not return the zone; only reboot resets it (matches the kill experiment in #44824).

Triage note
#44824 — same data.kalloc.1024 signature — was auto-closed by a bot as a duplicate of #24960, but #24960 is a userspace/RSS process leak (closed not_planned), a different bug class (frees on process kill; this does not). The kernel-zone leak keeps getting swept into userspace memory-leak buckets. Seconding the request to track this distinctly and investigate Claude Code's macOS rendering/EndpointSecurity interaction on macOS 26. Happy to provide zprint dumps or a panic log.

Follow-up to my Jul 1 comment — I ran a controlled workload-discrimination series on the affected machine (MacBook Air M2/T8112, 24 GB, macOS 26.5.1, Claude Code 2.1.198). Method: zprint samples of data.kalloc.1024 in-use elements bracketed around each workload, on a quiet machine (all other Claude sessions closed; ambient baseline ~1.0 elems/s interleaved between every leg).

| Workload | Excess above ambient |
|---|---|
| 15,732 real file-opens (recursive grep -rl over /usr/share) | zero (delta −22) |
| 296,281-file find traversal (stats/readdirs) | zero (+11) |
| 2,000 process execs (/usr/bin/true loop) | ~zero (+38, ≈0.02/exec) |
| Synthetic 30 fps full-screen ANSI repaint, 15 min in detached tmux | zero (1.00/s vs 1.00/s ambient) |
| Same repaint workload, 15 min rendered in a live Terminal.app window | zero (1.01/s) |
| pytest run (44 tests, heavy import/file churn) | zero (+2) |
| 600 TLS connects (curl loop) | ~0.18 elems/connect |
| 100 MB sustained HTTPS download (verified via size_download) | ~1/s during transfer |
| Fresh minimal Claude Code session doing real SSE-streamed work (small context, no MCP servers, driven via tmux pty) — run twice, once with telemetry on and once with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 | zero (0.99/s and 1.22/s vs ~1.0–1.5/s ambient brackets) |
| Agent probe inside a loaded, long-running Claude Code session (days-old process, 200k+ token context, MCP servers attached; probe = 87 s, 15 tool calls, ~71k tokens SSE-streamed with no TTY rendering of its own) | ~3/s sustained |

Takeaways for the thread:

1. The per-vnode-open EndpointSecurity theory does not reproduce on this machine — 15k real opens leaked nothing. Whatever the DTrace stacks show on other machines, per-open leaking is not universal among affected hosts (may be config-dependent — different ES clients installed — or a second trigger).
2. The terminal/rendering path is exonerated here — an aggressive synthetic TUI leaked nothing whether detached (no rendering) or fully rendered through WindowServer. "Only live TUI sessions leak" may be conflating TUI presence with the session actively working.
3. "Claude Code doing real work" alone is not sufficient either — two fresh minimal sessions doing genuine streaming work were completely clean (which also made the telemetry on/off comparison moot: neither leg leaked). The only workload that reproduced the leak was activity in a loaded, long-running session (large context, MCP servers, days-old process). I can't attribute the ~3/s between the host session and the agent it spawned, but the loaded/long-lived configuration — and/or concurrency on top of it — appears to be required. That's consistent with the OP's superlinear scaling under parallel agent load (21/s idle → 1,027–4,744/s heavy).
4. Generic file I/O, execs, and bulk network are all clean. The profile most consistent with the known reproducers (this app's SSE token streaming; kubernetes/kubectl#1798's auth-retry loop; orbstack/orbstack#2368's small-write workloads) is high-frequency small network I/O, but I haven't isolated the syscall — and per takeaway 3, raw streaming volume alone doesn't do it on a fresh session.
5. Per-unit rates look small but accumulate hard: this machine reached 4.47 GB in 6.5 days of mixed use (average 8/s around the clock), dominated by multi-instance overnight runs; quiet days add ~84 MB/day and nothing is ever returned without a reboot.

The 2.1.143→2.1.144–154 regression bisect upthread remains the best lead; these results suggest looking at whatever high-frequency runtime behavior (streaming/telemetry/IPC cadence) changed in that window that specifically engages long-lived, heavily-loaded sessions rather than the rendering path.

Follow-up to my 2026-07-02 comment — I ran a live kill-bisect against the leak with a 10-second zone sampler and can now attribute it much more precisely.

Environment: Claude Code 2.1.200, macOS 26.5.1 (Apple Silicon, M-series, 24 GB). Zone measured: data.kalloc.1024 in-use elements via zprint, sampled every 10s.

Headline findings

1. Idle sessions leak at a constant per-session rate — activity is not required.
Overnight, 8 idle long-running sessions (~12-22h old, no user input, no agents running) leaked at 12.50/s for 11 straight hours — hourly means 12.48-12.53/s. That constancy is a fixed-cadence mechanism, not workload. Interactive activity adds bursts on top of the floor; session startup/resume spikes but never reclaims.

2. The leak attributes to the claude process itself — every spawned component was individually exonerated by live kills while watching the zone:

| Component killed/toggled | Effect on leak floor |
|---|---|
| Quit one aged session | -1 to -1.5/s each (reproducible across 5 session quits) |
| ALL 8 MCP server child processes at once | ~-1.1/s total (~0.14/s each) — minor |
| statusLine 1 Hz command spawn (config-disabled, spawn-stop verified) | no change |
| Terminal attachment (fresh session detached in tmux vs in Terminal.app) | no difference |
| Idle network: nettop shows 1 static TLS connection/session, byte counters frozen | no churn to blame |

3. It's churn, not accumulation — the process holds nothing.
Comparing a 22-hour session against a 3-minute session (both idle): open fds 25 vs 26 (lsof), mach ports 148 vs 122 (lsmp), kqueue knotes ~30 vs ~29 with 3 EVFILT_TIMER entries each (lskq) — all flat across repeated samples minutes apart. Meanwhile the zone grows ~1.5 elements/s per aged session. So the kernel is orphaning ~1KB allocations on some recurring per-tick cycle the process drives, consistent with the kubectl-retry-loop reproducer earlier in this thread. Leading suspect from what an idle session still does at fixed cadence: event-loop timer (kevent) re-arm churn.

4. Leak rate grows with session age.
Fresh idle sessions contribute little (possibly ~0.7/s each, hard to separate from noise — consistent with my 07-02 observation that fresh fleets are clean). Sessions aged ~22h contribute ~1.2-1.5/s each while completely idle. Whatever the churn cycle is, it intensifies with process lifetime, not context size (sessions were regularly /clear'd).

Practical arithmetic

~1.5/s × 1KB ≈ 5 MB/h of unreclaimable wired memory per aged idle session — about 1 GB/day for a fleet of 8. Matches my observed 745 MB overnight growth. Only reboot reclaims.

What I didn't do

The remaining step is zlog1=data.kalloc.1024 zone logging to capture allocation backtraces and name the exact kernel path. On Apple Silicon that requires a Permissive Security downgrade + two Recovery round-trips + ~a day of session aging to re-create the reproducer — a big ask for a user machine, but presumably trivial on an internal test box with kernel symbols. Happy to provide raw sampler CSVs or run cheaper diagnostics if useful.

Another independent reproduction, on a newer OS build and different Mac model than reported above:

Environment

• macOS 26.5.2 (25F84), Mac17,8, Claude Code 2.1.207 (currently installed; matches the version at time of panic)
• Kernel: Darwin 25.5.0: Tue Jun 9 22:28:34 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6050

Panic

panicString: zalloc[3]: zone map exhausted while allocating from zone [data.kalloc.1024],
likely due to memory leak in zone [data.kalloc.1024] (20G, 21173392 elements allocated) @zalloc.c:4575
timestamp: 2026-07-11 16:20:09 -0300

Element count at panic (21,173,392) lines up closely with the OP's ~21,286,288 and the earlier ~21,300,000 report — the ~20GB/~21.3M-element ceiling looks like a hard constant across machines, not something that varies by RAM size or config.

This confirms the bug is still present on:

1. A newer macOS point release (26.5.2 build 25F84) than previously reported (26.5.1/25F80)
2. A newer Claude Code version (2.1.207) than the last update in this thread (2.1.200)
3. A different Mac model (Mac17,8) than the two reporters above (Mac17,2, Mac14,2)

Consistent with the thread's conclusion that this is a kernel-side leak tied to the claude process rather than anything model/config-specific. Happy to share the full panic report if useful — reboot was the only recovery.

Another independent reproduction — plus a datapoint suggesting the trigger may be gone in 2.1.208.

Environment

• Mac15,14 (M3 Ultra, 32-core, 512 GB RAM), macOS 26.3 (25D125), kernel xnu-12377.81.4~5/RELEASE_ARM64_T6031
• Claude Code via npm global install (hence the claude.exe procname), heavy multi-session agent use (loops, subagents)

Panic (2026-07-13 22:25:56 -04) — same signature as OP:

panic(cpu 28): zalloc[3]: zone map exhausted while allocating from zone [data.kalloc.1024],
likely due to memory leak in zone [data.kalloc.1024] (20G, 21269200 elements allocated) @zalloc.c:4534
Panicked task: pid 60245: claude.exe
Kernel Extensions in backtrace: com.apple.iokit.EndpointSecurity (deps: AppleMobileFileIntegrity, quarantine)

Element count at panic (21,269,200) matches the ~21.3M ceiling reported across machines. This extends the affected-OS range down to 26.3/25D125 (previously reported on 15.7.x, 26.4.1, 26.5.1, 26.5.2).

Leak history for that uptime (6.12 days, builds pre-2.1.208):

• A bug_type 298 JetsamEvent 7.4 h before the panic already showed the zone at 18.4 GiB
• Average ≈ 40 elems/s over the whole uptime; ≈ 73 elems/s in the final 7.4 h window under heavy parallel agent load (panic stackshot: 1,058 processes, 254 node, 12 concurrent claude.exe CLI sessions)
• Consistent with the OP's load-scaling observation (21/s idle → 1,027/s heavy)

The interesting part — same machine, same OS build, after reboot on 2.1.208:

The npm package was updated to 2.1.208 at 22:23 (3 minutes before the panic — the npm install -g vnode churn under EndpointSecurity was plausibly the final allocation burst). After reboot, still on the same macOS 26.3 (25D125), with 5 concurrent CLI sessions + 45 node processes doing real agent work:

| Measurement (via zprint, ~45–65 min uptime) | data.kalloc.1024 in-use |
|---|---|
| Baseline | 6 |
| After 500 execs + ~2,600 file-opens (grep -rl) + 10 TLS connects | 6 (zero growth) |
| Bracketed ~3 min sampling with an active streaming session | 6 (zero growth) |

The per-idle-session floor (~1–1.5 elems/s each, reported above by @spectre6000) is absent — with 5 sessions we'd expect hundreds of elements over the sampling window; we saw none. Zone capacity didn't grow either (576 elems).

Since OS build, hardware, and workload are unchanged and only the Claude Code version moved to 2.1.208, this looks like the trigger was removed/fixed somewhere in 2.1.208 (nothing in the changelog obviously matches — the 2.1.207 entries are userland RSS fixes and 2.1.207 still reproduced per the report above).

A root LaunchDaemon is now sampling the zone every 30 min on this machine; I'll report back if it regresses. Would be useful if others on ≥ 2.1.208 could re-check their data.kalloc.1024 growth with the OP's zprint one-liner.

🤖 Generated with Claude Code using Fable 5

Counter-datapoint to the "trigger may be gone in 2.1.208" report above: the leak is still present on 2.1.209, on the same machine I used for the 07-02 and 07-03 comments.

Environment

• Mac14,2 (M2, 24 GB), macOS 26.5.2 (25F84), kernel xnu-12377.121.10~1/RELEASE_ARM64_T8112
• Claude Code 2.1.209, Homebrew install
• 26 minutes uptime (clean post-reboot zone), 4 concurrent CLI sessions, all fresh

Measurement — data.kalloc.1024 in-use elements, 60s sampler, two independent samplers agreeing:

| Time | in-use | Δ | rate |
|---|---|---|---|
| 07:47:51 | 3,604 | — | — |
| 07:48:51 | 3,811 | +207 | 3.45/s |
| 07:49:52 | 4,462 | +651 | 10.67/s |
| 07:50:52 | 5,092 | +630 | 10.50/s |
| 07:51:52 | 5,535 | +443 | 7.38/s |
| 07:52:53 | 6,069 | +534 | 8.75/s |
| 07:53:53 | 6,817 | +748 | 12.47/s |
| 07:54:54 | 7,339 | +522 | 8.56/s |

~8.9 elems/s sustained mean, monotonic, never reclaiming. For reference, this machine's historical quiet baseline was ~1.0/s, and my overnight 8-aged-session idle floor was 12.50/s — so ~8.9/s with only 4 fresh sessions at 26 minutes uptime is squarely in leaking territory, not near-zero.

This contradicts the 2.1.208 observation under closely comparable conditions (that test was 5 sessions at 45–65 min uptime, reporting a flat 6 elements). The rate here also isn't an artifact of my own tooling: the growth continues at ~8.6/s across a window where the sessions were idle between turns, and my 07-03 controls already exonerated execs, file I/O, and the sampler itself.

The variable that differs is the macOS build. The clean 2.1.208 machine is on 26.3 (25D125); this one is on 26.5.2 (25F84) — the same build @visualpharm reproduced the panic on with 2.1.207. Given the thread's evidence that this is a kernel-side zone bug the CLI merely triggers, "fixed in 2.1.208" may be build-dependent rather than a real removal of the trigger, or the 26.3 machine may simply not engage the vulnerable kernel path.

Suggested control for anyone else re-checking: report your macOS build number alongside the CLI version, since the two reports currently disagree and differ on exactly that axis.

Caveat on my own numbers: these are fresh sessions at short uptime. My 07-03 finding was that per-session rate grows with process age (~0.7/s fresh → ~1.2–1.5/s at ~22h), so this should if anything be the optimistic end. I have a continuous sampler running and will post an aged-fleet figure after a full day.

Happy to share the raw CSVs.

I had the same issue, and I was able to find the root cause and resolve it.

TL;DR;

🎉

The root cause is the npm installation. Steps to fix it:

npm uninstall -g @anthropic-ai/claude-code
curl -fsSL https://claude.ai/install.sh | bash     
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc

🎉

The long story:

I've spent the last 2 weeks investigating this with Claude across several macOS machines, and the outcome is a complete causal chain with a deterministic reproduction and a natural control group: the kernel bug is Apple's, the trigger is npm-based Claude Code updates rewriting the package under running sessions — and the native installer already ships the fix.

The kernel bug (Apple's)

While handling an event for an EndpointSecurity client, XNU calls vn_getpath; when it fails with 0x2 (a vnode with no resolvable path), the 1KB path buffer (zone data.kalloc.1024, tag vfs.namei) is never freed. Each failure logs:

kernel (EndpointSecurity) vn_getpath failed: 0x2

1:1 proof (live, same clock): 2,039 logged failures over 8 quiet minutes ↔ zone +2,055 KB (99.2%); 116,991 failures over 5 loaded minutes ↔ zone +124,171 KB (94%, ~390/s; the kernel rate-limits its own log lines, so counts are lower bounds). Failure counts track zone growth across entire days. Only reboot reclaims the zone; at ~20GB (~21M elements) the machine panics — the panicked task (claude.exe, bash) is just the last allocator, not the leaker.

The trigger (reproduced on demand, plus a smoking-gun observation)

On a machine idling at a 3 failures/sec floor for 40+ minutes, running npm install -g @anthropic-ai/claude-code — what the auto-updater does on npm installs — under 4 running CC sessions stepped the rate to a sustained ~180/sec measured with every session idle (~60×). Replication: further downgrade/upgrade cycles kept stale sessions at ~240–350/s idle; the rate collapses only when the sessions are restarted (observed twice).

Why: npm updates delete and re-extract the package — the old 240MB binary loses both its hardlinks and its parent directories while running sessions keep executing it. The old inode survives only as a nameless "deleted but open" file. Smoking gun, visible with plain lsof on any post-update session: the process's txt segment is the old, deleted inode, and the kernel renders its path as just /claude — a degenerate fallback, because there is no directory entry left to walk. vn_getpath reconstructs paths by walking parent directory entries; for this vnode there is nothing to walk → 0x2. EndpointSecurity includes the originating process's executable path in every event it delivers to ES clients, so every file op a stale session tree performs = one failed resolution = 1KB leaked. Auto-updates land every day or two; sessions stay open for days; stale trees accumulate → the leak "compounds" over a workweek → 20GB ≈ 3 workdays for heavy users. This also explains the suspected "regression at 2.1.144" (the era of the large native binary rewritten in place) without any CC code being at fault.

The natural control group: the installer split

Users on the native installer (curl -fsSL https://claude.ai/install.sh | bash) cannot reproduce — it stores versioned binaries and swaps a launcher symlink, so the version a running session executes keeps its directory entries and stays resolvable. Only npm-installed machines leak. Same macOS (26.5.x), same security stack, same usage — update strategy is the discriminating variable. Live meters on the npm machines: 144,538 and 327,550 vn_getpath failures per 10 minutes on the two hottest (the latter at 9.2GB of the 20GB ceiling with 7 sessions open; one capture caught the auto-updater streaming 14,800 write events into the claude binary in 10 seconds).

Check your machine (no root)

/usr/bin/log show --last 10m | grep -c "vn_getpath failed"
≈ leaked KB per 10 min. Zone level: sudo zprint data.kalloc.1024 | awk '$1=="data.kalloc.1024"{printf "%d MB of ~20480 panic ceiling\n", $3/1024}'. If lsof -p <claude pid> | grep txt | head -1 shows a bare /claude path — that session is leaking right now.

Workarounds

1. Best: migrate off npm to the native installer (claude install / claude migrate-installer) — versioned updates never orphan running sessions; the trigger disappears.
2. On npm: restart all CC sessions after every update, or DISABLE_AUTOUPDATER=1 and update at session boundaries.
3. Reboot before the ~20GB ceiling (a LaunchDaemon sampling zprint with a 12GB alert; runway under heavy burn can be <6h).

Asks

Anthropic: (1) npm-installed CC should prompt/auto-restart sessions after self-update — or npm installs should adopt the versioned layout the native installer already has; (2) route the kernel bug to Apple — the diagnosis is as complete as userspace allows (log fingerprint, 1:1 allocation arithmetic, deterministic trigger, installer-split control group, multiple reproducing machines), and their fix is an error-path free in the ES kext.

Confirming @DimitarTachev's root cause end-to-end on the machine from my 07-01/02/03/14 comments — plus two corrections to my own earlier claims, and two datapoints nobody in-thread has yet (a deliberate version-swap stress test of the native installer, and a live auto-update firing over running sessions).

Corrections to my 07-14 comment

1. "Homebrew install" was wrong. On inspection it was an npm global install behind a Homebrew symlink farm — so this machine was in the affected (npm) population all along. If you think you're on Homebrew, check what the symlink actually resolves to before treating yourself as a counter-example.
2. The macOS-build hypothesis is dead. I suggested the 2.1.208-clean vs 2.1.209-leaking disagreement tracked macOS builds (26.3 vs 26.5.2). The npm-orphaning mechanism explains it better: the "clean 2.1.208 on 26.3" fleet was freshly rebooted/restarted — no npm update had orphaned anything yet. Build number is irrelevant; orphaning history is the variable. My 07-03 "per-session rate grows with process age" finding is likewise superseded: age correlated with having survived more npm updates, not with age itself.

Confirmation on this machine

Smoking gun, pre-migration: every running session's executable mapping was a nameless deleted inode. Diagnostic anyone can run, no root:

lsof -p <claude pid> | grep txt | head -1

Bare /claude (no versioned path) = that session is orphaned and leaking on every file op. All 4 of my pre-migration sessions showed it, with the on-disk binary's inode ≠ the mapped inode.

Leak meter, no root needed: log show --last 10m | grep -c "vn_getpath failed" ≈ leaked KB per 10 min (each failure = one 1KB data.kalloc.1024 element stranded). With 3–4 orphaned sessions idle this machine sat at ~5.7–6.1 failures/s. A fresh native-install session added ~0 on top.

Post-migration acceptance run (today, after npm uninstall -g + native install + reboot): 10 hours of real workload — 4 concurrent CLI sessions, sustained load average ~15–29 (heavy test/mutation runs) — sampled every 10 minutes:

• vn_getpath failed count: 0 on every single sample, all day.
• data.kalloc.1024 in-use: flat at ~1.1–1.25k elements (ambient floor; the panic ceiling is ~21.3M). Under the old install this workload leaked tens of MB/hour, monotonic.

Two datapoints beyond "migrate and it stops"

1. Deliberate version-swap stress test. With a native-install session running, I forced claude install 2.1.210 → 2.1.204 → 2.1.211 back-to-back. Old version files were never deleted, the running session's txt path stayed resolvable (~/.local/share/claude/versions/<ver>) throughout, and the leak meter stayed flat. The exact operation that orphans npm sessions — replacing the installed binary under a live session — is a non-event on the native layout, because versioned files keep their names and only the launcher symlink moves.

2. A real stable-channel auto-update fired over live sessions. The updater upgraded the launcher 2.1.204 → 2.1.205 while three sessions were actively running 2.1.204. Result: no orphaning (all txt paths still versioned and resolvable), no pruning of old versions (2.1.204/2.1.205/2.1.211 coexist in versions/), meter 0 across the event window. So the native auto-updater doesn't reintroduce the trigger either — that was the last way this could have come back.

Practical notes for anyone migrating

• claude install (or the curl installer) performs a full migration — it removes the npm tree and any brew symlink, not side-by-side. Don't be surprised mid-flight.
• Sessions that were orphaned before you migrate keep leaking until you reboot (only reboot reclaims the zone). Migrate, then reboot, then measure.
• The kernel side (vn_getpath leaking its buffer on 0x2 into data.kalloc.1024, surfaced via the EndpointSecurity event path) is Apple's bug and still unfixed — npm-style delete-and-replace of any monitored running executable should reproduce it. The npm→native migration removes Claude Code as a trigger; it doesn't patch the kernel.

Raw CSVs (60s zone sampler since 07-02, plus today's 10-min acceptance log) available as before.

@DimitarTachev's theory also explains why OpenCode was triggering the same issue for me and others.

I created a script to reproduce the issue. So if you want to see it happen, use bun or npm to install opencode-ai, and then run this script. You'll see kalloc.1024 usage creep up.

If you then uninstall opencode using bun or npm and install it with OpenCode's curl installer, and run the stress test again, you won't see the kalloc.1024 usage creep up.

https://gist.github.com/markjaquith/b6915a8f1b35939af04c166cd01b3b41

usage:

opencode-upgrade-under-load -n 16 ~/some-big-directory-of-code

-n is the number of opencode servers to run. Default 8.

You have to point it at a directory, but it will use your current directory if you don't. You can also pass in the specific OpenCode versions you want it to switch between (defaults to 1.18.2 and 1.18.3).

It'll keep the servers hot, feeding them prompts to fix "every bug in this codebase" (LOL) when they go idle. (so, uh, don't let this run all day and maybe set OpenCode to use a cheap model).

Thank you @DimitarTachev! Really great work to identify what's going on here.

Corroborating on macOS 26.4.1 (Darwin 25.4.0), Apple Silicon Mac mini 16 GB running as an always-on Claude Code server: data.kalloc.1024 grew linearly at ~23 elems/s (~2 GB/day) to 9.4 GB wired over 5 days, to the point of jetsam killing system daemons. We spent a day attributing it per-process with SIGSTOP A/B/A experiments (stop a suspect group, watch the zone growth rate, resume, watch it return) plus kill tests. A few findings that complement the load-scaling numbers above:

1. It reproduces fully headless — no WindowServer/GPU in the path. Our triggering clients run inside tmux over SSH; nothing renders on the leaking machine's display. The Terminal → WindowServer → AGX pipeline hypothesized in #44824 cannot be the (only) path. Your panic backtrace listing EndpointSecurity and apfs kexts fits that: the common factor here looks like the syscall churn itself (our samples are dominated by kevent64, __ulock_wait2, __psynch_cvwait, pty writes, and FS stat/open churn).

**2. Per-client leak rate grows with client age, complementing your scaling with load.** A freshly started claude agents status TUI leaks ~0–2 elems/s; the same binary 22 h old leaks ~20 elems/s by itself. Long-lived status/monitor clients end up dominating an otherwise idle machine. Both observations are consistent with leak ∝ cumulative syscall volume.

3. Not only the interactive TUI. The VS Code extension's resident headless client (--output-format stream-json, no TUI rendering) contributed ~5 elems/s at 18 h of age. The daemon/supervisor (claude daemon run) and its bg-pty-host/bg-spare workers measured clean in isolation. So throttling Ink redraws alone may not fully mitigate.

4. Kernel memory is never reclaimed, even on process exit. Killing our 22 h-old client collapsed system-wide growth from ~23/s to ~1.4/s but freed essentially none of the ~1.6 GB it had accumulated (zone in-use count unchanged). Only reboot returns the memory — the allocations are not owned by the exiting task, i.e. the bug is kernel-side; Claude Code is "only" the strongest trigger.

5. No userspace object ballooning. lskq shows ~24–26 knotes on both fresh and 18 h-old clients; no kqueue/port accumulation visible from userspace. Release kernel (SIP on, no zleak/zlog), so kernel allocation backtraces weren't obtainable; attribution stops at process granularity.

Mitigation that works for us: keep long-lived clients young — e.g. run the fleet TUI as while true; do timeout 6h claude agents; done, and restart resident clients periodically. Fresh clients leak ~nothing, so capping age caps the rate. Hourly watchdog one-liner: zprint -L | awk '$1=="data.kalloc.1024"{print $7}' (elems; ×1024 = bytes).

We are filing an Apple Feedback report with a sysdiagnose captured while the 9.2 GB was still accumulated; hourly monitor CSV (timestamp, in-use elems, rate) available on request.

Confirming this on macOS 26.5.2 (25F84, xnu-12377.121.10~1) — the current release does not fix it — with a full production-timeline dataset ending in the same panic.

System: MacBook Pro (Mac17,8, Apple Silicon, 64 GB). Heavy automation workload: ~15-25 concurrent Claude Code sessions (mostly headless runners, a few interactive TUI in tmux) plus heavy short-lived subprocess churn. No third-party kexts (all-Apple kernelcache); the only third-party system extension is a network extension (not Endpoint Security).

Panic (after 6.95 days uptime):

panic(cpu 13 caller 0xfffffe004786034c): zalloc[3]: zone map exhausted while
allocating from zone [data.kalloc.1024], likely due to memory leak in zone
[data.kalloc.1024] (20G, 21183792 elements allocated) @zalloc.c:4575

Same signature as OP in every particular: data.kalloc.1024 at 20G / 21,183,792 elements / 0B free (next-largest zone on the whole system was APFS_4K_OBJS at 431M); panicked task was the Claude Code CLI process; faulting backtrace frames inside com.apple.iokit.EndpointSecurity — which I also read as allocation-of-record rather than attribution, since at this machine's process-event rate ES is statistically likely to be the allocator that hits the exhausted map regardless of which subsystem leaks.

Leak rate vs workload — three operating points (reconstructed from a JetsamEvent snapshot 38 h pre-panic showing the zone at 8.64 GiB, plus live unprivileged zprint sampling post-reboot):

| Operating point | Rate | ~elements/sec |
|---|---|---|
| Baseline automation (first ~128.6 h) | ~68.8 MB/h | ~20/sec |
| Heavy burst: max concurrent sessions + subprocess fan-out (final ~38.3 h) | ~303.8 MB/h (4.4x) | ~86/sec |
| Light load, fresh boot (live sampling) | ~17 MB/h | ~4.6/sec |

This slots directly into OP's 21 -> 103 -> 1,027/sec scaling curve. Zone never shrinks; reboot fully resets it.

One note for the mechanism hunt: #44824 measured 30-48 MB/min per interactive TUI session; this machine peaked at ~5 MB/min total across ~20 mostly-headless sessions. Headless runs emit far less pty output than an interactive TUI, so this is consistent with pty output volume — not session count — being the driving variable.

I now run a 5-minute telemetry loop logging zone size + workload census (claude/node process counts) to jsonl, so future runs produce continuous dose-response curves. Happy to share the dataset, sanitized panic excerpts, or run controlled A/B slope experiments (kill-all-sessions) if useful.

Follow-up to my comment above: we just migrated npm -> native on the panicked machine and captured the orphaning transition live, with before/after meters — the cleanest single-machine demonstration of @DimitarTachev's causal chain I can offer, since the only variable that changed was the binary's inode state.

Timeline (same machine, same workload, same macOS 26.5.2, minutes apart):

| Time | State | vn_getpath failed meter | txt mapping of running sessions |
|---|---|---|---|
| 23:41 | npm 2.1.217, fresh boot, sessions started post-boot (no update had fired yet) | 0 /10 min | named, resolvable |
| 23:46 | ran the native installer (removes the npm tree — same delete-under-running-sessions operation as an npm update) | — | every long-lived session flipped to bare /claude |
| 23:47 | first 5-min sample after | 364 /5 min | orphaned |
| 23:50 | orphaned sessions doing real work | 1,515 /5 min | orphaned |
| 23:52 | rebooted | -> 0 (0 orphans) | fresh sessions: versioned native paths |

Zone reclaimed 13,098 -> 1,020 elements at reboot.

Two takeaways beyond confirmation:

1. npm-installed-but-never-updated-under-load is clean: our npm fleet read 0 failures pre-migration because tonight's earlier reboot had restarted every session and no auto-update had fired since. It really is orphaning history — not the npm layout per se — that leaks, which is why "works on my npm machine" reports and panic reports can both be true.
2. Practical migration note: the native installer's npm-tree removal orphans your currently running sessions the moment it runs (expected — it's the same kernel path). Migrate, then reboot at your next boundary; new sessions are clean immediately, and post-reboot everything is.

This also retro-explains the dose-response data in my earlier comment: our leak rate tracked workload because npm auto-updates had been landing every day or two under long-lived sessions, so "heavy burst" = high file-op volume through orphaned processes. The pty-output framing there is superseded by this mechanism.

We now run a 5-min watchdog logging zone size + the vn_getpath failure count, so if any regression re-introduces orphaning we'll have the exact timestamp. Raw jsonl available on request.

Corroborating on macOS 26.5.2 (25F84), Apple M2 Max, 32 GB.

Same signature: data.kalloc.1024 reached 18.5M live elements (~17.6 GB) over ~4.8 days uptime (from ~1,200 at boot), i.e. ~3.6 GB/day, under sustained Claude Code use plus containerized claude/codex agents running continuously. A reboot returns it to baseline (~1,200 elements / low MB).

Two data points that may help isolate the mechanism:

• NFS.namei is clean (0 live elements) throughout — so it's the generic vfs.namei pathname buffer accumulating, not the NFS client zone.
• Control test: three find /System/Library /usr /Applications -type f passes (millions of native pathname lookups, ~90s wall) grew the zone by only ~12 MB total — and ~4 MB of that is the ~2.5 MB/min background drip that continues regardless of the finds. So generic native path resolution does not leak meaningfully; the growth tracks agent tool-call load, consistent with the idle→heavy rate scaling in the report.

Caveat for honesty: I have not isolated Claude Code from other concurrent load on this machine (it also runs OrbStack and other long-lived node processes), so I'm offering this as a matching environment + the native-lookup control experiment, not a causal proof. Notably, the one OrbStack-repo issue for this same zone (orbstack/orbstack#2368) was retracted by its reporter as "not related to OrbStack," which is part of what pointed here.

<!-- obsidian --><p>Second data point, on a <strong>different macOS major version</strong> — this reproduces on Sequoia 15.7.3, not just 26.x, which suggests long-standing behaviour rather than a 26-specific regression.</p>
<h3 data-heading="Environment">Environment</h3>

  |  
-- | --
Hardware | MacBook Pro Mac16,5, M4 Max, 36 GB
OS at panic | macOS 15.7.3 (24G419)
Kernel | Darwin 24.6.0, xnu-11417.140.69.705.2~1/RELEASE_ARM64_T6041
Claude Code | 2.1.x, ~6 concurrent CLI sessions on large monorepos
MCP servers | 2

<p>19.0/sec × 12.32 d lands exactly on the 20,257,312 in the panic string, so the linear model holds well over multi-day windows. These are averages across sleep and idle, so bursts are considerably higher — consistent with your 21 → 1027/sec range.</p>
<p>Post-reboot baseline here is ~1,800–2,100 elements, matching your ~1,200.</p>
<h3 data-heading="Monitoring note">Monitoring note</h3>
<p><code>zprint</code> reports the in-use count in field 7 <strong>without sudo</strong>, which makes unattended sampling easier:</p>
<pre><code class="language-sh">zprint 2>/dev/null | awk '$1=="data.kalloc.1024"{print $7}'
</code></pre>
<p>I sample that every 60s alongside the mbuf zones (<code>mbuf</code>, <code>data.mbuf.cluster.{2,4,16}k</code>) and <code>netstat -m</code>. Over a 47-minute window <code>data.kalloc.1024</code> climbed monotonically while every network buffer pool oscillated flat around baseline — useful for ruling out the "it's a NIC/driver leak" theory that this symptom tends to attract.</p>
<h3 data-heading="Open question">Open question</h3>
<p>I have not been able to attribute the allocations to a call site without <code>zlog=data.kalloc.1024</code> as a boot-arg, which needs reduced security on Apple Silicon and isn't an option on an MDM-managed machine. Controlled load tests on my side so far show only a weak effect from process-exec volume and essentially none from raw path-lookup volume (119K <code>namei</code> lookups produced ~51 elements), so whatever drives the rate isn't simply file operations. If anyone has attributed it properly, I'd like to know what the allocating path turned out to be.</p>
<p>I've since updated to 15.7.5 (24G624) and will report back if it recurs on that build.</p>

Still reproducing on a clean native install: 2.1.223, macOS 26.3.1, M4 Mac mini 16 GB, zero npm.

Flagging this because the thread has converged on npm orphaning the binary, and that does not explain this machine.

• npm ls -g @anthropic-ai/claude-code is empty. Installed via install.sh, always has been.
• The only orphaned process on the box (a --chrome-native-host still running a deleted 2.1.220

binary) was tested on its own with SIGSTOP: 405 → 411 → 409 allocs/min. No effect.

What the leak does track is the number of running sessions, idle or not:

| running sessions | allocs/min |
|---|---|
| 14 | 697 |
| 9 | 610 |
| 8 | 409 |
| all 13 SIGSTOPped | −141 (zone shrinks) |
| resumed | 785 |

Roughly 50 to 68 allocations/min per session, about 75 MB/day each. Reached 10.4 GB wired over 14 days uptime before I rebooted. Reboot returned the zone to ~800.

One thing that may cost people time: the zone name differs. On this machine it is data_shared.kalloc.1024. The data.kalloc.1024 from the title sits at 203 and looks perfectly clean. Anyone checking only the zone in the title may conclude they cannot reproduce.

zprint | awk '/data_shared.kalloc.1024 /{print $7}'

That gives the in-use count and needs no sudo, which is easy to miss since zprint without root shows 0K for every size column.

This lines up with @spectre6000's 2026-07-03 comment that idle sessions leak at a constant per-session rate. That observation predates the npm theory and was never actually refuted.