›_ Codex Issues
Codex Issues / #30043

macOS GUI apps launched from Codex sandbox abort at _RegisterApplication

Open 💬 8 comments Opened Jun 25, 2026 by ElninoZhong
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 openai/codex#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 openai/codex#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 ↗

8 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #28752

Powered by Codex Action

sachasayan · 1 month ago

Confirming this still reproduces in the current unified ChatGPT/Codex desktop build, and that it affects Electron development runtimes as well as Chrome/LibreOffice.

Environment

  • ChatGPT/Codex app: 26.707.41301 (CFBundleVersion 5103)
  • Bundled CLI: codex-cli 0.144.0-alpha.4
  • Codex framework: 150.0.7871.115
  • macOS: 26.5.1 (25F80)
  • Hardware: MacBookAir10,1, Apple Silicon
  • Target runtime: Electron 41.5.0, launched from a Node-based development harness
  • Sandbox: default/workspace-write Codex command execution

Observed behavior

Commands which launch the development Electron.app from Codex produce native crash reports before the application's JavaScript main process starts:

Exception Type: EXC_CRASH (SIGABRT)
Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6

abort
___RegisterApplication_block_invoke
_RegisterApplication
GetCurrentProcess
-[NSApplication init]
+[NSApplication sharedApplication]
ElectronMain

The crash reports identify ChatGPT as the responsible process and com.openai.codex as the coalition. The macOS unified log gives the underlying reason:

Sandbox: Electron deny mach-lookup com.apple.windowserver.active
Sandbox: Electron deny mach-lookup com.apple.coreservices.launchservicesd

_RegisterApplication(), unable to get application ASN from launchservicesd,
and this application requires an ASN, so aborting.

Repeated or parallel agent validation attempts create a separate macOS crash report for every launch. In one session this produced two bursts of five reports, making the problem look like an Electron/application regression rather than a Codex sandbox limitation.

Workaround

Running Electron-launching validation commands outside the sandbox through the escalation/approval path avoids this boundary. We have added repository guidance requiring escalation for Electron, smoke, profile, and E2E launch commands.

Requested behavior

The ideal behavior remains what the original report proposes: detect macOS GUI application launches and request escalation automatically. At minimum, Codex should fail before spawning the GUI child with a clear diagnostic. Allowing AppKit to call abort() creates misleading crash reports and makes downstream application maintainers investigate crashes that occurred before their code ran.

Related reports with the same broader sandbox boundary include #13706 and the Chromium Mach-service failure in #31560.

igor-markin · 25 days ago

Confirming that this issue is still reproducible in the current ChatGPT/Codex Desktop version 26.727.51351, released on August 1, 2026.

This is not an isolated crash. macOS generated seven reports with the same crash fingerprint during normal Playwright/browser-testing work initiated from Codex:

  • August 2, 2026: 6 identical reports
  • August 3, 2026: 1 identical report

<details>
<summary>Sanitized representative crash report</summary>

The following excerpt has been sanitized. User paths, process IDs, incident IDs, crash reporter keys, device identifiers, boot/wake UUIDs, exact timestamps, memory addresses, and register state were removed.

Process:             Google Chrome for Testing
Identifier:          com.google.chrome.for.testing
Version:             151.0.7922.34
Code Type:           ARM-64 (Native)
Coalition:           com.openai.codex
Responsible Process: ChatGPT

OS Version:          macOS 26.5.2 (25F84)
System Integrity Protection: enabled

Triggered by Thread: 0
Dispatch Queue:      com.apple.main-thread

Exception Type:      EXC_CRASH (SIGABRT)
Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: Google Chrome for Testing

Application Specific Information:
abort() called

Thread 0 Crashed:
0   libsystem_kernel.dylib                  __pthread_kill
1   libsystem_pthread.dylib                 pthread_kill
2   libsystem_c.dylib                       abort
3   HIServices                              ___RegisterApplication_block_invoke
4   libdispatch.dylib                       _dispatch_client_callout
5   libdispatch.dylib                       _dispatch_once_callout
6   HIServices                              _RegisterApplication
7   HIServices                              TransformProcessType
8   Google Chrome for Testing Framework     ChromeMain
9   Google Chrome for Testing Framework     ChromeMain
10  Google Chrome for Testing Framework     ChromeMain
11  Google Chrome for Testing               main
12  dyld                                    start

All seven reports have the same relevant signature: Chrome for Testing 151.0.7922.34, SIGABRT, and TransformProcessType -> _RegisterApplication -> abort, with ChatGPT as the responsible process and com.openai.codex as the coalition.

