You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex Desktop Chrome plugin unavailable even though extension and native host are installed #23322
Chrome plugin should be available in this context. @chrome should appear in the composer, and Codex Desktop should be able to connect to the Chrome extension / external Chrome backend.
Additional information
Please check whether this Windows build/account has browser_use_external disabled, or whether the Desktop app/plugin/runtime versions are mismatched.
The interesting part of this report is the split between “installed/healthy on disk” and “unavailable in this context”: the extension is enabled, the native-host check passes, and extension-host.exe is running, but Desktop starts only the iab backend and @Chrome is absent.
WinBridge checks for version/source drift across the active Codex home, bundled marketplace, plugin cache/latest, native-host manifest + registry state, and the cua_node/node_repl runtime rather than assuming a successful native-host check means the whole integration is coherent. That is useful when an app update leaves different layers on different plugin/runtime generations.
If everything local is already coherent and this account/build is simply not being provisioned with browser_use_external, WinBridge cannot and should not bypass that feature/context gating. It should return an upstream/availability diagnosis instead of changing healthy files.
If anyone still has this exact “native host correct + only iab + @chrome unavailable” state and tries WinBridge, please report the outcome at zemeng5208/winbridge-recovery#4. I am collecting successful, partial, and failed results equally.
Activity
github-actions commentedon May 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zemeng5208 commentedon Aug 14, 2026
I maintain WinBridge Recovery, an independent Windows Codex Desktop recovery/diagnostic tool: https://github.com/zemeng5208/winbridge-recovery
The interesting part of this report is the split between “installed/healthy on disk” and “unavailable in this context”: the extension is enabled, the native-host check passes, and
extension-host.exeis running, but Desktop starts only theiabbackend and@Chromeis absent.WinBridge checks for version/source drift across the active Codex home, bundled marketplace, plugin cache/
latest, native-host manifest + registry state, and thecua_node/node_replruntime rather than assuming a successful native-host check means the whole integration is coherent. That is useful when an app update leaves different layers on different plugin/runtime generations.If everything local is already coherent and this account/build is simply not being provisioned with
browser_use_external, WinBridge cannot and should not bypass that feature/context gating. It should return an upstream/availability diagnosis instead of changing healthy files.If anyone still has this exact “native host correct + only iab + @chrome unavailable” state and tries WinBridge, please report the outcome at zemeng5208/winbridge-recovery#4. I am collecting successful, partial, and failed results equally.