## Summary On Windows, Codex Desktop (Microsoft Store) cannot use the Chrome backend. The browser plugin reports only the `iab` backend even though the Chrome extension, Native Messaging, and extension host are all working. ## Environment - OS: Windows 11 - Codex Desktop: Microsoft Store build 26.623.9142.0 - Chrome extension: 1.1.5 ## Expected Available browser backends should include the Chrome extension backend (e.g. `extension`), allowing Chrome control. ## Actual Prompting: `Use the brow

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #29389 - #29999 - #30227 - #30155 - #30535 *Powered by [Codex Action](https://github.com/openai/codex-action)*

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

Open 💬 2 comments Opened Jun 30, 2026 by bin26

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, Codex Desktop (Microsoft Store) cannot use the Chrome backend. The browser plugin reports only the iab backend even though the Chrome extension, Native Messaging, and extension host are all working.

Environment

OS: Windows 11
Codex Desktop: Microsoft Store build 26.623.9142.0
Chrome extension: 1.1.5

Expected

Available browser backends should include the Chrome extension backend (e.g. extension), allowing Chrome control.

Actual

Prompting:
Use the browser plugin and tell me all available browser backends.
returns only:

iab — Codex In-app Browser

The Chrome backend is absent.

Diagnostics performed

Chrome extension installed and enabled.
Service Worker running.
chrome.runtime.connectNative("com.openai.codexextension") succeeds in DevTools.
Native Messaging host registered and reachable.
extension-host.exe is running.
Codex Browser plugin still reports only iab.

Result

Chrome cannot be controlled from Codex even though the extension and native messaging appear healthy. This appears to be a runtime/backend registration issue rather than an installation problem.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

#29389
#29999
#30227
#30155
#30535

Powered by Codex Action

zemeng5208 · 12 days ago

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: https://github.com/zemeng5208/winbridge-recovery/issues/4