Computer Use cannot determine Chrome URL on Windows, even on chrome://newtab/

Open 💬 25 comments Opened May 30, 2026 by livlojp

💡 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.527.31326

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?

When using Computer Use in Codex Desktop on Windows to operate Google Chrome, the Chrome window is detected successfully, but Computer Use stops during the screen-state acquisition step with the following message:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

This reproduces even when Chrome is only showing chrome://newtab/ or about:blank, before any click, input, or external URL navigation.

Computer Use can detect the Chrome app and window title, for example:

{
  "success": true,
  "stage": "computer_use_list_apps",
  "pluginVersion": "openai-bundled/computer-use/26.527.31326",
  "chromeCandidateCount": 6,
  "chromeCandidates": [
    {
      "id": "Chrome",
      "displayName": "Google Chrome",
      "isRunning": true,
      "windows": [
        {
          "app": "Chrome",
          "id": 393446,
          "title": "about:blank - Google Chrome"
        }
      ]
    }
  ]
}

But when attempting to acquire the Chrome window state, it fails:

{
  "success": false,
  "stage": "computer_use_chrome_get_window_state_about_blank",
  "error": "Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended."
}

The issue appears specific to Computer Use targeting Chrome on Windows. Computer Use successfully operates other local Windows apps such as Calculator and Notepad.

There may also be a related Chrome extension / Codex app launch issue. After reinstalling the Codex Chrome Extension and rebooting Windows, the extension popup shows Connected, but clicking the extension settings gear opens an Electron error:

Error launching app

Unable to find Electron app at
C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\...\google-chrome

Cannot find module
'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\...\google-chrome'

In the same state, the Chrome plugin backend was not available from Codex and reported:

Browser is not available: extension

I cannot confirm whether this Electron/module error is the direct root cause, but it seems related because the Chrome extension says it is connected while Codex cannot use the Chrome extension backend, and Computer Use cannot determine the current Chrome URL.

What steps can reproduce the bug?

Use Codex Desktop on Windows with Computer Use enabled.
Install and enable the Codex Chrome Extension.
Open Google Chrome.
Keep Chrome on chrome://newtab/ or about:blank.
Ask Codex to use Computer Use to inspect or operate the Chrome window.
Computer Use detects the Chrome app/window successfully.
Attempt to acquire the Chrome screen/window state through Computer Use.

Expected reproduction result:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

Baseline checks that succeeded:

Computer Use + Windows Calculator: success
Computer Use + Notepad: success
Computer Use + Chrome app/window detection: success

Failure:

Computer Use + Chrome screen-state acquisition: failure

Versions observed:

Computer Use plugin: openai-bundled/computer-use/26.527.31326
Chrome plugin: openai-bundled/chrome/26.527.31326
Browser plugin: openai-bundled/browser/26.527.31326
Codex Chrome Extension: 1.1.5
Chrome: 148.0.7778.217

What is the expected behavior?

Computer Use should be able to determine the current URL for a Chrome window on Windows when the tab is on chrome://newtab/ or about:blank, and then continue with the requested browser GUI operation.

If the URL cannot be determined, Computer Use should provide a more specific diagnostic message, such as whether the problem is caused by:

Chrome extension connection failure
Chrome profile mismatch
Native messaging host issue
Windows UI Automation / address bar URL detection failure
inability to map the detected Chrome window to a known Chrome tab

If possible, Computer Use should use the same Chrome extension / Chrome plugin connection information to map the detected Chrome window to the current tab URL.

Additional information

I tried the following before filing this issue:

Retried in multiple Codex threads
Rebooted the PC
Reinstalled the Codex Chrome Extension
Verified that the extension is enabled
Verified that the extension popup shows Connected
Verified that Chrome is detected by Computer Use
Verified that Computer Use works with non-browser Windows apps

The extension settings gear produces this error, which may be related:

Error launching app

Unable to find Electron app at
C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\...\google-chrome

Cannot find module
'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\...\google-chrome'

The Chrome extension UI says Connected, but Codex reported:

Browser is not available: extension

This may indicate that the extension UI, the Chrome plugin backend, and Computer Use's Chrome URL safety check are not all using the same working connection path.

View original on GitHub ↗

25 Comments

github-actions[bot] contributor · 2 months ago

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

#24838
#24969

Powered by Codex Action

livlojp · 2 months ago

