Repository navigation
[Bug] Kernel panic (zone map exhaustion / memory leak) via EndpointSecurity — opencode.exe #32002
Description
Summary
A kernel panic occurred on 2026-06-12 caused by opencode exhausting the macOS kernel zone map through an apparent memory leak in the data.kalloc.1024 zone, triggered via the EndpointSecurity kext.
Environment
| Field | Value |
|---|---|
| OS | macOS 26.3 (25D125) |
| Kernel | Darwin 25.3.0 — xnu-12377.81.4~5/RELEASE_ARM64_T6000 |
| Chip | Apple M1 Pro (T6000) |
| Date/Time | 2026-06-12 14:37:57 +0800 |
| Panicked process | opencode.exe (PID 33091) |
Panic String
panic(cpu 2 caller 0xfffffe0029931d58): zalloc[3]: zone map exhausted while
allocating from zone [data.kalloc.1024], likely due to memory leak in zone
[data.kalloc.1024] (20G, 21182160 elements allocated) @zalloc.c:4534
Largest Zones at Time of Crash
| Zone | Size | Free |
|---|---|---|
data.kalloc.1024 |
20 GB | 0 B |
APFS_INODES |
106 MB | 211 KB |
compressor_segment |
60 MB | 14 MB |
The data.kalloc.1024 zone consumed the entire zone map (20 GB, 21,182,160 elements) with zero bytes remaining.
Backtrace (Panicked Thread tid 22229811)
Panicked task 0xfffffe2e9f38eb70: 31766 pages, 29 threads: pid 33091: opencode.exe
Panicked thread: 0xfffffe1d3b075fc0, backtrace: 0xfffffecc1c4dad30, tid: 22229811
lr: 0xfffffe00298adcf0 fp: 0xfffffecc1c4dadc0
lr: 0xfffffe0029a1e60c fp: 0xfffffecc1c4dae30
lr: 0xfffffe0029a1c804 fp: 0xfffffecc1c4daef0
lr: 0xfffffe0029853b88 fp: 0xfffffecc1c4daf00
lr: 0xfffffe00298adfbc fp: 0xfffffecc1c4db3e0
lr: 0xfffffe002a1b5854 fp: 0xfffffecc1c4db400
lr: 0xfffffe0029931d58 fp: 0xfffffecc1c4db600 ← zalloc panic site
lr: 0xfffffe00299357f8 fp: 0xfffffecc1c4db680
lr: 0xfffffe0029aa8fcc fp: 0xfffffecc1c4db960
lr: 0xfffffe0029acdcdc fp: 0xfffffecc1c4db9b0
lr: 0xfffffe002b9e3138 fp: 0xfffffecc1c4dba30 ← EndpointSecurity entry
lr: 0xfffffe002ba12808 fp: 0xfffffecc1c4dbb60
lr: 0xfffffe002ba12b18 fp: 0xfffffecc1c4dbb80
lr: 0xfffffe002a194b68 fp: 0xfffffecc1c4dbbe0
lr: 0xfffffe0029afb3c0 fp: 0xfffffecc1c4dbc30
lr: 0xfffffe0029ae6a3c fp: 0xfffffecc1c4dbde0
lr: 0xfffffe0029faf504 fp: 0xfffffecc1c4dbe50
lr: 0xfffffe0029a1c88c fp: 0xfffffecc1c4dbf10
lr: 0xfffffe0029853b88 fp: 0xfffffecc1c4dbf20
lr: 0x000000018d41483c fp: 0x0000000000000000
Kernel Extensions in backtrace:
com.apple.iokit.EndpointSecurity(1.0)[63D37344-1EF0-3E77-95AC-44E720AEBA86]
@ 0xfffffe002b9d6a80 -> 0xfffffe002ba65823
Analysis
The panic trace goes through com.apple.iokit.EndpointSecurity, the macOS security event framework used for monitoring filesystem and process events. opencode appears to be subscribing to EndpointSecurity events in a way that causes the kernel to allocate kalloc.1024 objects without ever releasing them — 21 million allocations over the session, consuming 20 GB of kernel zone map space, ultimately causing the machine to hard-panic and reboot.
Hypothesis: opencode's file-watching / process-monitoring code registers EndpointSecurity event handlers but leaks the associated kernel objects (possibly es_message_t buffers or related notification structures) over time. Under sustained use, this compounds until zone exhaustion.
Steps to Reproduce
- Run opencode for an extended session (exact duration unknown — crash occurred mid-session)
- Kernel panic occurs without warning; machine reboots
Impact
- Severity: Critical — causes a hard kernel panic and forced reboot, losing all unsaved work
- Machine must be restarted; no graceful shutdown
Diagnostic Files
- Full panic log:
/Library/Logs/DiagnosticReports/panic-full-2026-06-12-143757.0002.panic(2.4 MB) - Reset counter diag:
/Library/Logs/DiagnosticReports/ResetCounter-2026-06-12-143801.diag - Boot faults recorded:
wdog, reset_in1 - Incident ID:
FB6F2EC5-E99D-45FC-984B-EE99D8B27889
Suggested Fix
Audit all EndpointSecurity client usage for missing es_release_message() / es_delete_client() calls. Ensure that every es_message_t received via the event handler block is released after processing, and that the ES client is properly torn down on shutdown.
Activity
huashiyiqike commentedon Jun 12, 2026
Confirming the same pattern here with opencode 1.16.0 + oh-my-openagent on macOS 26.5.1 (25F80).
Running alongside Claude Code (which has a similar open issue at anthopics/claude-code#66020 -- also EndpointSecurity-triggered kalloc.1024 leak). The two tools together appear to叠加 the leak rate, causing panics every 9-23 hours instead of days.
Observed panic signature:
data.kalloc.1024exhausts to exactly 20GB (~21M elements) every timebash(via AMFI backtrace)May be worth checking if the file-watching / EndpointSecurity subscription pattern in oh-my-openagent differs from standard opencode usage, since the leak rate seems to scale sharply with active agent count.
Available to provide panic logs or test any workaround builds.
SamuelSmeys commentedon Jun 21, 2026
Experiencing the same issue under the same circumstances (Multi day sessions) - was going to open an issue but found this one (pasting below)
Please let me know if you need anything else
Hello,
Recently I've had multiple full PC restarts occur while using Opencode for an extended amount of time.
Panicked task 0xfbfffe2735a40e28: 162143 pages, 40 threads: pid 95484: opencode.exeOpencode v1.17.9
Device: MacBook Pro (16in)
CPU: M5 Max
RAM: 128GB (unified)
GPU: 40 Core version
OS: 26.5.1 (25F80) - Tahoe
Arch: ARM (Apple Silicon)
Additional Info:
Backtrace below
ech0potato commentedon Jun 25, 2026
Another data point for this issue — same kernel panic happened to me today.
Environment:
xnu-12377.81.4~5/RELEASE_ARM64_T6030opencode.exe(PID 95337)Panic string:
Largest zones at crash:
data.kalloc.1024data_shakalloc.3072APFS_4K_OBJSdata.kalloc.1024, ~20.8 million elementsSymptoms, panic signature, and backtrace are identical to what's already reported here. Just adding another confirmation.
markjaquith commentedon Jul 1, 2026
@ech0potato @SamuelSmeys @huashiyiqike @shiyan-salt Are any of you using security software like Crowdstrike Falcon? I believe these sorts of things hook into
com.apple.iokit.EndpointSecurityI'm also seeing these same kernel panics, correlated with OpenCode usage leveraging a lot of worktree creation in massive Git repos. Crowdstrike Falcon is currently my prime suspect, but I don't have a smoking gun.
vv111y commentedon Jul 12, 2026
I hit this on July 11, 2026.
1.17.15Mac17,8)25F71The panic signature was:
Additional details:
The machine had been up for roughly 11 days. I was using OpenCode against a local
rapid-mlxserver running Qwen3.6-35B-A3B-8bit. The model context and KV cache had grown substantially, although the panic itself was kernel zone-map exhaustion rather than an ordinary process-memory or Metal OOM.I am not running CrowdStrike Falcon or another enterprise EDR product. I do have LuLu and Tunnelblick installed, but neither appears in the panic backtrace.
I was not intentionally doing unusually heavy worktree creation, although I do not know whether OpenCode created or manipulated worktrees internally during the session.
I can attach the complete panic report if useful.
qy1603429908 commentedon Jul 15, 2026
Any workarounds? My little Mac Mini M4 16GB Ram gonna overwhelm...
PID COMMAND %CPU TIME #TH #WQ #PORT MEM PURG CMPRS PGRP PPID STATE BOOSTS %CPU_ME %CPU_OTHRS UID FAULTS COW
kernel_task 23.7 55:52:00 642/11 0 0 9200K 0B 0B 0 0 running 0[0] 0.00000 0.00000 0 1467592 0
24236
opencode 23.2 06:57:44 21 1 76 6105M+ 0B 5796M+ 24236 19983 sleeping *0[1] 0.00000 0.00000 501 275053228+ 653
DimitarTachev commentedon Jul 16, 2026
I had the same issue with Claude Code; the root cause was the npm installation and updates without restarting the existing processes. More details:
anthropics/claude-code#66020 (comment)
jackytin commentedon Jul 24, 2026
i meet the same issue with mac 26.5.2.
SamuelSmeys commentedon Jul 30, 2026
No, only Apple's native XProtect and Endpoint Security broker are hooked into that
joebartels-tw commentedon Aug 6, 2026
Confirming the same panic on a new M5 MacBook Pro. It has happened twice, on July 29 and August 5.
Both times I was running a few active opencode sessions, maybe 2 or 3
Environment:
1.18.10Homebrew25F84)[iTerm & intelliJ terminal]Both panics had effectively the same signature:
July 29:
August 5:
This Mac also has active Endpoint Security system extensions from CyberArk EPM, Microsoft Defender, and Kandji. Those products do not appear by name in the panic backtrace - the backtrace only names Apple’s EndpointSecurity and APFS components - but the security stack may be a useful variable to compare.
I realize
opencode.exebeing the panicked task only tells us it made the allocation that finally exhausted the zone; it does not prove OpenCode created the underlying leak. However, seeing the same process and nearly identical allocation count in two separate panics seems worth adding to the existing reports.github-actions commentedon Oct 7, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.