Codex Chrome bridge backend unavailable on macOS despite healthy Chrome extension/native host

Codex Chrome bridge backend unavailable on macOS despite healthy Chrome extension/native host

Summary

Codex Desktop on macOS cannot connect to the Codex Chrome Extension bridge.

Chrome itself is working, and direct Chrome DevTools/CDP access on port 9222 is working, but Codex does not expose the Chrome browser backend to the model-side browser runtime.

Main failure:

agent.browsers.list() => []
agent.browsers.get("extension") => Browser is not available: extension
agent.browsers.get("iab") => Browser is not available: iab

This appears to be a Codex Desktop browser backend registration issue, not a Chrome install/profile issue.

Environment

Platform: macOS
Codex app: 26.616.51431
Codex app build: 4212
Codex CLI: codex-cli 0.142.0-alpha.6
Google Chrome: 149.0.7827.156
Codex Chrome Extension: 1.1.5_0
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Bundled Chrome browser client version: 26.616.51431

What works

Chrome is installed and running.

The Codex Chrome Extension is installed and enabled in the selected Chrome profile.

The native messaging host manifest exists and validates correctly.

Direct Chrome DevTools/CDP access works through:

http://127.0.0.1:9222/json/version

That endpoint returns a valid DevTools websocket URL, and direct CDP control can interact with the visible Chrome tab.

This means Chrome itself is healthy and usable. The issue appears specific to Codex's browser bridge/backend registration.

What fails

After initializing the Codex browser runtime, no browser backend is available.

Code run inside the Codex node_repl/browser runtime:

var bridgeBrowserList = await agent.browsers.list();
nodeRepl.write(JSON.stringify({ bridgeBrowserList }, null, 2));

Actual output:

{
  "bridgeBrowserList": []
}

Trying to get the Chrome extension backend fails:

await agent.browsers.get("extension")

Actual result:

Browser is not available: extension

Trying to get the in-app browser backend also fails:

await agent.browsers.get("iab")

Actual result:

Browser is not available: iab

Chrome diagnostics already checked

Chrome running check passes.

Result summary:

{
  "platform": "darwin",
  "running": true,
  "processes": [
    {
      "process_name": "Google Chrome",
      "command": "Google Chrome"
    }
  ]
}

Chrome installed check passes.

Result summary:

{
  "installed_browsers": [
    {
      "name": "Google Chrome",
      "bundle_id": "com.google.Chrome",
      "path": "/Applications/Google Chrome.app",
      "version": "149.0.7827.156"
    }
  ]
}

Codex Chrome Extension diagnostics already checked

The Codex Chrome Extension is installed and enabled in the selected Chrome profile.

Result summary:

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "selectedProfileDirectory": "Default",
  "installed": true,
  "enabled": true,
  "profiles": [
    {
      "profileDirectory": "Default",
      "installed": true,
      "registered": true,
      "enabled": true,
      "disabled": false,
      "versions": [
        "1.1.5_0"
      ],
      "selected": true
    }
  ],
  "exitCode": 0
}

Native host diagnostics already checked

The native messaging host manifest exists and validates correctly.

Result summary:

{
  "expectedHostName": "com.openai.codexextension",
  "actualHostName": "com.openai.codexextension",
  "expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
  "allowedOrigins": [
    "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"
  ],
  "exists": true,
  "nameMatches": true,
  "hasExpectedOrigin": true,
  "correct": true,
  "problem": null
}

Steps tried

1. Confirmed Chrome is installed.
2. Confirmed Chrome is running.
3. Confirmed the Codex Chrome Extension is installed.
4. Confirmed the Codex Chrome Extension is enabled in the selected Chrome profile.
5. Confirmed the native messaging host manifest exists.
6. Confirmed the native host manifest has the expected extension origin.
7. Loaded the bundled Codex Chrome browser client.
8. Called agent.browsers.list().
9. Retried after waiting.
10. Called agent.browsers.get("extension").
11. Called agent.browsers.get("iab").
12. Verified direct Chrome DevTools/CDP access on port 9222 works as a fallback.

Expected behavior

When Chrome is running, the Codex Chrome Extension is installed/enabled, and the native host manifest is valid:

