Chrome plugin hardcodes standard Google Chrome and cannot use Chrome for Testing or Chromium on macOS

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

Codex App 26.707.31428 (build 5059), bundled codex-cli 0.144.0-alpha.4.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

macOS 27 beta 3, Apple Silicon arm64
Darwin 27.0.0 arm64 arm

What issue are you seeing?

The bundled Codex Chrome plugin on macOS assumes the browser is the regular
Google Chrome application and profile. It does not detect or connect to Google
Chrome for Testing, even when the ChatGPT Chrome Extension is installed,
enabled, and registered in that browser's active profile.

Environment observed:

Chrome plugin: 26.707.31428
Google Chrome for Testing: 148.0.7778.56
Chrome for Testing bundle ID: com.google.chrome.for.testing
Chromium: 149.0.7812.0
Chromium bundle ID: org.chromium.Chromium
ChatGPT Chrome Extension: 1.2.27203.26575_0
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Chrome for Testing profile: ~/Library/Application Support/Google/Chrome for Testing/Default

Before a local validation patch, the Codex browser runtime exposed only the
in-app browser and could not select the extension backend:

agent.browsers.get("extension")
Browser is not available: extension

The extension side panel displayed:

Install the app to use ChatGPT in Chrome

However, a profile-aware check against Chrome for Testing showed that the
extension itself was healthy:

{
  "userDataDirectory": "~/Library/Application Support/Google/Chrome for Testing",
  "selectedProfileDirectory": "Default",
  "installed": true,
  "enabled": true,
  "profiles": [
    {
      "installed": true,
      "registered": true,
      "enabled": true,
      "disabled": false,
      "versions": ["1.2.27203.26575_0"]
    }
  ]
}

The bundled plugin helpers contain separate hardcoded assumptions for regular
Chrome:

installed-browsers.js
  bundle ID: com.google.Chrome
  app name: Google Chrome.app

chrome-is-running.js
  process names: Google Chrome / Google Chrome Helper
  app path fragment: /Google Chrome.app/Contents/
  singleton profile root: ~/Library/Application Support/Google/Chrome

check-extension-installed.js
  default profile root: ~/Library/Application Support/Google/Chrome

check-native-host-manifest.js
  default manifest root: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts

open-chrome-window.js
  bundle ID: com.google.Chrome
  app name: Google Chrome.app
  default profile root: ~/Library/Application Support/Google/Chrome

Chrome for Testing uses different values for every one of those identifiers:

bundle ID: com.google.chrome.for.testing
app name: Google Chrome for Testing.app
process names: Google Chrome for Testing / Google Chrome for Testing Helper
profile root: ~/Library/Application Support/Google/Chrome for Testing

The same hardcoding also excludes Chromium. The installed Chromium application
on this machine reports:

bundle ID: org.chromium.Chromium
app name: Chromium.app
process names: Chromium / Chromium Helper
profile root: ~/Library/Application Support/Chromium
native host root: ~/Library/Application Support/Chromium/NativeMessagingHosts

The Codex native-host manifest already exists under Chromium's native-host root,
but the bundled detection and launch helpers do not recognize Chromium's bundle
ID, process names, application name, or profile location. The end-to-end
extension reproduction in this report was performed with Chrome for Testing;
Chromium's exclusion is confirmed from the same helper code and the installed
application identity, but the ChatGPT Chrome Extension was not installed in the
Chromium profile used for this inspection.

There was also a second cache-reconciliation failure that made the symptom more
confusing. The native-host manifests for regular Chrome, Chrome for Testing,
and Chromium pointed to:

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

but chrome/latest was a stale symlink to removed plugin version
26.707.30751. The native-host executable existed only in the installed
26.707.31428 directory. The manifest's JSON structure and allowed origin were
valid, but its resolved executable path did not exist.

After locally validating the proposed behavior by:

1. repointing chrome/latest to the complete 26.707.31428 plugin,
2. making all five helpers use the Chrome-for-Testing identifiers and profile,
3. reopening the already-installed extension from Chrome for Testing,

the official extension backend became available without reinstalling the app or
extension. I used https://www.microsoft.com/en-za as a basic test:

agent.browsers.get("extension")                 // succeeded
browser.user.openTabs()                         // returned the visible test tab
browser.user.claimTab(tab)                      // succeeded
tab.url()                                       // https://www.microsoft.com/en-za

