Windows Codex App: Chrome computer control intermittently times out after creating Chrome task group

Open 💬 2 comments Opened May 9, 2026 by Lesterffx
💡 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.506.31421 ; Codex CLI: 0.130.0-alpha.5 Chrome plugin: chrome@openai-bundled 0.1.7 Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Chrome computer control in Codex App is intermittent on Windows.

After the Codex App update, Chrome control improved partially:

  • The Chrome plugin can create a red Chrome task group, e.g. "Lichess AI practice".
  • One browser.user.openTabs() call succeeded and returned existing Chrome tabs.
  • Chrome native messaging host is launched.
  • Chrome Extension is installed and enabled.

However, subsequent browser operations often hang until timeout:

  • browser.user.openTabs() later times out.
  • tab.goto(...) times out.
  • tab.cua.keypress/type/click attempts time out.
  • The browser tab/group is visible in Chrome, but Codex does not reliably receive responses from the Chrome control channel.

This prevents reliable automation even on a simple Lichess human-vs-Stockfish practice game.

What steps can reproduce the bug?

  1. On Windows, install/enable the Codex Chrome Extension.
  2. In Codex App, enable Computer Control > Google Chrome.
  3. Set Chrome permissions to always allow approval/history.
  4. Open a new Chrome window with Profile 1.
  5. Ask Codex:

[@chrome](plugin://chrome@openai-bundled) open a chess website and automate playing chess

  1. Codex creates a red Chrome task group such as "Lichess AI practice".
  2. Try lightweight calls such as browser.user.openTabs().
  3. Try navigating with tab.goto("https://lichess.org") or using CUA click/type actions.

Uploaded thread:
c95453de-6c01-4ab5-834f-c09770652789

What is the expected behavior?

Once Chrome is connected and the Codex task group is created, browser.user.openTabs(), tab.goto(), and CUA/playwright actions should reliably return or fail with an actionable error.

Additional information

Network is not the issue:

Chrome/extension checks:

  • Chrome is running.
  • Codex Chrome Extension is installed, registered, and enabled.
  • Native host manifest check passes.
  • extension-host.exe is launched by Chrome via chrome.nativeMessaging pipes.

Important behavior change after update:

  • Old cached browser-client path reported:

"browser-client is not trusted. Load browser-client from the openai-bundled marketplace directory."

  • Using the updated trusted path works:

C:\Users\Administrator\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\scripts\browser-client.mjs

  • But after partial success, Chrome control still becomes intermittent and hangs.

Current workaround:

  • I can manually use Chrome and send screenshots.
  • Codex can recommend chess moves from screenshots.
  • Codex cannot reliably automate Chrome clicks/moves.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21670
  • #21698
  • #21765
  • #21691
  • #21851

Powered by Codex Action

Ace-Kelly · 3 months ago

Adding another Windows data point from a local repro on a different machine.

Environment:

  • Windows 11 Home Chinese, 10.0.26200, x64
  • Codex App package: 26.506.3741.0
  • VS Code Codex extension: openai.chatgpt@26.506.31421
  • Bundled Codex CLI: codex-cli 0.130.0-alpha.5
  • Codex Chrome Extension: 1.1.4
  • Chrome extension/native-host checks pass: Chrome is running, extension installed/enabled, native host manifest exists and has the expected origin.

Observed behavior:

  • Loading the old cached Chrome client path fails immediately with the trust error:
%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\0.1.7\scripts\browser-client.mjs
privileged native pipe bridge is not available; browser-client is not trusted. Load browser-client from the openai-bundled marketplace directory.
  • The updated bundled-marketplace path exists on this machine and succeeds:
%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\scripts\browser-client.mjs

With that path, setupAtlasRuntime({ globals: globalThis }) succeeds, agent.browsers.list() returns two Chrome extension backends plus Codex In-app Browser, and a smoke test can create a new Chrome tab, navigate to https://example.com/, read title Example Domain, and close the tab.

So this looks like at least two separate states on Windows:

  1. Old cached chrome/0.1.7 path is still present but no longer trusted by the current runtime.
  2. The newer %USERPROFILE%\.codex\.tmp\bundled-marketplaces\...\plugins\chrome\scripts\browser-client.mjs path is trusted and works for a basic smoke test.

This may be related to stale docs/instructions or stale plugin path selection after updates. It would help if the Chrome skill/check scripts pointed agents at the trusted bundled-marketplace path, or if the old cached path failed with a clearer "use this path instead" diagnostic.