I reviewed the potential duplicates. Some appear related, but this issue may not be a complete duplicate.

Related issues:

#24838 looks closely related to the Chrome backend side: the Chrome extension/native host appear installed, but Codex only exposes the in-app browser and agent.browsers.get("extension") fails with Browser is not available: extension.
#25157 / #25188 / #25203 look related to the Windows MSIX/Electron deep-link or app-activation issue. My extension settings gear error has a similar shape: Codex tries to open a WindowsApps path and reports Unable to find Electron app / Cannot find module, but the path ends with ...\google-chrome rather than an OAuth callback.
#21741 may be related to Chrome extension backend launch failures. It mentions a local COMSPEC workaround, but I have not yet verified whether that applies to this machine.

I am keeping this issue open for now because it also includes a separate Computer Use failure: Computer Use detects the Chrome window successfully, but stops during Chrome screen-state acquisition because it cannot determine the current browser URL, even on chrome://newtab/ or about:blank.

If maintainers confirm that this is covered by one of the existing issues, I can close this as a duplicate.

livlojp · 2 months ago

Update: retested with Codex App 26.601.20914

I retested after updating the Windows Codex App.

Environment:

Windows Codex App: 26.601.20914 / released 2026-06-03
Computer Use plugin: openai-bundled/computer-use/26.601.20914
Chrome: 148.0.7778.217
Codex Chrome Extension: 1.1.5_0
Native Host / registry / allowed-origin diagnostics: passed
Codex settings: Full access
config.toml: [windows] sandbox = "elevated"
Codex App was restarted before the retest

What improved:

The Chrome extension settings / Open Settings path appears improved.
Pressing the Chrome extension settings button no longer opens the previous Electron error.
It now opens the Codex “Computer Use” settings screen as expected.
The settings screen shows Google Chrome as connected and exposes the “Manage” button.

What still fails:

Computer Use initialization succeeds.
list_apps / list_windows succeeds.
Chrome is detected successfully.
The detected Chrome window title was localized Japanese: 新しいタブ - Google Chrome

(equivalent to New Tab - Google Chrome).

However, when attempting to acquire the Chrome window state, Computer Use still stops with the original #25271 error:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.

So in 26.601.20914, the Chrome extension settings path appears improved, but the core #25271 failure still reproduces once Computer Use reaches Chrome window-state acquisition.

Additional observation:
During earlier retesting, after changing permission/sandbox settings and restarting the Codex App multiple times, I also saw a different Computer Use settings state:

Computer Use plugin unavailable

I could not confirm whether that was the same root cause or a separate initialization/state issue, but it may be relevant because it appeared while switching access/sandbox settings and restarting the app.

Arconte112 · 2 months ago

I can reproduce this as well, but with Microsoft Edge rather than Google Chrome.

Environment:

Codex App: 26.601.2237.0 (Microsoft Store package OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0)
Computer Use plugin: openai-bundled/computer-use/26.601.21317
Browser app detected by Computer Use: MSEdge
OS: Microsoft Windows 11 Pro, 10.0.22000, x64

What happened:

Computer Use successfully listed Microsoft Edge as running and detected an open Edge window.
I selected the Edge window and attempted to acquire window state with get_window_state.
Computer Use stopped immediately with the same policy error:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.

So this does not appear to be limited to Chrome; at least on this Windows setup it also reproduces when targeting Edge via Computer Use.

sunxinti · 2 months ago

I am experiencing the same issue on Windows.

Computer Use can open my local page in Edge/Chrome, but then get_window_state fails with:

could not determine the current browser URL on Windows with enough confidence to enforce policy

It seems Codex cannot reliably detect the current browser URL on Windows, so Computer Use is stopped by policy. Is there any workaround or fix?

livlojp · 2 months ago

Additional retest result.

I updated the Codex App to 26.602.30954 and reinstalled Computer Use and the Chrome extension, then retested this issue.

Environment:

Windows Codex App: 26.602.30954 / Released 2026-06-05
Computer Use plugin: openai-bundled/computer-use/26.602.30954
Chrome Extension: 1.1.5
Chrome window: localized Japanese "新しいタブ - Google Chrome" / equivalent to "New Tab - Google Chrome"
Codex App / chat selector: Full access
visible config: sandbox_mode = "danger-full-access", approval_policy = "on-failure"
Native Host / registry / allowed-origin checks: passed

