Windows: Chrome browser backend missing (only 'iab' available despite extension and native host working) #30688

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   browser

   on Jun 30, 2026
2. github-actions commented on Jun 30, 2026

   

   github-actionsBot

   on Jun 30, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Chrome bridge backend unavailable on macOS despite healthy Chrome extension/native host #29389
   • Chrome plugin cannot connect after reinstall/restart #29999
   • Chrome plugin remains disconnected and @Chrome tool is not exposedThis blocks my main use case. I need the Chrome plugin to reliably control signed-in Chrome pages before each task, including reading page content, clicking, filtering, and taking screenshots. Falling back to Windows window-title reading is not sufficient.blocks my main use case”，让 #30227
   • Chrome plugin connection fails with missing-code-signing-identity #30155
   • Browswer/Chrome Plugin is not working with VSCode Ext #30535

   Powered by Codex Action
3. zemeng5208 commented on Aug 16, 2026

   

   zemeng5208

   on Aug 16, 2026 – with ChatGPT Codex Connector

   More actions

   I maintain WinBridge Recovery, an independent Windows recovery/diagnostic project for Codex Desktop plugin/runtime state.

   This is a particularly useful case because the Chrome-side checks are already healthy: the extension is installed, connectNative("com.openai.codexextension") succeeds, the Native Messaging host is reachable, and extension-host.exe is running — yet the Codex browser runtime exposes only iab.

   On Windows, WinBridge can verify the next local layers that are easy to miss when the extension itself looks fine: the active Codex home, current Store/AppX package generation, bundled marketplace contents, chrome@openai-bundled cache/version/latest, .plugin-appserver/runtime files, Native Host manifest/registry/v2 metadata, and paths such as browserClientPath, codexCliPath, nodePath, nodeReplPath, and resourcesPath. It rebuilds only user-owned state from the installed official package when those layers are stale or split, with verification and rollback.

   If all of those local layers are current and internally consistent but agent.browsers.list() still exposes only iab, I would treat that as strong evidence of an upstream session/backend-provisioning problem rather than repeatedly reinstalling Chrome or rewriting the manifest. WinBridge does not manufacture a privileged browser backend or bypass policy.

   If anyone with this exact symptom tests it, please report either success or failure here so the boundary can be documented: zemeng5208/winbridge-recovery#4