Codex Desktop crashes with SIGTRAP in native rust_exif parser after filesystem read on macOS

Summary

Codex Desktop crashed in the browser/main process while its native EXIF parser was handling data returned by a filesystem read. The process deliberately trapped with EXC_BREAKPOINT / SIGTRAP (brk 0) instead of rejecting the image or metadata gracefully.

This signature is distinct from the recurring Git/V8 serialization crashes being tracked in #27599.

Environment

• Codex Desktop: 26.721.41059 (build 5848)
• Codex Framework: 150.0.7871.128
• macOS: 26.5.1 (25F80)
• Architecture: Apple Silicon / ARM64
• Physical memory: 48 GB

Crash

• Process launch: 2026-07-27 18:16:27 local time
• Crash: 2026-07-27 18:37:56 local time
• Faulting thread: CrBrowserMain / com.apple.main-thread
• Exception: EXC_BREAKPOINT
• Signal: SIGTRAP
• Termination: Trace/BPT trap: 5
• ARM exception syndrome: (Breakpoint) brk 0

Relevant symbolicated stack excerpt:

v8::ValueSerializer::Delegate::HasCustomHostObject
v8::Isolate::SetIsInputHandling
rust_exif$cxxbridge1$194$parse_exif
...
v8::Function::Call
node::InternalMakeCallback
node::fs::FSReqCallback::Resolve
node::fs::AfterNoArgs
node::MakeLibuvRequestCallback<uv_fs_s, ...>::Wrapper
uv__work_done
uv_run
ChromeMain

xcrun atos against the installed Codex Framework also resolves the relevant frame to rust_exif$cxxbridge1$194$parse_exif.

Expected behavior

Invalid, unsupported, truncated, or otherwise problematic EXIF metadata should produce a recoverable parse error. It should not terminate the Codex Desktop browser process.

Actual behavior

The main process executes a native breakpoint trap and the entire desktop app exits. The app relaunches afterward.

Reproduction status

I do not yet have the exact source image because the .ips report does not retain its pathname and the unified log has no final file event. The stack shows the failure occurring after a Node filesystem completion callback enters the native EXIF parsing path.

Resource checks

• No macOS memory-pressure or Jetsam event was logged around the crash.
• The data volume had approximately 48 GB free.
• This was not an OS out-of-disk or memory-pressure termination.

I am not attaching the raw .ips publicly because it contains local paths and device identifiers. I can provide a sanitized crash excerpt or privately supply the report if requested.