Kernel panic data.kalloc.1024 on a Mac running many Claude Code sessions

Between 17 and 22 Oct 2026, my Mac rebooted itself five times, and every panic log said the kernel zone data.kalloc.1024 had run out. The cause is a kernel memory leak that Claude Code triggers, and the way Claude Code is installed decides how fast it leaks.

The machine and the setup: about 20 Claude Code sessions in parallel

Mac Studio M1 Max, 32 GB RAM. It ran macOS 26.5.2 when the panics happened; it runs 26.7.1 now.

Each project has its own Claude Code session in tmux, opened automatically when the machine boots. I drive them remotely through Remote Control (the Claude app on my phone and on other machines), so the Mac runs all the time with nobody sitting at it. The sessions use MCP servers, including Playwright and Chrome DevTools, which run headless Chrome, and they run e2e tests with Playwright.

The symptom: zone map exhausted in data.kalloc.1024

The machine reboots on its own. The panic log says:

zone map exhausted while allocating from zone [data.kalloc.1024]

The process named at the moment of the crash was claude.exe every time.

Watching the zone with zprint

zprint data.kalloc.1024

Column 7 is the number of elements in use, 1 KiB each. The zone grows while Claude Code runs and the machine panics when it reaches about 20 GB. Quitting Claude only stops the growth. Only a reboot gives the memory back.

The cause: issue #66020 has no fix, and the npm install leaks faster

The bug is reported at anthropics/claude-code#66020, and as of 31 Oct 2026 the issue is still open. The common suspicion is that the bug lives in the macOS kernel and Claude Code is what triggers it.

On my machine, more Claude Code processes meant a faster leak, and that includes short claude commands run from scripts.

The npm install updates itself, which means it replaces the executable underneath sessions that are still open. One panic came 4 minutes after such an update. While sessions kept running on the npm files that had been removed, the zone leaked 80 to 150 thousand elements per minute, which came to 3.3 GB in 40 minutes.

The fix: native installer, weekly updates, a watchdog script

1. Move Claude Code from npm to the native installer. There is a trap: claude install run from the npm build also removes the npm package, even while sessions are running from it, and an old session that is still running will reinstall the npm package. So restart every session right after the switch, then check with npm ls -g @anthropic-ai/claude-code and remove the package once no process uses it.
2. Turn off auto-update in the background sessions with DISABLE_AUTOUPDATER=1. Updates go into one weekly job: claude update, then restart every session if any of them still runs the old version. The job first ran every night, but Claude Code ships a release almost every day, so every morning the sessions had lost their scheduled tasks, and I moved it to weekly.
3. A watchdog script on a schedule: it reads zprint, computes the growth rate, and warns at 12 GB and 16 GB so I can reboot on my own terms before a panic.

After the move to native, the zone stayed flat: a rate of 0 for 8 hours with 17 sessions running. Since 22 Oct there has been no panic of this kind.

Limits of this fix

• Neither Claude Code nor macOS has shipped a fix. The native installer and the watchdog script are a way to live with the bug.
• A leak inside the kernel is not freed by quitting the app, only by a reboot. An early warning so you can reboot yourself beats waiting for the panic.
• A different panic string means a different problem. On 31 Oct the machine panicked again with 100% of compressed pages limit while the kalloc watchdog still reported 0.0 GB. That case and its fix are in the post A Mac with 65% RAM free nearly panicked.