Chrome Extension not working with Chrome Beta 150 #28584

Activity

1. rimanek

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 16, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   browser

   on Jun 16, 2026
3. Niek commented on Jun 17, 2026

   

   Niek

   on Jun 17, 2026

   More actions

   I can reproduce a related second-stage failure on macOS with Chrome Beta 150.

   Initial state matched this issue: Codex had installed the native host manifest under stable Chrome, but not under Chrome Beta:

   ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json
   # present
   
   ~/Library/Application Support/Google/Chrome Beta/NativeMessagingHosts/com.openai.codexextension.json
   # missing
   

   After copying the same native host manifest into the Chrome Beta NativeMessagingHosts directory and fully restarting Chrome Beta, the extension popup changed to connected. The native host process also starts successfully:

   ~/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
   

   The Chrome backend is then usable from Codex. agent.browsers.list() includes the extension backend and browser.user.openTabs() succeeds, so the live bridge is working.

   However, Codex settings still reports the Chrome integration as not connected. The bundled checker appears to keep inspecting stable Chrome only:

   {
     "userDataDirectory": "~/Library/Application Support/Google/Chrome",
     "selectedProfileDirectory": "Default",
     "installed": false,
     "enabled": false
   }

   When the same checker is pointed at Chrome Beta, it passes:

   {
     "userDataDirectory": "~/Library/Application Support/Google/Chrome Beta",
     "selectedProfileDirectory": "Default",
     "installed": true,
     "enabled": true,
     "versions": ["1.1.5_0"]
   }

   So there seem to be two Chrome Beta gaps:

   1. The native host manifest is not installed for Google/Chrome Beta.
   2. After fixing that manually, the Codex app settings health check still reports disconnected because it checks stable Chrome rather than the live connected Chrome Beta backend/profile.

   Environment details from this repro:

   • macOS arm64
   • Chrome Beta 150.0.7871.13
   • Codex Chrome extension 1.1.5_0
   • Chrome plugin bundle 26.611.61753
4. rimanek commented on Jun 29, 2026

   

   rimanek

   on Jun 29, 2026

   Author

   More actions

   About two weeks since I reported the bug and no action from Codex team here - does that mean this bug will not be dealt with?
5. Javoom commented on Jul 9, 2026

   

   Javoom

   on Jul 9, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming this remains reproducible on the July 9, 2026 unified ChatGPT/Codex build, including after reinstalling the bundled Chrome plugin.

   Environment:

   • ChatGPT/Codex app: 26.707.31123 (build 5042)
   • macOS, Apple Silicon
   • Google Chrome Beta: 151.0.7922.19
   • ChatGPT Chrome Extension: 1.2.27203.26575_0
   • Bundled plugin: chrome@openai-bundled version 26.707.31123
   • macOS default browser bundle ID: com.google.chrome.beta

   Verified state:

   • The extension is installed, registered, and enabled in Chrome Beta's Default profile.
   • The app's bundled browser detector reports the default browser as unknown app (com.google.chrome.beta) and inspects the stable Chrome profile tree instead.
   • The app logs record isExtensionInstalled=false even though the extension is enabled in Chrome Beta.
   • The native host manifest exists and validates under stable Chrome:
     ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json
   • The corresponding Chrome Beta manifest is not created:
     ~/Library/Application Support/Google/Chrome Beta/NativeMessagingHosts/com.openai.codexextension.json
   • No extension-host process starts for Chrome Beta.
   • The extension popup remains Disconnected.
   • Runtime probe fails immediately with: Browser is not available: extension.

   Recovery attempts:

   • Fully restarted the app and Chrome Beta.
   • Reinstalled chrome@openai-bundled from the app UI.
   • Rechecked the Beta profile and native-host registration after reinstall; the Beta manifest is still missing.

   This appears to be a Chrome Beta detection/native-host registration gap rather than a stale browser-use socket problem, since the failure occurs before an extension host is launched.
