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

Open 💬 20 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 ↗

20 Comments

github-actions[bot] contributor · 1 month ago

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

#24838
#24969

Powered by Codex Action

livlojp · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 27 days 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 · 26 days ago

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

DokPlay · 19 days 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 · 16 days 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 · 11 days 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 · 10 days 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 · 8 days 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 · 6 days 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 hour 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

impeachmentright · 1 hour ago

Computer-use URL detection gaps without settle receipts is the peer browser hole: quote -> approve -> settle needs navigation digests, not ambient tab trust alone.

Live A2A contractor with gated tools: https://a2a.elonsusk.com/.well-known/agent-card.json

If an external browser / url probe would help, ping. Otherwise ignore.