Skip to content

[macOS 26.6.2] Chrome native host signature inconsistency and browser-control timeout in 26.901.51231 #43385

Open

Description

@KAHN-creater

What version of the Codex / ChatGPT App are you using?

  • ChatGPT Desktop / Codex-integrated build: 26.901.51231 (CFBundleVersion 8109)
  • Bundled Codex CLI: 0.153.4
  • Chrome plugin: chrome@openai-bundled 26.901.51231
  • ChatGPT Chrome extension: 1.26.901.11451
  • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Google Chrome: 152.0.7977.83

What platform is your computer?

  • macOS 26.6.2 (build 25G83)
  • Apple Silicon / arm64

What issue are you seeing?

Codex can discover the installed Chrome extension, but any attempt to list or control Chrome tabs times out or returns:

nodeRepl.fetch request failed

The bundled native host initially failed code-signature verification:

ChatGPT for Chrome: invalid signature (code or signature have been modified)
In architecture: arm64

The affected path is:

~/.codex/plugins/cache/openai-bundled/chrome/26.901.51231/extension-host/macos/arm64/ChatGPT for Chrome

The embedded signature metadata identified:

Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
TeamIdentifier=2DC432GLL2
Timestamp=Sep 6, 2026 at 04:47:06

Steps to reproduce

  1. Install the bundled Browser/Chrome plugin in ChatGPT Desktop.
  2. Install and enable the ChatGPT Chrome extension in Chrome's Default profile.
  3. Set extension site access to all websites and enable Full Access in the ChatGPT side panel.
  4. Restart both Chrome and ChatGPT Desktop.
  5. Ask Codex to list Chrome tabs.
  6. Browser discovery succeeds, but the tab request waits about 30 seconds and fails.

Diagnostics completed

All bundled diagnostics pass:

  • Chrome is installed and running.
  • The extension is installed and enabled in the selected Default profile.
  • The native messaging manifest exists and is structurally correct.
  • The manifest contains the active extension ID in allowed_origins.
  • The manifest points to an existing arm64 executable.
  • The executable has no quarantine xattr.
  • Reinstalling the Browser/Chrome plugin and restarting Chrome and ChatGPT does not fix the issue.

Native messaging manifest:

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json

Local signing experiment

A backup was created before modifying the host. Ad-hoc signing was tested:

codesign --force --sign - --timestamp=none "ChatGPT for Chrome"

The modified host then passed:

valid on disk
satisfies its Designated Requirement
Signature=adhoc

However, Chrome control still timed out. Because ad-hoc signing removes OpenAI's Team ID and entitlements, it was not kept as the active host.

Interestingly, a copied backup of the original host subsequently passed Developer ID verification. That verified OpenAI-signed copy was restored to the active path:

Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
TeamIdentifier=2DC432GLL2
valid on disk
satisfies its Designated Requirement

Chrome was restarted again, but browser control still returned nodeRepl.fetch request failed.

Expected behavior

The released native host should consistently pass code-signature verification and establish the browser-control transport. Codex should be able to list, navigate, click, and type in Chrome tabs.

Additional information

This appears related to #37324, but the affected file here is the main ChatGPT for Chrome native-host executable in release 26.901.51231, rather than only classic-level.node.

No credentials, tokens, private URLs, account identifiers, or private file contents are included.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Sep 7, 2026
  2. github-actions commented on Sep 7, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  3. VidyFoo commented on Sep 27, 2026

    @VidyFoo

    This concerns the remaining browser-control timeout symptom. It does not explain or repair the code-signature inconsistency reported here; no signing changes were made in our successful run.

    On September 27, 2026, enabling FlClash TUN restored actual Chrome control on desktop 26.924.22138 (build 11645) with extension 1.26.901.11451_0.

    Before: system proxy enabled, extension/native-host checks passed, side panel worked, but browser tools timed out. The app-bundled Node helper was observed making stalled direct connections. After the user enabled TUN: the supported CUA tool returned all 11 Chrome tabs, opened https://example.com/, read its heading/body/link, and closed the test tab successfully. No official runtime/plugin files or authentication/security checks were patched.

    Full diagnostic evidence and verification.

    This is an environment-specific workaround where direct connectivity is unavailable and helper traffic needs the existing proxy. It requires TUN to remain operational, does not identify the exact failed authenticated prerequisite, and is not a universal fix for every nodeRepl.fetch error. No private logs or browser contents are attached.

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 workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions