›_ Codex Issues
Codex Issues / #39591

[macOS][26.814.41407] In-app Browser runtime exits during initialization; rollback restores it

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

What version of the Codex App are you using (From “About Codex” dialog)?

Regression: 26.814.41407 (build 6720).

Last known working version on the same machine: 26.810.52044 (build 6662).

What subscription do you have?

Authenticated ChatGPT desktop session (exact subscription tier not relevant to the reproduction).

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS 26.5.1, Apple Silicon).

What issue are you seeing?

After updating the macOS Codex/ChatGPT desktop app to 26.814.41407, the bundled in-app Browser cannot initialize. The Browser UI itself opens and the app can report the current tab URL through ambient state, but every attempt to use Browser control fails before a browser binding is returned.

The full observed error is:

trusted Node process exited unexpectedly; kernel reset, rerun your request

The failure occurs while initializing the bundled Browser client at:

~/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-client.mjs

Retrying produces the same error. Opening the in-app Browser and navigating to a page manually does not help.

This appears to be a desktop/runtime regression rather than a website or prompt problem: after downgrading the app on the same machine to 26.810.52044, Browser initialized immediately, returned an iab binding, opened a GitHub page, and read its DOM successfully. No project, browser-profile, or account changes were made, and no manual plugin-cache deletion was required.

What steps can reproduce the bug?

  1. Install or update the macOS Apple Silicon desktop app to 26.814.41407.
  2. Open the built-in Browser and navigate to any page.
  3. Ask Codex to inspect the open page using @Browser / the bundled Browser tool.
  4. Observe that Browser runtime initialization exits before returning a binding, with:

trusted Node process exited unexpectedly; kernel reset, rerun your request

  1. Retry the request; the same failure occurs.
  2. Quit the app, replace it with official version 26.810.52044, reopen it, and repeat the same Browser request.
  3. Observe that Browser control works on the same machine and session.

What is the expected behavior?

The bundled Browser runtime should initialize, connect to the built-in Browser, return a binding, and allow Codex to inspect and interact with the active tab, as it does in 26.810.52044.

Additional information

Temporary rollback workaround for affected Apple Silicon users:

  1. Quit the desktop app completely.
  2. Keep a copy of the current app if needed.
  3. Download the previous build from the official OpenAI update host:

https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-arm64-26.810.52044.zip

  1. Replace the current app in /Applications with the extracted app and reopen it.
  2. Confirm that About shows 26.810.52044 (build 6662).

Official Sparkle appcast used to identify the previous build:
https://persistent.oaistatic.com/codex-app-prod/appcast.xml

Automatic updates may reinstall the affected build, so this is only a temporary workaround, not a fix.

Related issue: #39136 reports Browser initialization failures on Windows for the same plugin version, but with a different Trusted RPC dependency is not within a trusted code path error. This macOS report is specifically about the trusted Node process exiting unexpectedly.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 8 days ago

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

  • #38549

Powered by Codex Action

tsuvic · 7 days ago

Same-build data point from the other side, with the honest caveat that my usage is lighter: on my machine (macOS 26.5.2 arm64, 26.814.41407 build 6720 — the same build) the browser-side runtime starts cleanly and the failure signature is absent.

From the desktop logs (UTC) after updating to this build:

  • 2026-08-20T05:35:27Z and 2026-08-20T05:36:52Z: browser_use_iab_backend_startup_started → browser_use_iab_backend_startup_ready with backend=iab platform=darwin release=26.814.41407, native pipe listening at /tmp/codex-browser-use/<uuid>.sock, peer authorization mode=packaged — two consecutive clean startups, zero errors/warnings in those logs.
  • Zero occurrences of trusted Node process exited unexpectedly / kernel reset in any desktop log from 2026-08-19 through 2026-08-21.
  • The plugin cache ~/.codex/plugins/cache/openai-bundled/browser/26.814.41407 (including scripts/browser-client.mjs) was extracted at update time (2026-08-19T08:58 local) and is intact.

Caveat: no Browser-tool turn has run here since the update, so this verifies the session backend startup, not a completed browser-client.mjs invocation. Even so, the failure is not universal on 26.814.41407, which points at machine-local state around the trusted Node host rather than the build itself. If it helps narrow: I would diff that cache directory against a known-good install and check Console for crash reports of the trusted Node host at the kernel reset moments — the signature is the host dying during init, not a binding lookup failing.

antonreshetov · 2 days ago

Update: this is still reproducible after updating the same machine to ChatGPT/Codex Desktop 26.820.60940 (build 7119). The last working build here remains 26.810.52044 (build 6662) on macOS 26.5.1, Apple Silicon.

Additional diagnostics from 26.820:

  • 26.810 bundles cua-node 0.0.8/20260812163607-f77e89a843fc; 26.820 bundles cua-node 0.0.9/20260821052104-5281bf8eab6c. Both bundles use Node 24.19.0.
  • The desktop log records the direct rejection reason:
dynamic_app_tools_peer_rejected reason=missing-code-signing-identity
browser-use native pipe rejected socket peer reason=missing-code-signing-identity
  • However, macOS codesign verification outside the sandbox reports ChatGPT.app, node_repl, node, and browser-use-peer-authorization.node as valid Notarized Developer ID artifacts from OpenAI, all with TeamIdentifier 2DC432GLL2. Verifying the currently running node_repl and node processes also reports them as dynamically valid with the same TeamIdentifier.
  • The Browser client changed between builds: SHA-256 is 9230e2bd8b24b7ac7a0ba6774c64bf0d78ecdabbdd91d0ed627b02a587bae2df in 26.810 and 2158647076eed887c7591cca0957da78747ab9155819d64409d6b895e84ed99b in 26.820. The user config still contains the 26.810 trusted Browser-client hash. Also, the Browser plugin cache has no browser/latest symlink, while the Chrome plugin cache does. Those may be migration clues, but the immediate failure is the packaged native-pipe authorizer reporting a missing signing identity even though the peer identity is present.
  • The Browser tool still fails with:
trusted Node process exited unexpectedly; kernel reset, rerun your request
  • The older composer-permission-mode-visibility migration is already in the current object-shaped format on this machine, so this does not appear to be that previous global-state migration problem.

This now looks more specifically like a regression in peer identity extraction or validation in the packaged cua-node / native-pipe runtime, rather than damaged or unsigned local binaries. I can provide a redacted log excerpt if that would help.