</details>

The issue is still current and disrupts normal browser-testing workflows by generating repeated macOS crash reports and dialogs. It needs a product-level fix. Requiring manual escalation for every affected launch is not an adequate long-term solution; Codex should automatically detect these macOS GUI/headless browser launches and escalate them, or fail early with a clear sandbox diagnostic before spawning a process that aborts.

tonydehnke · 24 days ago

Confirming a related variant on macOS 27.0 (26A5388g), Apple Silicon, with ChatGPT/Codex Desktop 26.727.51351.

This affects the normal installed /Applications/Google Chrome.app (151.0.7922.72), not only Chrome for Testing or an explicitly launched Playwright command.

While Codex was open, macOS generated 34 Chrome crash reports in one session. Representative reports identify com.openai.codex as the coalition and ChatGPT as the responsible process. The failure is EXC_CRASH (SIGABRT) / Abort trap: 6, with the main thread ending in:

abort
___RegisterApplication_block_invoke
_RegisterApplication
TransformProcessType
ChromeMain
main

Normal interactive launching of the same Chrome app succeeds, so this appears specific to the Codex-spawned/sandboxed launch path. In this case the user did not intentionally open Chrome or initiate browser testing; the repeated launches occurred in the background and produced intrusive crash dialogs.

This supports detecting the launch before spawning Chrome and either escalating automatically or surfacing a clear sandbox diagnostic instead of retrying.

joshduffy · 18 days ago

Confirming this is still reproducible in the current ChatGPT/Codex Desktop build and with the normal installed Chrome app.

Environment

  • ChatGPT/Codex Desktop: 26.803.41515 (CFBundleVersion 6321)
  • macOS: 26.5 (25F71)
  • Apple Silicon
  • Google Chrome: 151.0.7922.109

Current impact

macOS recorded 11 distinct Google Chrome crash incidents during the last 24 hours. Two pairs occurred within the same second, so these are separate process incidents rather than duplicate report files. The ordinary interactive Chrome instance remained healthy under launchd; only additional Chrome processes associated with Codex aborted.

Every incident has the same relevant fingerprint:

EXC_CRASH (SIGABRT)
Abort trap: 6

abort
___RegisterApplication_block_invoke
_RegisterApplication
TransformProcessType
ChromeMain
main

The reports identify ChatGPT as the responsible process and com.openai.codex as the coalition. The direct parent for the checked incidents was a short-lived node process.

The macOS unified log for a representative incident contains:

Sandbox: Google Chrome deny mach-lookup com.apple.coreservices.launchservicesd
Sandbox: Google Chrome deny mach-lookup com.apple.windowserver.active

The transient Node parent also shows Codex sandbox denials. Chrome aborts about 0.2 seconds after launch while registering as a foreground application. The same failure occurred again after a full Mac reboot, so restarting Chrome or macOS does not clear it.

This newer build evidence supports the requested product behavior: detect this launch path before spawning the GUI child, then escalate or fail with a clear sandbox diagnostic instead of generating repeated native Chrome crash reports.

masonjames · 14 days ago

Also confirming it's reproducible on this end. Even happening on MacOS 27 Beta.

For others who hit this before it's fixed, here's what I told codex:

Make this part of your long-term memory: On macOS, do not launch Chrome or other AppKit GUI applications inside the Codex sandbox. 
When browser/headless Chrome execution is required, request escalated execution outside the sandbox.

If that isn't possible, stop and give me the exact command to run manually in Terminal instead of attempting the sandboxed launch.
kkugot · 10 days ago

The Chrome plugin is enabled in config.toml, and its launcher forces a separate instance using open -n in [open-chrome-window.js] (line 345). The crash happens before Chrome reads the selected profile, so deleting or repairing profiles will not help.

AaronRayRay · 13 hours ago

I can reproduce the same _RegisterApplication SIGABRT pattern on macOS 26.6.2 with Codex Desktop 26.820.60940. Across 20 to 27 August this Mac retained 33 matching reports: 12 Playwright, 10 Firefox, 6 Google Chrome and 5 React Native DevTools. The reports consistently show node as parent and ChatGPT/Codex as the responsible process or resource coalition. Three React Native DevTools crashes on 27 August followed separate Codex-started Expo Metro sessions. This turns normal Codex tooling into repeated user-visible “quit unexpectedly” dialogs. Please detect GUI launches in the sandbox and escalate or fail early, and avoid launching Expo DevTools in this context.