await agent.browsers.list()

should include the Chrome extension backend.

Then:

await agent.browsers.get("extension")

should succeed.

If the in-app browser backend is available, then:

await agent.browsers.get("iab")

should also succeed or provide a clearer reason why it is unavailable.

Actual behavior

Codex returns an empty browser backend list:

[]

Chrome bridge access fails:

Browser is not available: extension

In-app browser access also fails:

Browser is not available: iab

Why this appears to be a Codex bridge/backend issue

The Chrome side passes all local checks:

• Chrome is installed.
• Chrome is running.
• The selected Chrome profile has the Codex Chrome Extension installed and enabled.
• The native messaging host manifest exists and validates correctly.
• Direct Chrome DevTools/CDP control through port 9222 works.

The failure happens specifically at the Codex browser runtime/backend discovery layer:

agent.browsers.list()
agent.browsers.get("extension")
agent.browsers.get("iab")

That suggests browser backend registration/session discovery is failing inside Codex Desktop, the bundled browser runtime, or the model-side node_repl/MCP bridge.

Related issues

This appears related to these existing reports:

• [https://github.com/openai/codex/issues/26470](<https://github.com/openai/codex/issues/26470>)
• [https://github.com/openai/codex/issues/25811](<https://github.com/openai/codex/issues/25811>)
• [https://github.com/openai/codex/issues/29348](<https://github.com/openai/codex/issues/29348>)
• [https://github.com/openai/codex/issues/29385](<https://github.com/openai/codex/issues/29385>)

The closest match appears to be issue 26470, where agent.browsers.list() returns an empty list even though the local browser setup checks pass.

Issue 25811 also looks related because it reports the Chrome extension appearing connected while Codex still returns:

Browser is not available: extension

Impact

This blocks Codex Chrome/browser workflows even though Chrome and the extension appear healthy.

The only working fallback is direct Chrome DevTools/CDP control through port 9222, but the official Codex Chrome bridge path is unavailable.

This can cause repeated reinstall/restart/retry loops because the extension and native host checks pass, while the actual Codex browser backend list remains empty.

Request

Please investigate why Codex Desktop can have a healthy Chrome extension/native host setup but still return:

await agent.browsers.list()
// []

Useful improvements would be:

• expose a clear diagnostic when backend registration fails,
• distinguish extension/native-host health from backend registration/session health,
• make agent.browsers.list() report why chrome and iab are unavailable instead of returning an empty list,
• avoid requiring local security-weakening workarounds for normal browser backend registration.

Recurrence: Slack feedback on Nightly 26.708

Slack report: [https://openai.enterprise.slack.com/archives/C09NZ54M4KY/p1783519959320029](<https://openai.enterprise.slack.com/archives/C09NZ54M4KY/p1783519959320029>)

Reporter says they cannot connect Chrome with Codex on Nightly 26.708.10433 (4812) and provided feedback UUID / thread id no-active-thread-019f4211-e226-7173-9c19-db706d8ee73c.

Sentry lookup mapped the UUID to CODEX-2QZF, actual event id / trace id db4c7f4466534de7b39a8a880734a1b6, occurred 2026-07-08T14:11:45.631Z, unresolved/new, no stacktrace. Event metadata: CLI 0.143.0-alpha.39, session_source=vscode, endpoint /responses, ChatGPT auth header attached with no auth errors, doctor warning only mcp.config. Indexed Sentry log/span searches by thread id and event id returned no rows. Raw feedback attachments could not be listed because the Sentry attachment helper returned get_event_attachment not found.

Caveat: the user-facing report does not include the exact visible error text, so this may be the Chrome extension bridge/backend-unavailable family, the Browser/IAB attach path, or stale browser-use vs current browser plugin resolution. Closest Slack context from Jul 7: a Nightly 26.707.11040 IAB attach failure where the runtime invoked obsolete browser-use 0.1.0-alpha1; removing stale plugins/cache/openai-internal-testing config/folder helped IAB in a new thread. That case also had a separate Computer Use service/client protocol skew. This recurrence should preserve the exact error text/screenshot if the reporter follows up.