Repository navigation
[Windows] Computer Use stops at get_window_state: cannot determine current browser URL (Chrome and Edge) #51524
Description
Activity
The exact URL-policy stop was observed initially in Brave using Computer Use plugin 26.930.61225. Later attempts, including a fresh-session retest on October 6, successfully exposed the URL and page accessibility tree, so the URL-policy stop did not recur in that retest. Screenshot capture remained blocked by FrameArrived/window capture timeouts, with an indexed-click geometry error. Those later symptoms align with #49680 and #51245. This adds a Brave occurrence while distinguishing the initial URL detection stop from the subsequent capture failure.
Additional Windows reproduction and read-only diagnostics from October 7, 2026.
Environment:
- Desktop app: 26.1002.51308, build 13417, prod channel.
- MSIX package: 26.1002.6548.0.
- Computer Use plugin: 26.1002.51308; @oai/sky: 0.7.6.
- Google Chrome: 154.0.8037.98.
- The desktop app update checker returned up_to_date.
Observed through the supported node_repl + @oai/sky API:
- list_apps returned the Chrome window.
- get_window succeeded.
- activate_window succeeded.
- get_window_state({window, include_screenshot:true, include_text:true}) returned the same URL-confidence policy stop reported here, without a screenshot or accessibility state.
The error was observed on both Google and a BOSS recruiting page. No browser search, click, or typing was performed after this stop.
Read-only checks:
- The session app allowlist includes chrome.exe.
- Desktop logs report the native pipe ready and the Computer Use plugin current.
- SHA256 comparisons of six copied runtime components against the current MSIX installation all matched: node.exe, node_repl.exe, sky package.json, sky.js, the Windows Computer Use helper, and the swift helper.
- Chrome, the desktop app, Node REPL processes, and the current swift helper are all non-elevated at medium integrity (RID 8192), in the active console session.
- Chrome was not launched with --disable-renderer-accessibility, --headless, or --kiosk.
- Both native-host registration caches point to the current installed resources; all registered paths exist. The Chrome native messaging manifest also exists. This does not establish extension connectivity.
- A Node REPL reset and reinitialization succeeded, and list_apps again returned Chrome. The subsequent get_window recovery attempt was rejected by automatic approval review because the earlier stop requirement remained in effect, so this recovery did not reach a new state-capture test.
The underlying URL-resolution cause remains unknown. No safety checks, permissions, browser data, or registration files were altered.
Could maintainers provide a supported way to identify which URL-resolution stage failed, or a fixed build? No account information, cookies, tokens, screenshots, personal paths, or raw logs are included.
Additional reproduction on 7 October 2026, submitted at the user's request.
Verified local versions:
- Codex desktop MSIX package: 26.930.7945.0
- Microsoft Edge: 154.0.4258.53
- Windows OS version reported by the local runtime: 10.0.26300.0
- Computer Use skill bundle observed: 26.930.61225
Minimal observed sequence:
- Import
skyfrom@oai/skyin the providednode_repl. sky.list_apps()successfully returns the Edge app and one live window.- Select that exact returned window with
sky.get_window({ id, app }). - Call
sky.get_window_state({ window, include_screenshot: true, include_text: true }).
Exact 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. Stop your work and send a final message noting why Computer Use ended.The same state-capture stop occurred in three successive user turns. Each turn ended after the stop; no click, typing or navigation was performed after it. The selected Edge window title changed between attempts, but page content and the current URL could not be inspected.
In the same session, the Edge extension browser path also failed to list tabs or open a new tab with
Unable to load browser request-header policy. Retry the browser command.; current evidence was added to #44169. A shared root cause has not been established.Expected: safely determine the current browser URL and return the authorized window state, or provide actionable diagnostics identifying the failed prerequisite. Please preserve the safety checks and provide a supported repair. No account details, page URLs or unredacted logs are included.
Reacted by benchristopher-gitWindows, Codex 26.1002.52244. Computer Use останавливается с ошибкой: “could not determine the current browser URL on Windows with enough confidence to enforce policy”. Расширение Chrome установлено, просмотр сайта разрешён. Перезапуск браузера и компьютера не помог. В отдельном диагностическом чате native computer APIs недоступны, поэтому восстановление проверить не удалось. Нужен поддерживаемый способ исправления.
Additional Windows reproduction, observed 2026-10-09 (Asia/Tokyo).
Environment:
- Desktop app version 26.1002.52244; MSIX 26.1002.7124.0.
- Computer Use plugin 26.1002.52244; @oai/sky 0.7.6.
- Microsoft Edge on Windows; existing ordinary browser window.
Verified sequence:
- Desktop log reports the Computer Use native pipe ready.
- The documented Node REPL import of @oai/sky succeeds.
- sky.list_apps() returns the Edge app and one window.
- Select that returned window with sky.get_window({id, app}).
- sky.get_window_state({window, include_screenshot:false, include_text:true}) stops with the current-browser-URL confidence error. No click, activation, typing, or foreground input was issued in this reproduction.
The browser connector can enumerate Edge tabs and their URLs. That is only an inventory control, not proof of native window-to-tab association or native policy enforcement.
There was also a separate elevated-sandbox startup defect: root-only ACL validation requested incompatible access to active runtime files (error 32). It was locally mitigated using narrowly scoped, reversible write-data/append-data deny ACEs for the host user on eight specific runtime files. File hashes were unchanged; ordinary execution runs as CodexSandboxOffline and an out-of-workspace write is denied. The native URL-confidence failure persists after this mitigation and a normal desktop restart. The mitigation is not claimed to be an official fix or a native URL repair.
Please provide a supported diagnostic that distinguishes URL acquisition failure, window/tab association failure, and policy-service failure, or identify the release that fixes this path. We have not modified URL enforcement, injected a URL, patched a binary, or substituted a lower-level input route after the stop.
No usernames, local paths, window titles, page URLs, private logs, or screenshots are included here.
Additional Windows/Chrome occurrence, observed on 2026-10-09. The owner reports that work has been blocked for about 24 hours.
The existing node_repl -> @oai/sky -> sky.get_window_state text read returned an empty accessibility tree. A subsequent state read stopped with the same "could not determine the current browser URL on Windows with enough confidence" policy error. The executor complied with the stop. No browser retry, alternative input route, administrative service read, or live business call followed that stop. No new reproduction was performed for this comment.
Current metadata read on 2026-10-10:
- Microsoft Windows 11 Pro, version/build 10.0.22621 / 22621.
- Installed OpenAI.Codex Store package: 26.1007.2314.0.
These are current observations, not versions independently established for the original failure.
Please route this to the Windows Chrome/Computer Use page-context and policy integration owner and provide:
- The authoritative URL source for this path and a supported way to distinguish URL acquisition, window/tab association, and policy evaluation failures using existing evidence.
- The responsible component, supported correction or fixed release, and any minimum diagnostic needed without repeating an action after its stop.
- How the policy mechanism itself will demonstrate trustworthy page-context evaluation and permit the specific state-read action before resumption.
In-app feedback receipt is separately unconfirmed after a logged upload TCP connect timeout (Windows error 10060). A common cause with the URL-policy stop has not been established. This comment provides a tracked referral on the existing issue.
Potential engineering lead from the older discussion: #25271 (comment) proposes identifying UIA Document nodes by stable ControlType 50030 rather than a localized text label. This is community analysis for an older build, not a verified cause or repair for our current installation. Please confirm the current helper behavior and provide a supported correction/diagnostic. No binary patch or policy change has been applied here.
For the selected current-service evidence path, please also clarify the approved policy mechanism for a separately scoped administrative export through an already-authenticated provider tool with an explicit destination. Can that mechanism assess the destination and the exact read-only operation independently of the stopped native-window context, and what evidence must precede authorization? No such alternative operation has been executed, and the closed authorization window is not being reused. We are not asking to override the native stop or obtain its refused window-state result through another input channel.
No private project links, account identifiers, page URLs, screenshots, raw logs, or extracted application source are attached.
Additional Windows/Chrome occurrence, observed on October 11, 2026 (UTC+08), submitted at the user's request.
The owner reports that browser control previously worked. The last known-good date/build has not been established, so this is not a confirmed update-induced regression.
Current read-only environment checks
- Windows 10 Pro, version/build 10.0.19045 / 19045, x64.
- Google Chrome product version: 154.0.8037.98.
- Official
codex plugin list --jsonexits 0 and listscomputer-useandunified-computer-useas installed and enabled, both version 26.1007.21434. - The desktop app's About version was not independently verified. The plugin version above is not being presented as the desktop app version.
Already-observed failure through the supported API
In the preceding task turn:
- Import
skyfrom@oai/skyin the provided Node REPL. sky.list_windows()initially has no Chrome window. Launch the existing installed Chrome executable throughsky.launch_app.- A fresh
sky.list_windows()returns one Chrome window. Select that returned object withsky.get_window({id, app}). sky.get_window_state({window, include_screenshot:true, include_text:true})returns:
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.No screenshot, accessibility tree, or current browser URL was returned. The executor ended that turn immediately, without browser input, upload, generation submission, or a substitute control route after the stop. Earlier turns also observed the same error with a text-only state request. No new browser reproduction was run solely to file this comment.
Settings report and limits of the evidence
The owner reports re-enabling Chrome in the desktop app, allowing the intended origin (
https://grok.com), and having the Codex extension installed in Chrome'sProfile 1. These settings and the active Chrome profile were not independently read back. A full desktop-app restart has not been verified; this report does not claim that restarting was tested and failed.The requested workflow remains blocked before even a read-only current-URL check can pass. No successful assistant upload or media-generation submission is being claimed.
Please investigate the Windows URL-acquisition, window-to-tab association, and policy-evaluation stages, and provide a supported diagnostic and correction or fixed release. Recovery should preserve signed-in profiles and the policy checks.
This report omits personal paths, account identifiers, private project/session URLs, credentials, screenshots, and raw logs.
Additional current-build Windows/Chrome observation, with an independently working extension connection
Observed on 2026-10-11 (Asia/Shanghai, UTC+08). Windows 11 Pro, version/build 10.0.26200 / 26200. Desktop updater reported 26.1007.21434, build 13901, prod, up_to_date earlier the same day; MSIX package 26.1007.2314.0; bundled CLI 0.162.0-alpha.17.2. These are separately versioned components.
Computer Use bundle: 26.1007.21434. Chrome product version checked today: 154.0.8037.98. ChatGPT Chrome extension manifest: 1.26.901.11451. Windows/Chrome UI is Chinese.The preceding turn used the supported Node REPL and @oai/sky:
- sky.list_windows() returned the user's Chrome window, titled 新标签页 - Google Chrome.
- The exact returned Chrome window object was selected.
- sky.get_window_state({window, include_screenshot:true, include_text:true}) returned the following stop before a usable state or any native click/input:
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 executor ended that turn. No retry, URL injection, binary patch, alternate input route or disabled safety check followed the stop. This comment reuses the existing observation; it did not reproduce the stopped operation again just to report it.
Useful comparison: immediately before that native test, the Chrome extension path successfully entered and submitted a Baidu search and opened signed-in Sohu/Zhihu article editors. The agent-created test tabs were closed; only the user's original new tab remained in the last Chrome extension inventory. Extension connectivity therefore worked, but that does not establish native window-to-tab association or native URL extraction.
A separate attempted Calculator launch before the Chrome state read produced Windows' missing ms-calculator handler dialog. The current user has no Microsoft.WindowsCalculator package returned by Get-AppxPackage, although the protocol registry key exists. We did not obtain a native state capture proving whether this dialog affected Chrome, so its involvement is unknown and should be considered as a possible confounder, not a proven cause. Calculator is not being presented as a Codex regression.
Please provide a supported diagnostic or fixed build for native URL acquisition/window-to-tab association on this configuration, including whether Chrome new-tab pages or another app's modal dialog should return a recoverable prerequisite error. Preserve safety enforcement and signed-in browser data. No successful native click/input is claimed.
Submitted on the account owner's explicit request. This comment contains no account names, personal paths, credentials, cookies, private query parameters, screenshots, raw logs or conversation content.
Summary
On October 6, 2026, previously working Windows Computer Use stopped being able to inspect browser windows. App/window enumeration succeeds, but
sky.get_window_state({window, include_text:true})immediately stops the turn before any click or typing.Exact error
Environment
node_replwith@oai/skyReproduction
sky.list_apps()successfully returns the browser and its window title.sky.get_window({id, app}).sky.get_window_state({window, include_text:true}).Checks performed
The user reports onset after an update, but causation has not been established. Related historical report: #25271. This report records a fresh recurrence on October 6 rather than assuming the older issue is the same regression.
Expected behavior
Browser URL detection should succeed for an ordinary visible browser page, or return actionable diagnostics explaining which detection component failed. Please investigate a possible regression in the current Windows browser URL detection path.
No signed launch URLs, authentication tokens, account names, or screenshots containing them are included.