Observations:

Immediately after switching to Full access, before restarting the Codex App, Computer Use initialization failed with "Computer Use native pipe path is unavailable".
After closing the Codex App, ending remaining Codex tasks in Task Manager, and restarting the app, Computer Use initialization succeeded.
In the same existing Codex session, list_apps / list_windows succeeded, and the Chrome window was detected successfully.
So creating a new session does not seem to be the key factor. What seems more important is fully restarting the Codex App after changing the sandbox / access setting so that the setting is actually reflected.
However, during Chrome window state acquisition, equivalent to get_window_state, Computer Use still stopped with the same error as before.

Error:
"Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended."

Conclusion:
In 26.602.30954, the Full access setting propagation / native pipe initialization path may have improved after an app restart.
However, the core #25271 issue still reproduces: Computer Use still cannot determine the current Chrome URL on Windows with enough confidence and stops during browser window-state acquisition.

jsonj3407-source · 2 months ago

Additional reproduction on Windows 11 (Microsoft Edge via Computer Use):

Environment

Codex Desktop with computer-use@openai-bundled 26.602.71036
setupComputerUseRuntime({ globals: globalThis }) succeeds from bundled computer-use-client.mjs
sky.list_apps() succeeds and returns Microsoft Edge (MSEdge) with an open window

Failure
After selecting/activating the Edge window, Computer Use stops during window-state acquisition (get_window_state) with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

Notes

Non-browser apps (Notepad/Calculator) work in the same setup.
External Edge browser automation is blocked at this policy check even on a normal HTTPS page.
Matches the Chrome/Edge behavior already reported in this thread.

Expected
Reliable active-tab URL resolution for Chromium browsers on Windows, or clearer diagnostics when the URL bridge is unavailable.

Happy to run additional diagnostics if maintainers need a specific build matrix.Additional reproduction on Windows 11 (Microsoft Edge via Computer Use):

Environment: Codex Desktop computer-use 26.602.71036; setupComputerUseRuntime + sky.list_apps() OK (MSEdge detected).

Failure: get_window_state stops with "could not determine the current browser URL on Windows with enough confidence to enforce policy."

Non-browser apps work. Normal HTTPS pages still blocked. Same as existing Chrome/Edge reports here.

Expected: reliable Chromium URL resolution on Windows or clearer diagnostics when URL bridge unavailable.

jsonj3407-source · 2 months ago

Additional reproduction on Windows 11 (Microsoft Edge via Computer Use):

Environment

Codex Desktop with computer-use@openai-bundled 26.602.71036
setupComputerUseRuntime({ globals: globalThis }) succeeds from bundled computer-use-client.mjs
sky.list_apps() succeeds and returns Microsoft Edge (MSEdge) with an open window

Failure
After selecting/activating the Edge window, Computer Use stops during window-state acquisition (get_window_state) with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

Notes

Non-browser apps (Notepad/Calculator) work in the same setup.
External Edge browser automation is blocked at this policy check even on normal HTTPS pages.
Matches the Chrome/Edge behavior already reported in this thread.

Expected
Reliable active-tab URL resolution for Chromium browsers on Windows, or clearer diagnostics when the URL bridge is unavailable.

Happy to run additional diagnostics if maintainers need a specific build matrix.

livlojp · 2 months ago

Additional retest result with Codex App 26.609.30741

I updated the Windows Codex App to 26.609.30741 / released 2026-06-12 and attempted to retest this issue.

Environment:

Windows Codex App: 26.609.30741
Windows package: OpenAI.Codex_26.609.3341.0_x64
Computer Use plugin: openai-bundled/computer-use/26.609.30741
Chrome plugin: openai-bundled/chrome/26.609.30741
Chrome: 149.0.7827.104
Codex Chrome Extension: 1.1.5_0, installed and enabled
Native Host / registry / allowed-origin diagnostics: passed
sandbox_mode: "danger-full-access"
approval_policy: "never"
[windows] sandbox: "elevated"

Result:
In this version I could not reach the original #25271 reproduction point.

Computer Use failed during bootstrap before list_apps / list_windows and before Chrome get_window_state could be tested.

Error:

Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js' is not defined by "exports" in C:\Users\<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_modules\@oai\sky\package.json

So for 26.609.30741, I cannot confirm whether the original Windows Chrome URL-confidence failure is fixed or not, because Computer Use now fails earlier during initialization.

