Codex Chrome extension 1.1.5 uses Chrome 143+ runtime.getVersion(), breaking backend discovery on Chrome 138

Open 💬 1 comment Opened Jun 13, 2026 by Rajahn

What version of the IDE extension are you using?

Codex Chrome Extension 1.1.5; chrome@openai-bundled 26.609.41114; Codex Desktop 149.0.7827.54

What subscription do you have?

Unknown / Codex Desktop user

Which IDE are you using?

Codex Desktop app / Chrome Browser Use (not IDE-specific)

What platform is your computer?

Darwin 24.6.0 arm64 arm; Google Chrome 138.0.7204.158

What issue are you seeing?

Summary: on macOS with Google Chrome 138, Codex Chrome Extension 1.1.5 shows Connected and the native host starts, but Codex Desktop cannot discover the Chrome browser backend.

Observed behavior:

  • The Codex Chrome Extension popup shows Connected.
  • The native host process is running from the chrome@openai-bundled cache.
  • Codex browser runtime cannot select the Chrome extension backend and reports: Browser is not available: extension.
  • A direct framed JSON-RPC getInfo request to the extension-host socket returns:
{"error":{"code":1,"message":"chrome.runtime.getVersion is not a function"},"id":1,"jsonrpc":"2.0"}

The installed extension package contains chrome.runtime.getVersion() in background.js. On this Chrome version, that API is not available, so backend discovery drops the Chrome backend even though the extension/native host connection otherwise exists.

What steps can reproduce the bug?

  1. On macOS, install/enable the Codex Desktop Chrome plugin and install the Codex Chrome Extension from the Chrome Web Store.
  2. Use Google Chrome 138.0.7204.158 with Codex Chrome Extension 1.1.5.
  3. Open Chrome and confirm the extension popup shows Connected.
  4. In Codex Desktop, start a browser-use / Chrome-backed task or run the browser runtime setup and try to get the extension backend.
  5. The backend is not discovered. agent.browsers.get("extension") fails with Browser is not available: extension.
  6. Probe the extension-host socket directly with a framed JSON-RPC getInfo request. The response is chrome.runtime.getVersion is not a function.
  7. Inspect the installed Web Store extension package. background.js contains one chrome.runtime.getVersion() reference.
  8. As an isolation test, loading an unpacked local copy with that call changed to chrome.runtime.getManifest().version makes backend discovery succeed and browser.user.openTabs() works.

What is the expected behavior?

Codex Desktop should discover and use the Chrome backend on supported stable Chrome versions when the Codex Chrome Extension is installed, enabled, and connected to the native host.

The extension getInfo implementation should not depend on Chrome 143+ APIs for the extension version. A compatible implementation would use:

chrome.runtime.getManifest().version

or feature-detect:

chrome.runtime.getVersion?.() ?? chrome.runtime.getManifest().version

Additional information

Chrome's runtime API docs list chrome.runtime.getVersion() as Chrome 143+. chrome.runtime.getManifest().version is available on older Chrome versions and is the compatible source for the extension version.

I found related mentions in existing issues, but they do not seem to be a standalone report for this macOS / Chrome <143 backend discovery failure:

  • #24559 mentions the same getVersion() observation while reporting a Windows localhost policy issue.
  • #22114 discusses native-host/cache path problems, which is a different failure mode.

Current local verification on the official installed package:

  • Web Store extension directory: hehggadaopoacecdllhhajmbjkdcmajg/1.1.5_0
  • manifest.json version: 1.1.5
  • background.js contains one chrome.runtime.getVersion() reference.
  • After refreshing the Codex Chrome plugin cache to 26.609.41114, the official extension still cannot be discovered as the Chrome backend on Chrome 138.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