6. Leask commented on Oct 12, 2026

   

   Leask

   on Oct 12, 2026

   More actions

   Still reproducible on October 12, 2026, with Chrome Beta 156 and desktop 26.1007.30912 / build 20156. Posting with the affected user's explicit authorization. The user asks that the serious impact on normal work be communicated and that this receive a prompt official fix.

   Impact

   The external Chrome Beta integration cannot be used for browser-dependent development and UI verification. The built-in browser also remains unusable for this user after restarting, with separate route evidence reported in #47270. Both browser choices are failing in their normal workflow. I am not treating the IAB route error as proof of the Chrome Beta transport's root cause.

   Verified environment

   • macOS 27.2 (26B5101f), Apple Silicon / arm64.
   • ChatGPT desktop / Codex: 26.1007.30912, build 20156, bundle com.openai.codex.
   • Google Chrome Beta: 156.0.8078.12, installed and running.
   • Default HTTP/HTTPS browser bundle reported by the official diagnostics: com.google.chrome.beta.
   • Official ChatGPT extension version in Beta's selected Default profile: 1.26.901.11451_0.
   • Extension installed, registered, enabled; no disable reasons reported by the official helper.

   Fresh diagnostic results

   The official diagnostic scripts were used read-only. For the Beta-specific checks, only the documented temporary target overrides were set for the individual helper processes; no persistent configuration was changed.

   Check	Actual result
   Chrome Beta application/process metadata	Installed and running, version 156.0.8078.12.
   installed-browsers.js --json	Default browser bundle is com.google.chrome.beta, but its name/path/version are unresolved and installed_browsers is empty.
   chrome-is-running.js --browser chrome --json	Reports running: false, despite the running Beta main process.
   Default check-extension-installed.js --browser chrome --json	Fails with EPERM while scanning the standard Chrome directory.
   Same official extension helper with CODEX_CHROMIUM_USER_DATA_DIR targeting the actual Beta root	Exit 0; selected Default profile has installed: true, registered: true, enabled: true, no disable reasons.
   Official native-host helper with CODEX_CHROMIUM_NATIVE_HOST_MANIFEST_PATH targeting the Beta manifest	Fails because the expected Beta manifest is absent.
   Direct filesystem metadata check of the Beta native-host path	NativeMessagingHosts directory exists, but com.openai.codexextension.json returns ENOENT.

   The generic expected Beta registration path is:

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

   The installed extension-ids.json diagnostics configuration still lists only:

   • Application: Google Chrome.app.
   • Bundle ID: com.google.Chrome.
   • Process names: Google Chrome, Google Chrome Helper.
   • Default profile root: Library/Application Support/Google/Chrome.
   • Native-messaging destinations covering standard Chrome/Chromium/Chrome for Testing, with no Chrome Beta destination.

   This reproduces the channel-discovery mismatch described earlier in this issue on a substantially newer build. The enabled Beta extension is not the missing component; the required Beta native-host registration is concretely absent.

   Desktop plugin/setup state

   A separate official plugin/list metadata reader reports browser@openai-bundled installed/enabled, but chrome@openai-bundled not installed/not enabled in the persistent local catalog. That standalone reader does not expose the foreground conversation's effective runtime overrides. This is relevant setup context, not evidence that a successful Chrome-plugin installation subsequently lost its registration.

   We did not install or reinstall the desktop Chrome plugin during this diagnostic pass. Consequently, the missing Beta manifest is a verified current connection blocker, while an installer failure after a successful fresh installation has not been independently reproduced here. The Beta application/profile discovery mismatch is independently demonstrated by the default helper results and the installed diagnostics configuration. Please distinguish incomplete setup from channel-detection or registration failures, and make the supported Beta setup/recovery path explicit.

   Separate permission finding and limits

   The standard Chrome root produces EPERM: operation not permitted, scandir in both the official helper and desktop extension-detection logs. Its exact OS security cause has not been isolated. I am not assuming that this denial explains every failure, nor claiming the inaccessible standard Chrome manifest is missing: the confirmed ENOENT above is specifically for the accessible Beta destination.

   No native host was manually copied/installed, no app code was patched, and no browser security permission or persistent override was changed. Registration remains an official installer/reconciliation responsibility. The effects of repairing that registration on actual tab/page operations have therefore not been tested in this pass.

   Proposed official fix and regression coverage

   1. Resolve the selected/running Chrome channel consistently by application/bundle identity, including com.google.Chrome.beta, instead of relying solely on standard Chrome names and directories.
   2. Use that same channel identity for extension discovery, the selected profile, the app-managed native-host registration destination, and launch/recovery behavior.
   3. Register/validate the native host for the selected installed channel through the official installer, including after app updates and plugin reconciliation.
   4. Report the actual selected channel/profile and live extension handshake in settings; distinguish an unrecognized channel, missing registration, permission denial, and transport timeout.
   5. Isolate errors in unused optional browser roots. A denied standard Chrome directory should not prevent an accessible Beta integration or working IAB session from initializing.

   Please add regression cases for Beta-only installations; stable and Beta side-by-side with the extension only in Beta; multiple profiles; a missing/denied unused standard Chrome root; app updates with existing registration; and actual tab enumeration plus a harmless page read/action/readback. Installation checks alone are insufficient to demonstrate recovery.

   Please prioritize this long-standing, workflow-blocking compatibility gap and provide an engineering owner, a supported recovery path, and the first fixed build when available. Further restart-only guidance cannot create the absent Beta registration or correct the demonstrated channel mismatch.

   This public report omits account details, local usernames and host/project names, conversation/tab IDs, private URLs/content, credentials, screenshots, and raw logs.