Compared with my previous retests, this is a regression in my environment:

Earlier versions could initialize Computer Use and successfully run list_apps / list_windows.
They then failed at Chrome window-state acquisition with the original #25271 URL-confidence error.
In 26.609.30741, Computer Use does not get that far.

Omniloss · 2 months ago

I can reproduce what appears to be the same Windows Computer Use browser URL policy failure on a newer Codex Desktop build, with both Chrome and Edge.

Thread ID: 019ec68c-c427-7051-b058-88d3c01be8ed

Environment:

Codex Desktop app: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Codex process file version: 149.0.7827.54
Windows: Windows 11 Pro, version 10.0.26200, build 26200, 64-bit
Chrome plugin: 26.609.41114
Computer Use plugin: 26.609.41114
@oai/sky: 0.4.10
CUA runtime id: 789504f803e82e2b
Google Chrome: 149.0.7827.115
Microsoft Edge: 149.0.4022.69

Observed behavior:

Computer Use can list browser apps/windows.
sky.list_apps() returns Chrome with a window titled Example Domain - Google Chrome.
Calling sky.get_window_state({ window: chromeWindow, include_screenshot: false, include_text: true }) stops the turn with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.

This reproduces on a simple public HTTPS page, https://example.com/, and the same failure occurs with Microsoft Edge on the same URL.

Additional diagnostics:

Chrome extension install check passes:
extension installed: true
extension enabled: true
extension id: hehggadaopoacecdllhhajmbjkdcmajg
Native host manifest check passes:
manifest exists: true
registry path matches manifest: true
allowed origin matches the Codex Chrome extension: true
Chrome extension/browser-client can read open tabs and sees:

[
  {
    "title": "Example Domain",
    "url": "https://example.com/"
  }
]

Windows UI Automation diagnostics outside Computer Use show that Chrome exposes the page URL:
Omnibox edit value: example.com
RootWebArea document value: https://example.com/
Changing Chrome UI locale from zh-CN to en-US did not help.
Setting Chrome preference omnibox.prevent_url_elisions = true did not help.
Launching Chrome/Edge with --lang=en-US --force-renderer-accessibility did not help.

Assessment:

This looks like a Windows Computer Use native helper/browser URL policy detection path issue, not a Chrome extension disconnect issue. The browser window is targetable, the extension/native-host path is healthy, the extension can read the active tab URL, and UI Automation exposes the URL, but Computer Use still cannot verify the URL with enough confidence. Edge failing the same way suggests the problem affects Chromium-based browser URL detection on Windows in this Codex Desktop build.

FreeZIngMoon11 · 2 months ago

I can reproduce the same issue on Windows with Codex Desktop.

Environment observed:

Computer Use plugin: openai-bundled/computer-use/26.616.51431
Chrome plugin: openai-bundled/chrome/26.616.51431
Browser plugin: openai-bundled/browser/26.616.51431
Target app: external Google Chrome on Windows

Repro notes:

Opened a single Chrome window with a single tab.
Navigated to a normal authenticated HTTPS web app page.
The page was visibly loaded and logged in.
sky.list_apps() detected Chrome and the target window successfully:

{
  "id": "Chrome",
  "windows": [
    {
      "app": "Chrome",
      "id": "<redacted window id>",
      "title": "<redacted web app> - Google Chrome"
    }
  ],
  "displayName": "Google Chrome",
  "isRunning": true
}

Calling sky.get_window_state({ window }) stopped with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.

This still reproduced after closing all other Chrome windows, leaving only one Chrome window and one tab.

In the same Codex session, the Chrome window can be detected, but Computer Use cannot proceed past the browser URL identity check. This looks consistent with the failure described in this issue rather than a site-specific permission problem.

NealW1000 · 2 months ago

I am facing the same issues. On both chrome and Edge.

DokPlay · 1 month ago

I can reproduce the same issue on Windows.

Environment:

Codex app / plugin build: 26.623.70822
Computer Use plugin: openai-bundled/computer-use/26.623.70822
Chrome plugin: openai-bundled/chrome/26.623.70822
Codex Chrome Extension: 1.1.5
Chrome profile: Default
Chrome version: 149.0.7827.201
OS: Windows 11 Pro 10.0.26200 x64

What happens:

Computer Use detects Google Chrome and the active Chrome window correctly. For example, it sees the window title:

