Codex macOS app crashes with SIGABRT in computer-use-capture while loading objc-js native module

Summary

The Codex macOS app quit unexpectedly while it was actively working on a task in the conversation associated with the Feedback ID below.

The crash immediately interrupted my task and significantly disrupted my work. This is especially problematic for long-running Codex tasks, because an unexpected application-level crash terminates the active execution instead of presenting a recoverable error.

Feedback ID

019ee8f8-10a3-7110-842f-ade6115b13d1

Environment

• Codex version: 26.616.51431
• Build: 4212
• Release date shown in the app: June 21, 2026
• macOS: 26.5.1 (25F80)
• Device: 16-inch MacBook Pro
• Chip: Apple M5 Max
• Memory: 128 GB
• Architecture: ARM64 native
• System Integrity Protection: Enabled
• Approximate crash time: June 21, 2026 at 15:20:38 UTC+8

Steps to reproduce

I do not yet have a minimal deterministic reproduction.

1. Open the Codex macOS app.
2. Continue the task in the conversation associated with the Feedback ID above.
3. Allow Codex to actively process the task.
4. Codex unexpectedly terminates.
5. macOS displays the message: Codex quit unexpectedly.

The Feedback ID should make it possible to correlate this report with the exact affected session and any available application telemetry.

Expected behavior

Codex should remain open and continue processing the task.

If an internal computer-use or capture worker encounters an error, the failure should be isolated and reported inside the application. It should not terminate the entire Codex process or abruptly interrupt the active task.

Actual behavior

The entire Codex application terminated with:

• Exception: EXC_CRASH (SIGABRT)
• Termination reason: Abort trap: 6
• Faulting thread: computer-use-capture

This interrupted the task that Codex was performing.

Impact

This crash is highly disruptive because it:

• Abruptly terminates an active Codex task
• Interrupts long-running work without warning
• Requires the application and task to be reopened or resumed manually
• Makes it difficult to rely on Codex for unattended or extended tasks

A worker-level failure should not be able to bring down the entire desktop application.

Crash report findings

The macOS crash report identifies Thread 55, named computer-use-capture, as the faulting thread.

The top of the faulting stack shows an abort while Codex was loading or registering the ARM64 native Node module included with objc-js:

Triggered by Thread: 55  computer-use-capture

Exception Type:    EXC_CRASH (SIGABRT)
Exception Codes:   0x0000000000000000, 0x0000000000000000

Termination Reason:  Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: Codex

Application Specific Information:
abort() called

Relevant faulting stack:

Thread 55 Crashed:: computer-use-capture

0   libsystem_kernel.dylib        __pthread_kill + 8
1   libsystem_pthread.dylib       pthread_kill + 296
2   libsystem_c.dylib             abort + 148
3   libc++abi.dylib               __abort_message + 132
4   libc++abi.dylib               demangling_terminate_handler() + 296
5   libobjc.A.dylib               _objc_terminate() + 172
6   libc++abi.dylib               std::__terminate(void (*)()) + 16
7   libc++abi.dylib               __cxxabiv1::failed_throw(...) + 88
8   libc++abi.dylib               __cxa_throw + 92
9   node.napi.armv8.node          + 163252
10  node.napi.armv8.node          napi_register_module_v1 + 68
11  Codex Framework               napi_module_register_by_symbol(...) + 484
12  Codex Framework               node::binding::RegisterExternalReferences(...) + 2392
13  Codex Framework               node::Environment::TryLoadAddon(...) + 136
14  Codex Framework               node::binding::DLOpen(...) + 984

The native module shown in the binary image list is:

/Applications/Codex.app/Contents/Resources/app.asar.unpacked/node_modules/objc-js/prebuilds/darwin-arm64/node.napi.armv8.node

Several neighboring computer-use-capture worker threads were also in Node environment cleanup. Some of those stacks included:

node::AsyncHooks::FailWithCorruptedAsyncStack(double)
node::AsyncHooks::clear_async_id_stack()
node::FreeEnvironment(node::Environment*)
node::worker::Worker::Run()

Those cleanup stacks may be secondary fallout from the initial abort.

Based on the faulting stack, it appears that an exception escaped from the objc-js native add-on during module initialization or registration and caused the entire Codex process to abort. This is an inference from the crash report rather than a confirmed root cause.

Requested investigation

Please investigate:

1. The initialization and exception handling of the bundled objc-js ARM64 native module.
2. The computer-use-capture worker startup path on Apple Silicon.
3. Whether native Objective-C or C++ exceptions can escape through N-API module registration.
4. Why a failure in this worker terminates the entire Codex application.
5. Whether the active task can be preserved or automatically recovered after an internal worker failure.
6. Whether the Feedback ID above contains additional telemetry that can identify the exact operation being performed at the time of the crash.

The application should catch this failure, disable or restart the affected worker, and display a recoverable error instead of terminating the entire process.

A complete crash report is available, but device-specific identifiers have been omitted from the excerpt above for privacy.

<img width="2048" height="1575" alt="Image" src="https://github.com/user-attachments/assets/05b4b4c5-424c-4dd2-89b7-092225174aae" />