This indicates that Chrome for Testing and the extension/native-host protocol
are compatible; discovery and cache reconciliation are the failing layers.

What steps can reproduce the bug?

1. On macOS, install and launch Google Chrome for Testing without launching

regular Google Chrome.

1. Install and enable the ChatGPT Chrome Extension in Chrome for Testing's

Default profile.

1. Confirm the extension is registered under:

``text
~/Library/Application Support/Google/Chrome for Testing/Default/Extensions/hehggadaopoacecdllhhajmbjkdcmajg
``

1. In Codex Desktop, invoke @chrome and ask it to inspect or navigate the

current Chrome-for-Testing tab.

1. Observe that the bundled diagnostics report regular Google Chrome as not

running and inspect the regular Chrome profile rather than Chrome for
Testing.

1. Observe that the extension backend is unavailable:

``text
Browser is not available: extension
``

1. If reproducing after a bundled Chrome plugin update, also resolve the native

host manifest's path. In the affected update sequence, chrome/latest
pointed to a removed version even though a newer complete plugin was
installed.

What is the expected behavior?

Codex's Chrome plugin should support Google Chrome for Testing and Chromium as
first-class Chromium-family browsers on macOS.

If Chrome for Testing or Chromium is running and contains an enabled ChatGPT
Chrome Extension, the plugin should consistently select that same browser
variant for:

• installed-browser detection,
• running-process detection,
• profile and extension detection,
• native-host manifest installation and validation,
• opening a browser window, and
• extension-backend registration.

The native-host manifest must always resolve to an existing executable after a
plugin update. A structurally valid manifest whose path resolves through a
stale latest symlink should be reported and self-healed as a broken install,
not presented as “Install the app.”

Additional information

Proposed upstream fix

1. Centralize supported macOS Chromium variants in one data structure instead

of hardcoding regular Chrome independently in five scripts. For example:

```text
regular Chrome
bundle ID: com.google.Chrome
app: Google Chrome.app
profile: ~/Library/Application Support/Google/Chrome

Chrome for Testing
bundle ID: com.google.chrome.for.testing
app: Google Chrome for Testing.app
profile: ~/Library/Application Support/Google/Chrome for Testing

Chromium
bundle ID: org.chromium.Chromium
app: Chromium.app
profile: ~/Library/Application Support/Chromium
```

1. Select one variant consistently, using this order:

• an explicit supported config/environment override,
• a running supported browser with the extension installed and enabled,
• regular Chrome as the compatibility fallback.

1. Make installed-browsers.js, chrome-is-running.js,

check-extension-installed.js, check-native-host-manifest.js, and
open-chrome-window.js consume the same selected-variant record.

1. Reconcile the native-host manifest for every installed supported Chrome

variant, or at minimum for the selected variant. Validation should check that
the manifest's resolved executable exists and is executable, not only that
its name and allowed origin match.

1. Avoid registering the native host through a mutable cache alias where

possible. Prefer a stable host location outside the replaceable plugin cache.
If latest remains part of the design:

• install the new complete plugin version first,
• atomically update latest,
• reconcile manifests,
• verify the resolved host executable,
• only then remove the old version,
• retain or restore the previous target if validation fails.

1. Improve diagnostics to report:

• which supported browser variants and profile roots were scanned,
• which variant was selected,
• whether the extension was installed/enabled there,
• the resolved native-host executable path,
• whether the cache alias is dangling.

1. Add macOS tests for:

• Chrome for Testing as the only installed/running browser,
• Chromium as the only installed/running browser,
• multiple supported variants installed with the extension enabled in only one,
• process and profile selection staying on the same variant,
• a native-host manifest resolving through a dangling latest symlink,
• plugin update ordering that must not publish a broken host path.

Related issues

• #29389 — broader macOS case where extension/native-host checks pass but the

browser backend is unavailable.

• #24296 — Windows report identifying the architectural risk of running the

native host from the mutable chrome/latest plugin-cache path.

This report is narrower than #29389 because changing the browser-variant
identifiers and repairing the stale cache alias made the extension backend work
immediately. It adds a macOS Chrome-for-Testing reproduction and a concrete
cross-helper consistency requirement.