Вакансия Программист разработчик 1С в Омске, работа в компании Группа ПРОДО - Google Chrome

But as soon as it tries to acquire the Chrome window state, it stops with the same error:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

I checked the local Chrome extension/native host setup:

Codex Chrome extension is installed and enabled
Native messaging host registry entry exists
com.openai.codexextension.json exists
extension-host.exe exists
allowed origin points to chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
no Chrome enterprise policy / native messaging blocklist was found in HKCU or HKLM

So in this case Chrome is visible to Computer Use, and the extension/native host setup appears valid, but Computer Use still cannot pass the Chrome URL-confidence check.

This seems specific to Computer Use + Chrome + Windows; other Windows app discovery works.

Akloenx123 · 1 month ago

Reproduced on Windows with Codex 26.623.13972.0 and Computer Use/Chrome 26.623.101652. Chrome is detected as “Google - Google Chrome”, but get_window_state and even Ctrl+L immediately stop with the exact URL-confidence error. This also happens with https://google.com open. The native-host registry entry, manifest, and executable are present. The Chrome backend additionally reported Browser is not available: extension. The issue therefore persists in 26.623.

livlojp · 1 month ago

#25271 is still reproducible on Windows Codex App 26.707.30751 (released July 10, 2026).

Verified:

Computer Use plugin: 26.707.30751
Chrome plugin: 26.707.30751
Chrome: 150.0.7871.115
Codex Chrome Extension: 1.2.27203.26575_0 (enabled)
Native Host diagnostics: passed
Computer Use bootstrap, Chrome detection, and get_window(): succeeded

For the Chrome window titled "New Tab - Google Chrome",
get_window_state({ include_screenshot: false, include_text: true })
reproduces the same error as before:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.

egore4606 · 1 month ago

Reproduces on:

OpenAI Codex 26.707.3748.0 (Microsoft Store)
Chrome 150.0.7871.114
Codex Chrome extension 1.2.27203.26575_0

Computer Use detects the Chrome window (including its “Example Domain” title), but acquiring the Chrome window state stops before screenshot/action with the exact error that it “could not determine the current browser URL on Windows with enough confidence to enforce policy”, even with https://example.com open.

The Chrome extension and native messaging diagnostics pass, and the separate Browser Use backend can enumerate the same live Chrome tabs. A separately configured Playwright MCP can operate the page successfully.

papaartemsmurf2002-commits · 1 month ago

Additional reproduction: AppX 26.707.6957.0, Chrome 150, and Opera 132

Retested on July 13, 2026 after reinstalling Computer Use and restarting.

Environment

Windows: NT 10.0.26200.7462, 25H2, x64
OpenAI Codex Microsoft Store/AppX package: 26.707.6957.0
Computer Use plugin cached/loaded by the task: 26.623.141536
Computer Use plugin bundled in the installed AppX package: 26.707.51957
Chrome plugin cache: 26.623.141536
Chrome plugin bundled in the AppX package: 26.707.51957
Google Chrome: 150.0.7871.101
Opera: 132.0.5905.114
Codex Chrome Extension: 1.2.27203.26575_0

Native-host and Chrome bridge checks

Verified locally:

Native-host manifest exists.
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension exists.
The registry default value points to the existing manifest.
The manifest authorizes chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/.
The manifest points to the expected cached extension-host.exe.
extension-host.exe is running from that expected path.
The dedicated Chrome integration connects successfully, enumerates open tabs, claims a normal Google HTTPS tab, and returns its current https://www.google.com/... URL and title.

This confirms that the extension/native-host path can independently read a live Chrome tab URL.

Reproduction matrix

Non-browser baseline succeeds

Computer Use opened Windows Calculator and completed 2 + 2 = 4.

Chrome fails at browser state acquisition

Computer Use detects Chrome and its window.
Before navigation or interaction, browser state acquisition stops with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.

Opera fails at the same stage

list_apps, get_window, and window activation succeed for Opera.
get_window_state stops with the same URL-confidence policy error.

The newer plugin bundled in the AppX package also fails

I initialized the packaged Computer Use client from 26.707.51957 directly.
Opera detection succeeded, but get_window_state produced the same policy error.

Recovery already attempted

