Codex Chrome plugin shows Connected on Windows, but Codex cannot control Chrome and initialization times out

I am seeing what looks like the same Chrome plugin failure on Windows.

Related issue:

• #21890: Chrome plugin connection times out despite extension showing Connected

Environment

• OS: Windows
• Codex Desktop on Windows
• Chrome plugin: chrome@openai-bundled 0.1.7
• Codex Chrome Extension version: 1.1.4 / 1.1.4_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome profile: Default
• Native host name: com.openai.codexextension
• Codex runtime user: WIN-0H28B45NIHJ\CodexSandboxOffline

Diagnostics

The extension and native host appear to be installed and connected:

• Native host registry key exists and passes check:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

• Native host manifest exists:

C:\Users\Administrator\AppData\Local\OpenAI\extension\com.openai.codexextension.json

• Manifest points to:

C:\Users\Administrator\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

• Chrome profile permissions were fixed so CodexSandboxOffline can read:

C:\Users\Administrator\AppData\Local\Google\Chrome\User Data

• Extension check reports:
• installed=true
• registered=true
• enabled=true
• disabled=false

• Chrome extension DevTools storage reports:
• NATIVE_HOST_STATUS.state = "connected"
• hostName = "com.openai.codexextension"
• reconnectAttempt = 0

• extension-host.exe is running.

Failure

Even though the extension reports that the native host is connected:

• agent.browsers.list() can see the Chrome backend.
• agent.browsers.get(Chrome extension backend) times out indefinitely.
• browser.user.openTabs() cannot be reached because backend acquisition hangs.

I have already tried:

• Restarting Windows
• Restarting Chrome
• Restarting Codex
• Restarting extension-host.exe
• Toggling the Chrome extension
• Toggling the Codex Chrome skill
• Reinstalling the Codex Chrome plugin

None of these fixed the issue.

Conclusion

This does not look like a registry, Chrome profile permission, or extension installation problem.

The Chrome extension and native host appear to connect successfully, but Codex Desktop still cannot acquire the Chrome extension backend. It looks more like a Codex Desktop / Chrome plugin runtime issue.

Adding another Windows reproduction from Codex Desktop.

Environment:

• Windows Codex Desktop package: OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0
• Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome extension version: 1.1.4_0
• Chrome plugin cache path: %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.519.21041

Observed behavior:

• Mentioning @chrome is recognized by Codex, but the browser-control / node_repl tools are not exposed to the conversation.
• Tool discovery after @chrome only returns unrelated tools such as GitHub/Canva, not the Chrome browser-client execution tool.
• As a result, Codex cannot actually open/control Chrome tabs via the Chrome plugin.

Diagnostics already checked:

• Chrome is running.
• Codex Chrome Extension is installed and enabled in the Chrome Default profile.
• Native messaging host is registered at HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension.
• Manifest exists at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json.
• Manifest has the expected host name and allowed origin: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/.
• extension-host.exe is running from the Chrome plugin cache path.
• Running the plugin diagnostic scripts with a working Node reports extension installed/enabled and native host manifest correct.

Additional note:

• The Store-packaged Codex node.exe under C:\Program Files\WindowsApps\...\app\resources\node.exe returned Access is denied when invoked directly from PowerShell, while an alternate Codex runtime Node under %USERPROFILE%\.cache\codex-runtimes\...\node.exe works. Prepending that working Node to the user PATH made node -v succeed, but @chrome still did not expose the Chrome browser-control tools.

Recovery attempts that did not fix it:

• Windows app Repair and Reset for Codex.
• Removing/reinstalling the Chrome plugin.
• Closing Chrome and stopping extension-host.exe before reinstalling the plugin.
• Starting a fresh Codex conversation after reinstalling.

Current conclusion: local Chrome extension and native host appear healthy, but Codex Desktop plugin/tool routing is not exposing the Chrome browser-client/node_repl execution tools to the conversation after @chrome.

I saw a similar Windows pattern: the Chrome extension could work right after install, but later Codex would no longer expose/control Chrome even though the extension popup looked connected.

The workaround that consistently helped locally was:

1. Fully quit Codex.
2. Fully quit Chrome.
3. In Task Manager, make sure chrome.exe and extension-host.exe are gone.
4. Start Codex first and wait until the Chrome/Browser plugins are visible.
5. Start Chrome after that.

I wrote a short troubleshooting guide here:
https://treasure-lung-30f.notion.site/Codex-Chrome-Extension-on-Windows-Setup-and-Troubleshooting-Guide-36830cb58ab8816eb0a4e8b93153a94c

Not an official fix, just a user-tested workaround in case it saves someone time.

I can reproduce a closely related Windows Chrome plugin failure in Codex Desktop.

Environment / local state:

• Windows, Codex Desktop with chrome@openai-bundled enabled.
• Chrome plugin cache version: 26.519.41501.
• Codex Chrome Extension installed and enabled in the selected Chrome profile (Profile 3), extension version 1.1.5_0.
• Extension id: hehggadaopoacecdllhhajmbjkdcmajg.
• Native host manifest exists at %USERPROFILE%\AppData\Local\OpenAI\extension\com.openai.codexextension.json and points to %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe.
• reg query HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension shows the default value pointing to that manifest.

Observed behavior:

• When Codex tries to communicate with an existing Chrome tab, Chrome displays the banner: "Codex" started debugging this browser.
• The controlled tab then gets stuck on a black/loading state with a spinner. This is reproducible even with a new Codex session.
• The issue can create duplicate tabs for the same ChatGPT conversation.
• Restarting extension-host.exe and resetting the Node REPL/browser runtime allows browser.user.openTabs() to work again temporarily, but the stuck tab remains associated with an old browser session.

Concrete errors observed:

native pipe is closed

and then, when trying to reclaim the stuck tab:

Tab 723868938 is already part of browser session 019e5481-33dd-7d32-82ef-d1f5cdc09bb9

The current session can list tabs and can claim some duplicate tabs, but one stuck tab remains permanently owned by the previous browser session. Calling browser.tabs.finalize({ keep: [] }) from the current session does not release that old tab because browser.tabs.list() is empty for the current session.

One additional oddity: direct PowerShell/.NET registry reads show the native messaging host key exists and has the correct default value, but the plugin diagnostic script still reported:

{
  "registryManifestPath": null,
  "correct": false,
  "problem": "Windows native host registry key does not exist: HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.openai.codexextension"
}

So this looks like a stale browser-session ownership / native pipe lifecycle bug, plus possibly an inconsistent Windows registry read in check-native-host-manifest.js.

Closing as a duplicate of #21698.

Disclosure: I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This thread is a good boundary case for a local repair tool. Some reproductions show the Chrome extension, registry/manifest and extension-host.exe all present — in one case the Chrome backend is even visible — but backend acquisition or the browser-control/node_repl tool route still hangs or disappears.

WinBridge checks whether that apparently healthy surface is hiding mixed Windows state: active CODEX_HOME, bundled marketplace, concrete plugin cache/latest, native-host manifest + registry/v2 state, and cua_node/node_repl runtime references are compared against the official installed package together. Reinstalling just the Chrome plugin does not necessarily repair all of those layers.

But if those local layers validate and the host really is connected while agent.browsers.get("extension") still times out, WinBridge should not claim to fix a Desktop routing/backend handshake. It reports that boundary as upstream rather than repeatedly rewriting a healthy native-host registration.

If anyone with this exact “Connected / host running / acquisition still hangs” state tries WinBridge, please leave the result at https://github.com/zemeng5208/winbridge-recovery/issues/4. ✅ fixed, 🟡 local inconsistencies repaired but timeout remained, and ❌ no change are all useful field results.