macOS 26.4.1: repeated Codex crashes with AppleSystemPolicy provenance errors, dyld child SIGABRT, and Array buffer allocation failures on large threads

Summary

Codex for Mac is repeatedly crashing on my machine. I am seeing two correlated failure modes:

1. Shell children launched by Codex abort immediately in dyld before shell startup.
2. Codex logs RangeError: Array buffer allocation failed while trying to serialize/send very large conversation snapshots, especially image-heavy threads.

The app bundle itself appears valid and notarized, so this does not look like a simple corrupt install.

Environment

• Codex version: 26.417.41555 (build 1858)
• Electron version from running process: 41.2.0
• macOS: 26.4.1 (25E253)
• Hardware: Apple Silicon (Mac15,3)

What I verified

• spctl --assess --type execute -vv /Applications/Codex.app reports:
• accepted
• source=Notarized Developer ID
• codesign --verify --verbose=4 /Applications/Codex.app reports:
• valid on disk
• satisfies its Designated Requirement

Crash evidence

Newest child-shell crash report:

• ~/Library/Logs/DiagnosticReports/zsh-2026-04-23-120456.ips

Relevant fields from that report:

• procName: zsh
• parentProc: codex
• responsibleProc: Codex
• exception: EXC_CRASH / SIGABRT
• stack includes:
• ignition_halt
• boot_boot
• dyld4::CacheFinder::CacheFinder(...)
• dyld4::ProcessConfig::DyldCache::DyldCache(...)

This same pattern repeats across many reports on the same date, including multiple zsh-*.ips and one bash-*.ips in ~/Library/Logs/DiagnosticReports/.

System log evidence

During the same crash window, unified logs show repeated AppleSystemPolicy / syspolicyd failures for Codex:

Time window examples:

• around 2026-04-23 12:02:00 -0500
• around 2026-04-23 12:05:23 -0500

Representative lines:

• ASP: Unable to apply provenance sandbox: ..., /Applications/Codex.app/Contents/MacOS/Codex
• Unable to initialize qtn_proc: 3
• dispatch_mig_server returned 268435459

These entries repeat many times in a burst immediately around the crashes.

Codex app log evidence

Codex logs show snapshot serialization failures in the same session:

File:

• ~/Library/Logs/com.openai.codex/2026/04/23/codex-desktop-b2bab1d7-487b-447c-8fa9-db2254e76d38-78328-t0-i1-164953-4.log

Representative error:

• Failed to send message from view
• Error invoking remote method 'codex_desktop:message-from-view': RangeError: Array buffer allocation failed

This appears while Codex is trying to send a thread snapshot / patch for a very large conversation state.

Heavy-thread correlation

The largest local session files are:

1. ~/.codex/sessions/2026/04/21/rollout-2026-04-21T11-32-29-019db0e2-d834-7b22-ad36-2932082428a5.jsonl — 38,966,307 bytes

• current crash log directly references this conversation
• contains 62 embedded "type":"image" payloads

1. ~/.codex/sessions/2026/04/20/rollout-2026-04-20T15-34-27-019dac9a-024c-7a70-949e-62fa4e7cd884.jsonl — 18,037,109 bytes

• contains 14 embedded "type":"image" payloads

1. ~/.codex/sessions/2026/04/22/rollout-2026-04-22T19-55-02-019db7d5-4bf3-7a42-98db-0e6a3d8f4cf2.jsonl — 15,237,908 bytes
2. ~/.codex/sessions/2026/04/20/rollout-2026-04-20T20-47-22-019dadb8-7eb0-7d90-9e71-21b217a7fc68.jsonl — 8,504,048 bytes

• this thread also appears in the failing snapshot log

So there seems to be a strong correlation between very large / image-heavy threads and the Array buffer allocation failed path.

Runtime memory at crash/restart window

Immediately after restart, process memory was already very high:

• Codex main process: about 1.58 GB RSS
• Codex Helper (Renderer): about 693 MB RSS
• codex app-server: about 674 MB RSS

Earlier in the session I also observed a similarly high combined footprint before another crash.

Repro pattern

I can often trigger instability with some combination of:

1. Work in a long-lived thread with many screenshots / browser automation / large tool outputs.
2. Reopen or continue one of the largest threads.
3. Codex starts trying to sync or snapshot that thread state.
4. App logs RangeError: Array buffer allocation failed.
5. Around the same time, Codex-spawned shell children (zsh, sometimes bash) begin crashing immediately in dyld.
6. The app becomes unstable or crashes again.

Expected

• Large threads should not crash snapshot serialization.
• Codex child shells should launch normally.
• AppleSystemPolicy / provenance-related failures should not cascade into repeated child-process SIGABRTs.

Actual

• Thread snapshotting appears to hit a serialization / allocation limit.
• Codex-spawned child shells repeatedly abort in dyld.
• Unified logs show repeated AppleSystemPolicy provenance failures for Codex around the same time.

Notes

• This does not appear to be a bad signature / bad notarization / corrupted app bundle on disk.
• The issue feels like a combination of:
• a large-thread memory/snapshot handling problem in Codex, and/or
• a macOS 26.4.1 provenance / child-process interaction problem when Codex repeatedly launches helpers/shells.

If useful, I can provide more sanitized excerpts from the .ips report and the Codex logs.