Removed and reinstalled Computer Use through the Codex plugin UI.
Restarted Codex/Windows and tested from a fresh task.
Tested a normal HTTPS browser page.
Verified the extension, native-host manifest, registry pointer, allowed origin, executable path, and running host process.
Verified that the dedicated Chrome integration can read the active HTTPS tab URL.

Assessment

This does not appear to be a missing native-host registry entry or disconnected Chrome extension. The dedicated Chrome backend can read the URL, while Windows Computer Use rejects the same browser during its URL-confidence check. Opera reproducing the same failure suggests the affected path is the Windows Computer Use browser URL resolver rather than a single site.

There is also a plugin reconciliation mismatch: the current AppX package contains 26.707.51957, while the UI reinstall leaves the active cache at 26.623.141536. That appears secondary because the directly loaded packaged client also reproduces the failure.

Could the browser URL policy failure expose a diagnostic reason indicating which URL source failed or disagreed (extension mapping, UI Automation, window-to-tab mapping, or another verifier)?

julesLubrano · 1 month ago

Still reproducible on Windows 11 with a substantially newer build:

Codex Desktop: 26.707.9981.0
Computer Use plugin: 26.707.72221
Google Chrome: 150.0.7871.101
Codex Desktop running with a Windows + WSL configuration

Computer Use successfully detects Chrome and its open window through list_apps(). It then stops during get_window_state() with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

The Chrome extension backend is also unavailable in the same environment (agent.browsers.list() returns an empty list), even though the Chrome extension is installed and enabled.

This confirms that the URL-detection failure still reproduces on the 26.707 release family.

asiacnstudent · 1 month ago

Still reproducible on Windows 11 with a substantially newer build:
Codex Desktop: 26.707.3748.0
Google Chrome: 150.0.7871.129
model settings: GPT 5.6 Sol Medium Standard
Codex Desktop running with a Windows + WSL configuration
Computer Use successfully detects Chrome and its open window through list_apps(). It then stops during get_window_state() with:

<img width="777" height="534" alt="Image" src="https://github.com/user-attachments/assets/515a0de9-a9c8-46c2-8bc8-928574a02f37" />
This confirms that the URL-detection failure still reproduces

julesLubrano · 13 days ago

Still reproducible on 2026-08-15 with a newer Windows build.

Environment:

Codex Desktop for Windows (MSIX 26.810.7004.0)
Computer Use bundled plugin 26.810.52044
Windows x64
WSL-backed workspace

Exact reproduction:

The prescribed Computer Use bootstrap succeeds.
sky.list_apps() detects Google Chrome and returns the running Chrome window with a valid window id/title.
Selecting that returned window succeeds.
The first read-only sky.get_window_state(...) call stops the turn with:

Computer Use has been stopped for this turn because it could not verify whether the current browser URL is allowed.

No click, typing, navigation, or other input was attempted before the failure.

There is a separate Chrome native-host/backend path problem on this installation matching #28956, so failure to map the detected window to an extension-backed tab may be contributory. The current error still does not identify whether URL verification failed because of the extension connection, window-to-tab mapping, address-bar inspection, or policy state. Reporting that resolved sub-reason would make this failure actionable.

zemeng5208 · 12 days ago

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery/diagnostic utility for Codex Desktop Browser/Chrome/Computer Use local state.

This issue appears to contain two layers that are worth separating. The URL-confidence/policy decision itself is product behavior and WinBridge does not bypass or weaken that. But the surrounding symptoms — Chrome shown as connected while Browser is not available: extension, intermittent Computer Use plugin unavailable, and disagreement between the extension UI, Chrome backend and Computer Use runtime — are exactly the local consistency checks WinBridge can help with.

On Windows it can verify the installed official package against the user-side bundled marketplace/plugin cache, Chrome latest state, Native Messaging manifest/registry/v2 registration, local runtime/helper paths, and the Computer Use/Chrome materialization chain. If those layers are stale, partial or version-split, it can rebuild supported user-owned state from the already installed official package with backup/verification rather than manually fabricating a host or modifying WindowsApps.

A useful diagnostic boundary here is: if WinBridge reports the Chrome/native-host/runtime chain healthy and the same could not determine the current browser URL ... enough confidence to enforce policy error still occurs, I would treat that remaining failure as upstream URL-detection/policy logic rather than keep rewriting local files.

If anyone tests it on this specific Windows Chrome/Computer Use state, please report Worked / Partial / Failed here so the result is independently verifiable: https://github.com/zemeng5208/winbridge-recovery/issues/4

