[Bug] macOS kernel panic: data.kalloc.1024 zone exhausted from leaked file descriptors/kqueues in long-running sessions

Bug Description
Bug report: macOS kernel panic (data.kalloc.1024 zone exhausted) with claude.exe as panicking task after a long session Environment Claude Code version: 2.1.197 (Claude Code) OS: macOS (build 25F80) — Darwin Kernel 25.5.0, arm64 (Apple T6041), 36 GB RAM Session profile: a single multi-hour ("marathon") session driving a DB seed + rekey workflow. Heavy, sustained use of: background Bash tasks (run_in_background), several subagents (Task tool), and multiple long-lived file-polling loops (background samplers reading log files every 90–120 s for hours). The workflow spawned many child node/pnpm processes over its lifetime. Symptom Over the session, backgrounded tasks were repeatedly killed en masse at seemingly random times (consistent with the OS shedding processes / jetsam under mounting memory pressure). System-wide compressor memory climbed steadily across the session. The machine eventually kernel-panicked and restarted on its own. Panic report (key excerpts) panic(cpu 1 caller ...): zalloc[3]: zone map exhausted while allocating from zone [data.kalloc.1024], likely due to memory leak in zone [data.kalloc.1024] (20G, 21171952 elements allocated) @zalloc.c:4575 Largest zones: data.kalloc.1024 20G free 0B compressor_segment 126M vnodes 66M kqueue workloop zone 25M Panicked task 0xfffffe20933d5cd0: 13536 pages, 36 threads: pid 35912: claude.exe Kernel Extensions in backtrace: com.apple.iokit.EndpointSecurity(1.0) com.apple.filesystems.apfs(2811.120.14) (Full panic log available on request.) Analysis / hypothesis The kernel data.kalloc.1024 zone was exhausted: 20 GB across ~21.1 M 1 KB allocations — i.e., a kernel-memory leak. The panicking task was claude.exe (36 threads); EndpointSecurity + apfs kexts appear in the panicked thread's backtrace, and vnodes / kqueue workloop are among the largest zones. Together this points to leaked kernel handles (file descriptors / kqueues / vnodes) accumulated over the session's very high volume of process spawns + file operations. Caveat: the panicking thread being claude.exe does not prove claude.exe owns all the leaked memory — it was simply the allocator that hit the already-exhausted zone. The leak could be in Claude Code's own kernel-handle usage, or in an EndpointSecurity client (e.g., a corporate EDR/security agent) reacting to Claude Code's activity. Impact Hard machine panic + restart; all in-flight background work lost. Questions Is there a known fd / kqueue / vnode leak in Claude Code's background-task, subagent, or file-watching machinery on macOS? Does Claude Code retain kernel handles per run_in_background task, per subagent, or per file read over a long session? Repro / what would help pinpoint Repro shape: a multi-hour session that spawns many run_in_background Bash tasks + several subagents + long-lived polling loops that read files on a timer. To capture next time: sudo zprint sampled over time (watch data.kalloc.1024 grow) and a spindump of claude.exe, plus lsof -p <claude pid> fd-count trend.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.197
• Feedback ID: 33268d6f-6936-438a-89f6-2a3560cc1799

Errors

[]