›_ Codex Issues
Codex Issues / #21916

Windows: Codex Chrome plugin shows "connected" in the UI, but browser automation cannot actually connect

Resolved 💬 4 comments Opened May 9, 2026 by gouzigouzi Closed Jun 12, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.430.10722

What subscription do you have?

Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

I am testing the new Codex Chrome plugin.

Observed behavior on Windows:

  • Codex Settings / Computer Use shows Google Chrome as connected
  • The Chrome Web Store extension can be installed successfully
  • However, when I ask Codex to use @chrome for a browser task, the browser automation connection still fails
  • Codex times out when trying to connect to the browser
  • The UI state and the runtime state appear inconsistent

In my case, Codex was able to recognize a configured browser connection in the UI, but actual automation did not work.

I also noticed an additional point of confusion:

  • The extension page indicates that the extension can be installed in Microsoft Edge
  • But the current @chrome automation path appears to expect Google Chrome specifically
  • So it is unclear whether Edge is officially supported for runtime automation, or only for extension installation

What steps can reproduce the bug?

  1. Install Codex Desktop on Windows
  2. Install the new Codex Chrome plugin
  3. Install the Codex Chrome Extension from the Chrome Web Store
  4. Open Codex Settings / Computer Use and confirm that Google Chrome shows as connected
  5. Start a chat and ask Codex to do a browser task using @chrome
  • Example: [@chrome] please open GitHub Trending
  1. Observe that Codex cannot actually connect to the browser runtime and the request fails / times out

What is the expected behavior?

Expected behavior

If the UI shows Google Chrome as connected, browser automation should work end-to-end.

At minimum:

  • Codex should be able to complete @chrome browser tasks successfully, or
  • the UI should clearly indicate that the browser is only partially configured and not actually ready for runtime automation

Actual behavior

The UI shows a successful browser connection, but runtime browser automation still fails.

This makes it look like setup is complete when it is not.

Additional information

A few observations from troubleshooting:

  • On macOS, the same plugin flow works
  • On Windows, the issue seems to be somewhere between the extension/UI layer and the runtime automation handshake
  • In my testing, Codex kept timing out when trying to establish the browser automation connection
  • I also saw signals suggesting that the native host / browser profile detection on Windows may be part of the problem, but I cannot confirm whether that is the root cause

One concrete example from the agent-side diagnostics was that the connection flow timed out even though the UI still showed the browser as connected.

It may help if the app exposes more precise status states such as:

  • connected in UI only
  • extension installed
  • native host registered
  • runtime automation ready

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21878
  • #21698
  • #21765
  • #21890
  • #21908

Powered by Codex Action

gouzigouzi · 3 months ago

I reviewed the potential duplicates. This looks related to #21698, #21765, #21878, #21890, and possibly #21908, because the visible symptom is the same: the Chrome plugin / Computer Use UI indicates a connected browser, but @chrome browser automation cannot establish a usable runtime connection and times out.

There is one difference in my case that may be useful for triage:

  • Codex Settings / Computer Use shows Google Chrome as Connected
  • However, agent-side diagnostics did not agree with that ready state
  • check-extension-installed.js --json reported that the default Chrome user data directory did not exist:

..\Google\Chrome\User Data

  • check-native-host-manifest.js --json reported that the Windows native host registry key was missing:

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

  • The browser automation connection then timed out while trying to initialize/list tabs

So this may be the same Windows Chrome plugin connection failure class, but my case also shows a UI/status mismatch: the app reports the browser as connected even when the native host / Chrome profile checks suggest the runtime automation path is not actually ready.

Another possible source of confusion: I had installed the extension in Microsoft Edge, and the Chrome Web Store page indicates that the extension can be used with Edge. However, the current @chrome automation path appears to validate and connect through Google Chrome-specific profile/native-host locations. It would be helpful to clarify whether Edge is supported only for installing the extension, or whether Edge is expected to work for Codex runtime browser automation as well.

If maintainers prefer to track all Windows Chrome plugin timeout cases in one issue, I can close this as a duplicate. I wanted to add this diagnostic difference first because my local checks do not match the "all diagnostics pass but runtime times out" cases exactly.

gouzigouzi · 3 months ago

I accidentally closed this issue while reviewing the duplicate suggestions.

I do not have permission to reopen it from the GitHub UI. Could a maintainer please reopen it if this should remain tracked separately?

If this is considered a duplicate, I am also fine with keeping it closed, but I would appreciate confirmation on which issue should be treated as the canonical one.

ax-openai · 2 months ago

Closing as a duplicate of #21698.