redsquid4525-ikasosaji · 11 days ago

Additional A/B result: the failure survives both the latest Windows update on this machine and a completely fresh local Windows user profile.

Environment:

Windows 11 25H2: 26200.9168 after installing KB5121003
Codex Desktop: 26.810.7004.0
Computer Use plugin: 26.810.52044
Chrome: 151.0.7922.138
Locale: ja-JP

I first retested from the existing Windows user after applying KB5121003. Computer Use uniquely identified the normal HTTPS Chrome window (Example Domain - Google Chrome), but the first read-only get_window_state call still stopped with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

I then performed an A/B test using a newly created standard local Windows account on the same PC:

first login for that Windows account
fresh per-user Codex state
completely new Chrome user-data directory
extensions disabled
no proxy
no Chrome/Google account sign-in
test URL: https://example.com/?computer-use-new-windows-user-ab=1

list_windows returned exactly one target:

app: Chrome
title: Example Domain - Google Chrome
valid window handle

The first get_window_state call on that returned window produced the same URL-confidence policy stop.

This substantially lowers the likelihood of an existing Windows-user-specific Codex cache, Chrome profile, extension, proxy, cookie, or login state being the root cause. The remaining shared boundary is the Windows 26200 build family / machine-wide Windows UI Automation environment / bundled Windows Computer Use URL-resolution path. A normal per-user Codex reset is therefore unlikely to address this case.

pfz14 · 8 days ago

Still reproducible on Windows 10 with the current 26.814 release family:

Environment

Windows 10 Pro 22H2, build 19045.6466, x64
Codex desktop package: 26.814.5167.0
Computer Use bundled plugin: 26.814.41407
Google Chrome: 151.0.7922.138

Exact reproduction

The prescribed @oai/sky initialization succeeds.
sky.list_apps() returns exactly one running Google Chrome app and exactly one window:

{
  "displayName": "Google Chrome",
  "id": "Chrome",
  "isRunning": true,
  "windows": [
    {
      "app": "Chrome",
      "title": "新标签页 - Google Chrome"
    }
  ]
}

Rehydrating the returned window succeeds.
The first read-only sky.get_window_state({ include_screenshot: true, include_text: true }) call immediately stops the turn with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

The same stop first occurred on a normal existing Chrome tab. The user then explicitly opened a fresh Chrome new tab and kept it in the foreground; the failure reproduced unchanged. No click, key press, text input, navigation, screenshot, or site interaction occurred before either stop.

This expands the confirmed impact to Windows 10 build 19045, rather than only the Windows 11 26200 build family reported in some comments.

j604664003 · 8 days ago

Additional reproduction on 2026-08-20 with a newer Computer Use build after a full reinstall and app restart.

Environment:

Windows x64
Computer Use plugin loaded by the task: openai-bundled/computer-use/26.818.21641
Google Chrome
Exactly one Chrome window was open on a normal user-facing page

Reproduction:

Reset the JavaScript runtime.
Initialize the bundled @oai/sky package.
sky.list_apps() succeeds and returns Google Chrome with exactly one window.
sky.get_window(...) succeeds for that returned window.
sky.activate_window(...) succeeds.
The first read-only sky.get_window_state({ include_screenshot: false, include_text: true }) call immediately stops the turn with:

No click, typing, navigation, form submission, or other page interaction occurred before the stop.

Recovery already attempted:

Reinstalled Computer Use
Restarted the Codex desktop app
Reset and reinitialized the Computer Use runtime
Retested with one Chrome window on a normal page

The result was unchanged. This confirms that the URL-confidence failure remains reproducible in the 26.818 plugin family, beyond the 26.814 results already reported in this issue.

ESKehler · 2 days ago

Fresh current-build confirmation using one returned Chrome window:

Windows 10 Home 22H2, build 19045.7663
Computer Use plugin 26.818.61809
@oai/sky, target windows

sky.list_apps() and sky.get_window() succeeded against exactly one Chrome window.

On an approved observation-only get_window_state request, Computer Use immediately hard-stopped the turn with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

No click, typing, navigation, or other browser input occurred before the failure.

This confirms the URL-confidence stop remains reproducible in plugin 26.818.61809. Local paths, URLs, window handles, screenshots, and task/account identifiers are omitted.