[BUG] Codex v0.118.0 causes macOS kernel panic (os_refcnt overflow) — 2 crashes in 1 day on Apple Silicon

Open 💬 8 comments Opened Apr 5, 2026 by Vsundan
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • OS: macOS 25E246 (Sequoia)
  • Chip: Apple Silicon M-series (T8132)
  • Codex version: 0.118.0 (desktop app + CLI)
  • Node: v24.14.0

Bug Description

Codex causes full macOS kernel panics with os_refcnt overflow. This happened twice in a single day (April 5, 2026), requiring hard reboots each time. All running services and work were interrupted.

Crash Signature

panic(cpu 9 caller 0xfffffe0044beb48c): os_refcnt: overflow
(rc=0xfffffe1f3ec31274, count=268435456, max=268435455) @refcnt.c:68

Panicked task: pid 64850: Codex

Kernel extension in backtrace:

com.apple.AppleSystemPolicy(2.0)
  dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)
  dependency: com.apple.security.quarantine(4)
  dependency: com.apple.security.sandbox(300.0)

Crash Details

Crash 1: PID 64850 (Codex) — os_refcnt: overflow (count=268435456, max=268435455)
Crash 2: PID 34212 (Codex) — identical crash signature, same day after updating to v0.118.0

Both crashes occurred on CPU core 9 with the same backtrace through AppleSystemPolicy.

Root Cause Analysis

Codex appears to leak file system reference counts through Apple's AppleSystemPolicy kernel extension. Each file access creates a reference via Apple's security/quarantine checks. Codex's aggressive file scanning pattern accumulates references faster than the kernel can reclaim them, eventually hitting the hard maximum of 268,435,455 and overflowing the counter.

The AppleSystemPolicy extension handles file quarantine, code signing, and Gatekeeper checks. Codex's rapid file I/O pattern triggers these checks at extreme volume without properly releasing references.

Steps to Reproduce

  1. Install Codex desktop app v0.118.0 on macOS Sequoia (Apple Silicon)
  2. Open Codex in a project directory with many files
  3. Let Codex scan and index the codebase
  4. System will kernel panic within minutes to hours

Impact

  • Full system crash requiring hard reboot
  • Data loss risk from unclean shutdown
  • All running processes killed — no graceful shutdown possible
  • This is not an app crash — it's a kernel-level failure that takes down the entire operating system

Workaround

Uninstalled Codex entirely (desktop app + CLI + all cached files). No other application on this system has ever caused a kernel panic.

Additional Notes

  • Updated from an earlier version to 0.118.0 — the crash persisted after the update
  • No other application on this machine (Claude Code, OpenClaw, Node.js services, Python bots) has triggered this issue
  • Full panic logs from /Library/Logs/DiagnosticReports/ are available upon request
  • This appears to be specific to Apple Silicon + macOS Sequoia + AppleSystemPolicy interaction

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #16767
  • #16651

Powered by Codex Action

Vsundan · 3 months ago

Reviewed both flagged issues. This is not a duplicate — it's a severity escalation of the same root cause.

  • #16767 reports syspolicyd/trustd CPU spikes — the system stays up but apps hang
  • #16651 reports Chrome/VS Code/Fork hangs — again, system stays up
  • This issue (#16866) is the worst-case outcome: the os_refcnt counter overflows at 268M and the kernel panics, crashing the entire machine. Twice in one day.

All three issues share the same root cause: Codex's child-process execution pattern triggers excessive AppleSystemPolicy validation checks. The difference is that in my case, the reference count leaked to the hard maximum and overflowed, causing a kernel-level crash rather than just CPU spikes.

This issue provides the kernel panic backtrace that confirms the connection to com.apple.AppleSystemPolicy and should help engineers understand the full severity spectrum of this bug.

Keeping this open as it documents the most severe manifestation.

etraut-openai contributor · 3 months ago

This sounds like a significant issue with MacOS. No user-mode app should be able to panic the kernel based on its file system access patterns.

RektTillNoon · 3 months ago

It is constantly crashing at this point for me.

kirahpwang · 3 months ago

I have same problem,

theyuvir · 3 months ago

Seeing the same behavior.

Codex app: Version 26.409.20454 (1462)
Codex cli: OpenAI Codex (v0.121.0)

mochafreddo · 2 months ago

Another data point with the same panic signature, observed on Codex Desktop 26.429.30905 (CFBundleVersion 2345).

Environment:

  • macOS: 26.4.1 (25E253)
  • Kernel: Darwin 25.4.0, from the panic log
  • Hardware: Apple Silicon MacBook Pro, arm64
  • Codex Desktop: 26.429.30905
  • Codex bundle id: com.openai.codex
  • Approx. panic time from log: 2026-05-04 20:56:38 KST

Symptom:

  • Full macOS kernel panic while Codex was the panicked task.
  • I do not have a deterministic reproduction yet.

Relevant panic excerpt:

panic(cpu 8 caller 0xfffffe00432941d4): os_refcnt: overflow (rc=0xfffffe1e556819c4, count=268435456, max=268435455) @refcnt.c:68
OS version: 25E253
Kernel version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:33:25 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T6041
Panicked task 0xfffffe29eeba2418: 0 pages, 1 threads: pid 97207: Codex
Kernel Extensions in backtrace:
   com.apple.AppleSystemPolicy(2.0)
      dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)
      dependency: com.apple.security.quarantine(4)
      dependency: com.apple.security.sandbox(300.0)

This looks like the same AppleSystemPolicy / AMFI / quarantine / sandbox path as the original report. Happy to provide additional sanitized panic details if they would help.

VladimirBrejcha · 1 month ago

This is a daily thing for me at this point.

We need this fixed ASAP, it is breaking workflows and remote work.