Codex Desktop 26.422.71525 triggers AppleSystemPolicy/spctl failures and was involved in a macOS 26.4.1 kernel panic

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

Codex Desktop 26.422.71525 can trigger macOS AppleSystemPolicy / spctl failures and was involved in a kernel panic on macOS 26.4.1

Summary

On macOS 26.4.1 (25E253), Codex Desktop 26.422.71525 appears to interact badly with AppleSystemPolicy / syspolicyd. The first observed failure was a kernel panic while Codex was the panicked task. Afterward, Gatekeeper/SystemPolicy assessment started failing for both Codex and Apple's TextEdit, even though codesign --verify --deep --strict passes for Codex.

The important distinction is:

  • Code signature verification succeeds for /Applications/Codex.app.
  • SystemPolicy / Gatekeeper assessment fails through spctl, including for /System/Applications/TextEdit.app.
  • The failure was observed around Codex Desktop activity; Codex was the panicked task in the panic log.

Environment

  • macOS: 26.4.1
  • Build: 25E253
  • Hardware: Apple Silicon
  • Codex Desktop: 26.422.71525
  • Codex bundle id: com.openai.codex
  • Install channel: Homebrew cask codex-app, also supports Sparkle auto update
  • Panic file: /Library/Logs/DiagnosticReports/panic-full-2026-04-30-061041.0002.panic

Panic Summary

Relevant panic excerpt:

panic(cpu 7 caller 0xfffffe004ffaf48c): os_refcnt: overflow (rc=0xfffffe2403b00b24, count=268435456, max=268435455) @refcnt.c:68
Debugger message: panic
OS version: 25E253
Kernel version: Darwin Kernel Version 25.4.0
Panicked task: pid 71870: Codex
Kernel Extensions in backtrace:
   com.apple.AppleSystemPolicy(2.0)

What I Tried

  1. Verified Codex code signature:
/Applications/Codex.app: valid on disk
/Applications/Codex.app: satisfies its Designated Requirement
exit=0
  1. Checked Gatekeeper/SystemPolicy assessment. It failed for Codex and also for Apple's TextEdit:
/Applications/Codex.app: bundle format unrecognized, invalid, or unsuitable
exit=1
/System/Applications/TextEdit.app: bundle format unrecognized, invalid, or unsuitable
exit=1

In earlier runs, the same assessment path returned:

internal error in Code Signing subsystem
  1. Reinstalled the current Codex Desktop cask and rebuilt the user runtime state:
  • Archived Codex local runtime directories.
  • Reinstalled codex-app from Homebrew.
  • Confirmed installed app version:
CFBundleShortVersionString = 26.422.71525
CFBundleVersion = 2210
  1. Captured AppleSystemPolicy / provenance sandbox symptoms in logs during previous runs. The repeated pattern was:
AppleSystemPolicy
ASP: Unable to apply provenance sandbox
Unable to initialize qtn_proc
dispatch_mig_server returned 268435459

Expected Behavior

Codex Desktop should run without destabilizing AppleSystemPolicy / syspolicyd, and spctl --assess should continue to work for both Codex and system apps such as TextEdit.

Actual Behavior

After Codex Desktop activity, SystemPolicy assessment can enter a bad state where:

  • codesign --verify --deep --strict /Applications/Codex.app passes.
  • spctl --assess --type execute --verbose=4 /Applications/Codex.app fails.
  • spctl --assess --type execute --verbose=4 /System/Applications/TextEdit.app also fails.
  • A prior kernel panic had Codex as the panicked task and com.apple.AppleSystemPolicy in the backtrace.

Current Local Status

The machine has been restored to Codex Desktop 26.422.71525 with old local runtime state archived. I am still collecting post-reboot verification to determine whether a clean local state eliminates the issue or whether it remains reproducible on the latest version.

