Windows Codex Desktop cannot control discovered Chrome tab and Computer Use bridge is unavailable

Resolved 💬 2 comments Opened Jun 3, 2026 by Divine-Shadow Closed Jun 3, 2026

Summary

On Windows Codex Desktop, a user-authorized browser task could not proceed because both available control surfaces failed in confusing ways:

  • The Chrome extension backend could list existing Chrome tabs, including the target Miro settings tabs, but the documented tab-control path could not attach to those tabs.
  • The Chrome browser backend then rejected opening https://miro.com in a newly controlled tab due to enterprise browser security policy. That policy block may be intentional, but it left no safe in-product path for a user-authorized subscription-management task.
  • The Computer Use fallback could not start because the native bridge reported Computer Use native pipe path is unavailable, even after a fresh session reset and the recommended retry.

Environment

  • Host OS: Windows 11 x64.
  • App surface: Codex Desktop.
  • Browser plugin bundle observed locally: openai-bundled/browser/26.527.60818.
  • Computer Use plugin bundle observed locally: openai-bundled/computer-use/26.527.60818.
  • Chrome browser backend: discovered as a Chrome extension backend for Chrome profile Person 2.
  • Date observed: 2026-06-03.

User Task

The user asked Codex to manipulate the active Chrome tab and help cancel a Miro subscription. This is a user-authorized account/billing-management task. Codex correctly needed to stop before any final subscription-cancel action and ask for action-time confirmation.

Observed Behavior

Chrome Extension Backend

Codex listed available browser backends and found a Chrome extension backend plus the Codex in-app browser. The Chrome backend's browser.user.openTabs() returned open Chrome tabs, including Miro settings and dashboard tabs.

However, attempts to control the already-open tab failed:

browser.tabs.selected() -> No active tab found
browser.tabs.get("<miro-tab-id>") -> tabs.get could not find tab id "<miro-tab-id>". Existing tabs: none

This was confusing because the same backend had just returned those tab IDs through browser.user.openTabs().

Opening a new controllable tab to the same Miro URL then failed with:

Browser Use rejected this action due to browser security policy.
Reason: Browser Use cannot access https://miro.com because enterprise network policy blocks it.

The policy rejection explicitly prohibited workaround routes.

Computer Use

The user then explicitly asked Codex to try Computer Use. A fresh Computer Use setup and sky.list_apps() failed with:

Computer Use native pipe path is unavailable

After a reset and the documented single retry, the same error repeated.

Expected Behavior

  • If Chrome tab discovery returns user tabs, there should be a documented and working way to claim or control a selected discovered tab, or the returned IDs should clearly be marked as discovery-only.
  • If a domain is blocked by browser security policy, Codex should still provide a clear remediation path for user-approved tasks, such as explaining that the user must complete the task manually or that an admin policy controls the block.
  • Computer Use should either connect to the native bridge on Windows or return an actionable diagnostic that distinguishes "helper not installed", "helper crashed", "native host not registered", "permission unavailable", and "unsupported session".

Actual Behavior

  • Chrome tab discovery and tab control appeared internally inconsistent: discovered tab IDs could not be controlled with the documented tabs.get path.
  • The browser security policy block was explicit and non-bypassable, but the surrounding product behavior made it look like alternative automation paths might exist.
  • Computer Use failed before app enumeration with a non-actionable native pipe error, leaving no way to inspect or repair the Windows control bridge from the documented workflow.

Impact

The user had to abandon automation for a routine account-management task even though:

  • The target site was already open in Chrome.
  • The user explicitly authorized assistance.
  • Codex could identify the relevant Miro tabs.
  • A desktop-control plugin was installed locally.

The failure mode also creates unnecessary support friction because the operator cannot tell whether the problem is policy, stale Chrome extension/native-host registration, Computer Use helper startup, or a documentation mismatch.

Suggested Fixes

  1. Document and expose the intended "claim existing Chrome tab" path in the browser skill/API reference, or make browser.tabs.get() work with IDs returned by browser.user.openTabs().
  2. Improve the policy-block message for user-facing flows so it gives an actionable next step without implying that another automation backend should be tried.
  3. Improve Computer Use startup diagnostics around Computer Use native pipe path is unavailable.
  4. Add a lightweight health check for the Computer Use native bridge that reports whether the helper is installed, reachable, and compatible with the current Codex Desktop build.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