macOS GUI apps launched from Codex sandbox abort at _RegisterApplication

Open 💬 2 comments Opened Jun 25, 2026 by ElninoZhong

Description

Launching macOS GUI applications from a Codex sandboxed shell can crash the target app immediately with SIGABRT at _RegisterApplication.

This appears broader than a single app-specific CLI integration. I reproduced it with both Google Chrome and LibreOffice, and it is similar in shape to #13706, but these repros do not depend on Obsidian's CLI/socket behavior.

Environment

  • Codex Desktop
  • macOS 26.5.1 (25F80)
  • Apple Silicon Mac, model code observed in crash report: Mac17,2
  • Sandbox mode: workspace-write / default sandboxed command execution
  • Chrome: reproduced with 149.0.7827.158; after clean reinstall, reproduced again with 149.0.7827.197
  • LibreOffice: 26.2.4.2

Reproduction: Chrome

From a Codex sandboxed shell, run:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --headless=new \
  --user-data-dir=/private/tmp/chrome-codex-smoke \
  --no-first-run \
  --no-default-browser-check \
  --disable-gpu \
  --dump-dom about:blank

Observed result:

  • Command exits with code 134
  • Crash report shows EXC_CRASH (SIGABRT) / Abort trap: 6
  • Crash report parent/responsible process is Codex/codex
  • Faulting main-thread frames include:
abort
___RegisterApplication_block_invoke
_dispatch_once_callout
_RegisterApplication
TransformProcessType
ChromeMain
main

Running the same Chrome launch outside the sandbox via elevated execution / LaunchServices succeeds. A headless smoke test returned:

{
  "Browser": "Chrome/149.0.7827.197",
  "Protocol-Version": "1.3"
}

Reproduction: LibreOffice

From a Codex sandboxed shell, run:

soffice --headless \
  -env:UserInstallation=file:///private/tmp/libreoffice-smoke-profile \
  --convert-to pdf \
  --outdir /private/tmp \
  /private/tmp/libreoffice-smoke.txt

Observed result:

  • Command exits with code 134
  • Crash report shows EXC_CRASH (SIGABRT) / Abort trap: 6
  • Crash report parent/responsible process is Codex/codex
  • Faulting main-thread frames include:
abort
___RegisterApplication_block_invoke
_dispatch_once_callout
_RegisterApplication
GetCurrentProcess
-[NSApplication init]
+[NSApplication sharedApplication]
create_SalInstance
CreateSalInstance
InitVCL
soffice_main
main

Running the same LibreOffice conversion outside the sandbox succeeds:

convert /private/tmp/libreoffice-smoke.txt as a Writer document -> /private/tmp/libreoffice-smoke.pdf using filter : writer_pdf_Export

Expected behavior

Codex should not make these failures look like app crashes caused by Chrome/LibreOffice themselves. Ideally Codex would either:

  • detect that the command is launching a macOS GUI app and prompt/escalate to run it outside the sandbox, or
  • fail early with a clear sandbox limitation message rather than letting the GUI app abort in macOS app registration.

Notes

This looks related to #13706, but the Chrome and LibreOffice repros suggest the problem is not limited to Obsidian's CLI behavior. The common failure point is macOS app registration from a Codex-spawned sandboxed process.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