Skip to content

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

Open
Open
[macOS][26.814.41407] In-app Browser runtime exits during initialization; rollback restores it#39591
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't working

Description

@antonreshetov
antonreshetov
opened on Aug 20, 2026

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
  5. Retry the request; the same failure occurs.
  6. Quit the app, replace it with official version 26.810.52044, reopen it, and repeat the same Browser request.
  7. 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
  4. Replace the current app in /Applications with the extracted app and reopen it.
  5. 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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    browser
    on Aug 20, 2026

  2. github-actions commented on Aug 20, 2026

    @github-actions
    github-actionsbot
    on Aug 20, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. tsuvic commented on Aug 21, 2026

    @tsuvic
    tsuvic
    on Aug 21, 2026

    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.

  4. antonreshetov commented on Aug 26, 2026

    @antonreshetov
    antonreshetov
    on Aug 26, 2026
    Author

    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.

  5. nittajun commented on Aug 30, 2026

    @nittajun
    nittajun
    on Aug 30, 2026

    Additional sanitized reproduction data:

    • macOS
    • ChatGPT desktop app 26.825.41651 (build 7345)
    • Reproduced in a fresh local task that explicitly targeted the in-app Browser plugin
    • Before any website navigation, the runtime failed with: trusted Node process exited unexpectedly; kernel reset, rerun your request
    • A minimal runtime execution that did not request a browser connection failed with the same error
    • Reproduced again in a fresh task after removing a symlinked writable root from the project and confirming that the permission profile contained no symlink writable root
    • No final URL or page title was obtained
    • No Chrome or Computer Use fallback was attempted
    • The failure continues after updating the app to this build

    This appears to be the same failure layer as this issue and provides additional evidence that it is not solely caused by a symlink writable root.

  6. nittajun commented on Sep 2, 2026

    @nittajun
    nittajun
    on Sep 2, 2026 – with ChatGPT Codex Connector

    2026-09-02の追加確認です。macOS版ChatGPT 26.831.21537（build 7579）でも、Codexのmcp__cua_repl.jsから内蔵Browserでhttps://example.comを開く1回の試行が、初期化中に "trusted Node process exited unexpectedly; kernel reset, rerun your request" で失敗しました。ページ到達・titleは未確認です。

    Browser関連pluginはuser config上enabledで、設定内のapp versionは実機と一致し、旧trusted-browser-client hashキーはありません。js_repl=falseは存在しますが、現在はcua_repl専用launcherが使われており、この設定との因果は未確認です。今回のtool errorにworkspaceのG-12拒否は出ていません。現行CUA runtimeについて、secretやraw logを含めずに取得できる診断項目、または既知の修正buildをご案内いただけますか。

  7. jeronapoleon commented on Sep 27, 2026

    @jeronapoleon
    jeronapoleon
    on Sep 27, 2026

    Additional reproduction on a later macOS desktop build, following the documented UI-based test. This provides new dated evidence; a shared underlying cause with earlier reports is not established.

    Desktop: browser page renders, but task reader and minimal Node execution fail

    Feedback/session ID: 01a07162-664b-7e31-80fe-586893dedb18.

    Observed problem

    In this existing desktop task, mcp__node_repl__js repeatedly returns:

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

    Even nodeRepl.write(1 + 1) failed on September 25 at
    06:11:46.967–06:11:47.393 UTC. No numeric result or worker exit code was returned.

    On September 27, the user manually opened the built-in browser and loaded
    https://example.com/. A user-supplied screenshot confirms Example Domain visibly
    rendered. The user then asked this same task:

    Use the current page and quote the first paragraph verbatim.

    The code submitted through mcp__node_repl__js attempted setupBrowserRuntime(),
    an explicit agent.browsers.get('iab'), and a documentation request. No checkpoint
    established which initialization step was reached. The attempt at
    20:46:50–20:46:58 UTC returned
    the same worker error; no page content was returned. No retry was performed.

    Expected: the supported current-page reading flow returns page content or any
    required website-access prompt, rather than a worker-exit error.

    This establishes working manual page display and failing task-level reading
    through the available worker. It does not establish a separate non-Node reading
    path or prove that such a path fails. Please identify an independent supported
    route if one exists.

    Environment and chronology

    Version observations were collected on September 25, not freshly inferred for
    the September 27 occurrence:

    • Desktop /Applications/ChatGPT.app, bundle com.openai.codex, version
      26.917.62051, build 10789.
    • Bundled CLI: 0.155.0-alpha.16.3 (--version, exit 0).
    • macOS 26.5.1, build 25F80.
    • The documented /Applications/Codex.app/Contents/Resources/codex path was absent
      (exit 127); the actual bundled CLI was found in ChatGPT.app.

    Exact command output and historical build observations are attached. Current
    version observations are not substituted for missing historical OS evidence.

    September 25 app logs also recorded example.com DOM-ready at 06:11:19.782 and
    06:12:19.553 UTC. They used a client-new-thread: conversation identifier while
    ownerRoutePath pointed to the existing task. Those identifiers are preserved in
    the logs as observations; a routing defect or causal relationship is not established.

    Separate dispatcher observation; relationship unknown

    An offline test in functions.exec cell 406 on September 22 recorded a
    callback between 20:49:30.383 and 20:53:59.592 UTC, lasting 269.209 seconds
    with an injected three-second response delay. There were zero real broker calls.
    A separate tool call overlapped, and compaction was recorded at 20:53:59.202 UTC.
    These correlations do not establish timer suspension or a shared cause with the
    Node failure. Please advise whether this needs a separate issue.

    Evidence and request

    A prepared redacted ZIP contains scoped app-log excerpts, selected original
    transcript records and manifests, the timing record, and the September 27 result.
    The ZIP is not attached to this comment yet; the available GitHub integration
    can post text but cannot upload an issue attachment.

    File: codex-browser-worker-diagnostics-20260927-redacted.zip (35,889 bytes).
    SHA-256: 97dd00ee31c33b6cebe16945258738424b402f2938ad0127bea06ba64a3a205d.
    It does not contain the full conversation or the screenshot with unrelated UI.
    Older records retain their original dates; the September 27 result is the latest
    manual-display and task-reading observation. Original files remain unchanged.

    The cause, worker exit status and historical VPN/proxy conditions remain unknown.
    There is no evidence sufficient to assign the failure to network interference.
    The app recorded node_repl MCP status ready at 20:45:17.597 UTC; that metadata
    did not establish successful worker execution, as the later tool error shows.
    The September 27 app log records chatgpt_pubsub_transport_closed at 20:47:07.991
    UTC, after the reader error, alongside UI/metadata errors in the wider window.
    Those observations are retained without assigning them as the cause.
    Please investigate the worker startup/exit using the feedback/session ID and call
    IDs, or specify the next supported, narrowly scoped diagnostic collection step.

    Reference: https://learn.chatgpt.com/docs/reference/troubleshooting

    Latest task tool correlation: call_j0FwS7i4KBOKVPBQT4T2i1aQ (September 27).

  8. jeronapoleon commented on Sep 27, 2026

    @jeronapoleon
    jeronapoleon
    on Sep 27, 2026

    codex-browser-worker-diagnostics-20260927-redacted.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions