macOS GUI apps launched from Codex sandbox abort at _RegisterApplication
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 with149.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.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