Post-reboot update:

  • Codex Desktop is still 26.422.71525.
  • codesign --verify --deep --strict /Applications/Codex.app still passes.
  • spctl --assess --type execute --verbose=4 /Applications/Codex.app still fails.
  • spctl --assess --type execute --verbose=4 /System/Applications/TextEdit.app still fails.
  • No newer panic-full file appeared after the original panic.

This appears related to the AppleSystemPolicy/Gatekeeper class of failures discussed in #17447, but this report is for the Desktop app and includes a kernel panic where Codex was the panicked task and com.apple.AppleSystemPolicy appeared in the backtrace. It may also be related to #17339.

Evidence Files Available Locally

Evidence directory:

/Users/crane/Library/Logs/codex-latest-restore-control/run-20260430-072755

Key files:

after_app_info.txt
after_codesign.txt
before_spctl_codex.txt
before_spctl_textedit.txt
restore.log
sw_vers.txt
post-launch-verify-20260430-073641/app_info.txt
post-launch-verify-20260430-073641/codesign.txt
post-launch-verify-20260430-073641/spctl_codex.txt
post-launch-verify-20260430-073641/spctl_textedit.txt

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19166

Powered by Codex Action

CraneHuang6 · 3 months ago

2026-05-17 recurrence on latest Codex Desktop: SystemPolicy remains broken after reboot and daemon restart

Adding a fresh recurrence from the same machine, now on a newer Codex Desktop build.

Environment

  • Hardware: Apple Silicon Mac mini, Mac16,10
  • macOS: 26.4.1 (25E253)
  • Kernel: Darwin 25.4.0 / xnu-12377.101.15
  • Codex Desktop: 26.513.31313, CFBundleVersion 2867, bundle id com.openai.codex
  • Panic report: /Library/Logs/DiagnosticReports/panic-full-2026-05-17-074350.0002.panic

Kernel panic signature

panic(cpu 7 caller 0xfffffe004a9a348c): os_refcnt: overflow (rc=0xfffffe3201390344, count=268435456, max=268435455) @refcnt.c:68
Panicked task 0xfffffe276d8d55e0: 0 pages, 1 threads: pid 31859: 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)

Post-reboot verification

I performed a clean reboot and did not get a new panic report. However, the SystemPolicy / Gatekeeper state is still broken:

$ codesign --verify --deep --strict /Applications/Codex.app
# exits 0

$ codesign --verify --deep --strict /System/Applications/TextEdit.app
# exits 0

$ spctl --assess --type execute --verbose=4 /Applications/Codex.app
/Applications/Codex.app: internal error in Code Signing subsystem

$ spctl --assess --type execute --verbose=4 /System/Applications/TextEdit.app
/System/Applications/TextEdit.app: internal error in Code Signing subsystem

I also restarted syspolicyd, taskgated, trustd, and taskgated-helper with administrator privileges. syspolicyd restarted successfully, but both spctl checks still returned the same internal error in Code Signing subsystem.

Current unified log signal

Recent logs still show the same AppleSystemPolicy / provenance sandbox failure chain while Codex is running:

kernel (AppleSystemPolicy): ASP: Unable to apply provenance sandbox: 268451845, <pid>, /Applications/Codex.app/Contents/MacOS/Codex
syspolicyd [com.apple.syspolicy.exec:default] Unable to initialize qtn_proc: 3
syspolicyd [com.apple.syspolicy.exec:default] dispatch_mig_server returned 268435459

Later entries also show the same pattern for:

/Applications/Codex.app/Contents/Resources/codex

Why this looks broader than a Codex bundle corruption

  • codesign passes for both Codex and TextEdit.
  • spctl fails for both Codex and TextEdit with the same Code Signing subsystem internal error.
  • The panic backtrace lands in com.apple.AppleSystemPolicy, with Codex as the triggering task.
  • A clean reboot and daemon restart did not clear the broken SystemPolicy state.

This appears consistent with #16866 and #19166. I am also reporting the same evidence to Apple Feedback Assistant because a user-mode app should not be able to panic the macOS kernel through file/process launch or SystemPolicy evaluation.