Codex Desktop 26.422.71525 triggers AppleSystemPolicy/spctl failures and was involved in a macOS 26.4.1 kernel panic
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
- Verified Codex code signature:
/Applications/Codex.app: valid on disk
/Applications/Codex.app: satisfies its Designated Requirement
exit=0
- 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
- Reinstalled the current Codex Desktop cask and rebuilt the user runtime state:
- Archived Codex local runtime directories.
- Reinstalled
codex-appfrom Homebrew. - Confirmed installed app version:
CFBundleShortVersionString = 26.422.71525
CFBundleVersion = 2210
- 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.apppasses.spctl --assess --type execute --verbose=4 /Applications/Codex.appfails.spctl --assess --type execute --verbose=4 /System/Applications/TextEdit.appalso fails.- A prior kernel panic had
Codexas the panicked task andcom.apple.AppleSystemPolicyin 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.appstill passes.spctl --assess --type execute --verbose=4 /Applications/Codex.appstill fails.spctl --assess --type execute --verbose=4 /System/Applications/TextEdit.appstill fails.- No newer
panic-fullfile 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
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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
com.openai.codex/Library/Logs/DiagnosticReports/panic-full-2026-05-17-074350.0002.panicKernel panic signature
Post-reboot verification
I performed a clean reboot and did not get a new panic report. However, the SystemPolicy / Gatekeeper state is still broken:
I also restarted
syspolicyd,taskgated,trustd, andtaskgated-helperwith administrator privileges.syspolicydrestarted successfully, but bothspctlchecks still returned the sameinternal error in Code Signing subsystem.Current unified log signal
Recent logs still show the same AppleSystemPolicy / provenance sandbox failure chain while Codex is running:
Later entries also show the same pattern for:
Why this looks broader than a Codex bundle corruption
codesignpasses for both Codex and TextEdit.spctlfails for both Codex and TextEdit with the same Code Signing subsystem internal error.com.apple.AppleSystemPolicy, with Codex as the triggering task.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.