Repository navigation
Computer Use cannot determine Chrome URL on Windows, even on chrome://newtab/ #25271
Description
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/orabout: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.
Activity
github-actions commentedon May 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
x5neivi commentedon May 30, 2026
I reviewed the potential duplicates. Some appear related, but this issue may not be a complete duplicate.
Related issues:
agent.browsers.get("extension")fails withBrowser is not available: extension.Unable to find Electron app/Cannot find module, but the path ends with...\google-chromerather than an OAuth callback.COMSPECworkaround, 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/orabout:blank.If maintainers confirm that this is covered by one of the existing issues, I can close this as a duplicate.
x5neivi commentedon Jun 3, 2026
Update: retested with Codex App
26.601.20914I retested after updating the Windows Codex App.
Environment:
26.601.20914/ released 2026-06-03openai-bundled/computer-use/26.601.20914148.0.7778.2171.1.5_0config.toml:[windows] sandbox = "elevated"What improved:
What still fails:
list_apps/list_windowssucceeds.新しいタブ - 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:
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:
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 commentedon Jun 3, 2026
I can reproduce this as well, but with Microsoft Edge rather than Google Chrome.
Environment:
OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0)openai-bundled/computer-use/26.601.21317MSEdgeWhat happened:
get_window_state.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 commentedon Jun 3, 2026
I am experiencing the same issue on Windows.
Computer Use can open my local page in Edge/Chrome, but then
get_window_statefails with:could not determine the current browser URL on Windows with enough confidence to enforce policyIt seems Codex cannot reliably detect the current browser URL on Windows, so Computer Use is stopped by policy. Is there any workaround or fix?
x5neivi commentedon Jun 5, 2026
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:
Observations:
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 commentedon Jun 9, 2026
Additional reproduction on Windows 11 (Microsoft Edge via Computer Use):
Environment
Failure
After selecting/activating the Edge window, Computer Use stops during window-state acquisition (get_window_state) with:
Notes
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 commentedon Jun 9, 2026
Additional reproduction on Windows 11 (Microsoft Edge via Computer Use):
Environment
computer-use@openai-bundled26.602.71036setupComputerUseRuntime({ globals: globalThis })succeeds from bundledcomputer-use-client.mjssky.list_apps()succeeds and returns Microsoft Edge (MSEdge) with an open windowFailure
After selecting/activating the Edge window, Computer Use stops during window-state acquisition (
get_window_state) with:Notes
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.
x5neivi commentedon Jun 12, 2026
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:
Result:
In this version I could not reach the original #25271 reproduction point.
Computer Use failed during bootstrap before
list_apps/list_windowsand before Chromeget_window_statecould be tested.Error:
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:
Omniloss commentedon Jun 14, 2026
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-88d3c01be8edEnvironment:
OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0149.0.7827.5410.0.26200, build26200, 64-bit26.609.4111426.609.41114@oai/sky:0.4.10789504f803e82e2b149.0.7827.115149.0.4022.69Observed behavior:
sky.list_apps()returns Chrome with a window titledExample Domain - Google Chrome.sky.get_window_state({ window: chromeWindow, include_screenshot: false, include_text: true })stops the turn with: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:
truetruehehggadaopoacecdllhhajmbjkdcmajgtruetruetrue[ { "title": "Example Domain", "url": "https://example.com/" } ]example.comRootWebAreadocument value:https://example.com/zh-CNtoen-USdid not help.omnibox.prevent_url_elisions = truedid not help.--lang=en-US --force-renderer-accessibilitydid 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.
36 remaining items
yotch0928-collab commentedon Oct 4, 2026
Additional Windows observation (2026-10-04): Japanese UI, same native component, extension reads recovered within the existing task.
Verified locally:
The supported native API discovers the Chrome window, but window-state acquisition returns the exact current-browser-URL confidence stop described in this issue. Native work stopped when that refusal was returned.
Separately, the official Chrome extension channel initially failed to enumerate tabs with "Unable to load browser request-header policy." Resetting the browser JavaScript session did not immediately recover it. A later normal tab enumeration in the same task succeeded; the extension then retrieved the authorized existing HTTPS page's content and screenshot. No desktop restart, extension reinstall, account switch, policy change, or runtime patch was applied. A subsequent native window-state request still returned the same URL-confidence refusal. In a later turn, another read of the existing page through the extension succeeded in approximately 1 second.
This adds a Japanese-UI observation using the same component hash as comment 5971013202. We did not independently disassemble the component or observe the rejected element's live properties; the matching hash supports applicability of that static analysis but does not prove which branch caused this installation's failure. The separate policy-initialization failure also recovered within the existing task, so it should not be assumed to be permanently stuck or to explain the remaining native refusal.
Could maintainers provide a signed fixed component or a supported privacy-preserving diagnostic distinguishing Document selection, URL extraction, target-window association, and policy evaluation? Please retain URL validation and rejection on ambiguity.
This report was posted with the operator's authorization. Private URLs, page contents, screenshots, account identifiers, local usernames/paths, credentials, and raw logs are omitted.
NinjinAniki commentedon Oct 5, 2026
Additional reproduction on 2026-10-05 JST: Japanese Windows, Chrome and Edge, still failing after a Codex restart.
Environment verified locally:
Observed behavior:
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.
Observed cases across separate, user-requested attempts:
Minimal supported API sequence used:
Each attempt stopped when the tool returned the stop instruction. Later attempts were explicitly requested by the operator. No URL-policy override, binary patch, private helper execution, or fabricated window/URL data was used.
Impact:
The user cannot delegate ordinary browser GUI tasks or screenshot collection through native Computer Use, even though the browser is visible and usable manually. Reopening the page, changing browsers, keeping the address bar visible, and restarting Codex did not resolve the observed failure. The generic error does not identify which URL-discovery step failed.
Separate observation, not a claimed shared root cause:
Earlier, before switching to native-only operation, the supported browser automation route could read the intended webpage. That particular site has a developer-tools detector which initiated a navigation to its About page when browser tooling connected. We therefore attempted native mouse/keyboard and OS capture. However, the native URL-confidence failure also occurred in Edge before visiting that site, so the site's detector is not sufficient to explain this native failure.
Existing comments 5971013202 and 5977343295 discuss localized Windows/UIA behavior and the same app/plugin revisions. Our ja-JP reproduction is consistent with those observations, but we did not independently trace UIA properties or establish the root cause. We did not perform an English/Japanese locale A/B test.
Please investigate the native URL-discovery path and provide a supported fix or privacy-minimal diagnostics that distinguish document identification, URL extraction, target-window association, and policy evaluation. Actual URL validation and rejection of ambiguous or denied targets should remain intact. Please also cover Japanese UI and both Chrome/Edge in regression testing.
Posted at the operator's explicit request to investigate and report this failure. Private URLs, page contents, screenshots, account identifiers, local usernames/paths, credentials, and raw logs are omitted.
marcoxbr commentedon Oct 5, 2026
I can reproduce this on a much newer current build, and the failure is now isolated specifically to the native Windows Computer Use → Chromium URL-confidence path.
Current environment
26.930.3930.0154.0.8037.95@oai/sky:0.7.5Current control results on the same machine / same target page
Target page:
https://www.ppa.com.br/brasilChrome extension / Browser Use: PASS
Using an already-existing, human-selected Chrome tab, the extension path successfully resolved and read the exact tab:
1574516431https://www.ppa.com.br/brasilPPA - Conforto com SegurançaNo new tab was created, activated, or navigated by automation.
Integrated Browser: PASS
The integrated Browser backend also successfully accessed the PPA page and returned the final URL/title/content.
Native Computer Use on Chrome: FAIL
A fresh native window discovery returned exactly one matching Chrome window. One read-only state request was then made against that freshly returned window:
sky.get_window_state({ window, include_screenshot: true, include_text: false })Result:
No screenshot was returned. No click, typing, navigation, retry, fallback, or policy bypass was performed after the stop.
This gives a useful contrast on the same live environment:
Non-browser native Computer Use had previously succeeded against Windows Calculator, so the failure remains specific to the native browser URL-resolution/policy bridge rather than general Windows capture.
Additional notes
During the investigation, Browser/Chrome integration issues on the local installation were repaired separately, including restoring the current Browser bundle and confirming current Browser/extension operation. The native Computer Use failure above still reproduces afterwards.
Related reports with very similar isolation:
At this point I do not have a safe local fix for the native URL-confidence failure. A supported diagnostic that distinguishes failure at:
would be very helpful.
zekai7261-stack commentedon Oct 6, 2026
Additional Windows trace: empty in-app-browser enumeration in the same turn as the URL-confidence stop, and why ending the whole turn matters for long jobs
Environment (Windows 10 Pro 22H2, build 19045, x64):
26.930.31730(first entry 06:35:25 JST); previous client26.928.40906(last entry 06:33:36 JST). Appx package version26.930.3930.0is a separate identifier, not a third update.0.160.0;approval_policy=never,approvals_reviewer=user,sandbox_mode=danger-full-access; configured backendschrome,iab,mcpapps.Recorded trace, 2026-10-05 JST (UTC+9):
cua.listTabs({browser:'4'})→Browser is not available: 4cua.listBrowsers()→[]cua.createBrowserTab('iab', …)→Browser is not available: iabtask_complete— the top-level task ended before the requested operation startedThe agent initially reused a stale numeric browser id, which was its own mistake. That does not explain the rest: the fresh enumeration returned an empty array and an explicit
iabrequest also failed. The three 09:08 timestamps are one call (issue, inner completion, recorded result), not three failures; the call start is not the stop instant.Two top-level endings, and they are not the same event. The first (09:08:27) followed the tool's own instruction to stop work and send a final message. After the first user re-instruction at 09:10:28, a second completion at 09:12:30 was the agent's own early ending — no equivalent stop instruction was returned in that turn, and no attempt was made at a capability that worked minutes later. Do not read the second as another platform-forced stop.
Recurrence. The identical stop string appears as an actual tool result 8 times across 5 local threads between 2026-09-25 and 2026-10-05. Seven of the eight precede the 2026-10-05 06:33–06:35 client version transition, so this comment does not claim the update introduced it, and it does not claim the update worsened it either (untested):
Counterexamples (intermittent, and the in-app backend later worked). Later on 2026-10-05, in a new turn of the same thread at 11:14:57, the in-app browser enumerated normally and completed an authenticated page read plus a file download. At 11:55:22 a different local thread and client entry loaded a public static page. No intervening reinstall or configuration repair was identified in the reviewed records. The recovery trigger is unknown; this does not establish that the native URL-confidence path recovered.
Diagnostics I ran, and their limits. For the standard current-user Chrome data root and its
Defaultprofile, the bundled extension check returnedinstalled:false(exit 2) while the native-host manifest check returnedcorrect:true(exit 0). These are external-Chrome dependency facts; no original evidence shows that the external extension is a required dependency of the in-app-browser backend, so they are not presented as its cause. No local occurrence of the "saved browser permissions could not be verified" error class was found in the reviewed local sources — that is a search-scope statement, not proof it never occurred here, and public reports of that error class are separate cases.Why this matters beyond the error string. This did not cost one error message; it ended the top-level task of an authorized multi-hour job before its first step, and the job then needed two human instructions and a manual third-party authentication step before recording started, approximately 21 minutes after the original instruction. The agent's compliance with "stop your work and send a final message" is what made the top-level failure — unrelated background workers staying alive does not soften it. A stop that ends a whole job is a far more expensive contract than a stop that disables one capability.
Questions:
listBrowsers()is empty orBrowser is not available: <id>is returned? Is there a supported machine-readable diagnostic, and if not, is that on the roadmap?A separate public report in this same issue (the 2026-10-05 ja-JP report by another reporter) shows a Windows 11 / ja-JP environment where window enumeration succeeds and native window-state acquisition still fails after restart; an Edge case also failed before visiting the target site. I am citing a separate public report from a different account, not my machine's log.
Another October 5 report on the same app build describes successful extension and integrated-browser access while native Computer Use still returned the same stop. That is a separate reported comparison, not evidence that our empty IAB enumeration and the native stop share a cause.
I am not asking for the URL policy to be relaxed, and I have not disabled any check, patched any component or circumvented the stop. Ambiguous or unverifiable URLs should keep failing closed. What I need is the failure boundary and a way to tell the states apart.
(This comment deliberately omits account identifiers, private URLs, raw logs and screenshots.)
KallasLima commentedon Oct 6, 2026
I can reproduce the same native URL-confidence failure after the October 6 Windows app update, with working Browser Use on the same page.
Environment
OpenAI.Codex 26.930.6422.0(status OK), updated from26.930.4958.0using the official signed package, then fully exited and restarted.26.930.51102.10.0.26300.0, display localept-BR.154.0.8037.98.Reproduction on an unlocked desktop
https://example.com/and bring it to the foreground.@oai/skypackage in a fresh JavaScript session.list_windows()returns the correctExample Domain - Google Chromewindow. Select that exact returned window withget_window()and activate it.get_window_state({window, include_screenshot:true, include_text:true})returns:The turn stops before native screenshot/input can continue. Fresh sessions, a new browser tab, the signed update and full application restart did not resolve it.
Controls
include_text:true, accessibility data was null.This blocks native browser zoom and screen-reader testing. OpenAI Help's support assistant could not provide a fix or case number and directed me to this tracker. It mentioned the current service incident, but I have no evidence connecting that incident to this native failure.
Is there a supported diagnostic that distinguishes URL acquisition, window-to-tab mapping, and policy-confidence evaluation, or a build that fixes this? The URL check should remain enforced; I have not patched the helper, injected a URL, or changed browser identity or safety settings.
luiz00martins commentedon Oct 6, 2026
Also reproduced on Windows 11, Microsoft Edge.
tlswotj commentedon Oct 7, 2026
Additional reproduction on 2026-10-07 (KST), on Korean-language Windows with the current installed app/plugin.
Verified environment
ko-KR.OpenAI.Codex 26.1002.6548.0.26.1002.51308.@oai/sky:0.7.6.154.0.8037.98.Observed behavior
The supported
node_repl+@oai/skypath initializes successfully. Bothsky.list_apps()andsky.list_windows()identify the running Chrome app and its single target window, including the expected website title.A read-only call against the returned Chrome window:
immediately returns:
No usable screenshot or accessibility tree is returned. An earlier text-only request (
include_screenshot: false, include_text: true) also failed.Recovery attempts that did not resolve this reproduction
Each attempt stopped when instructed by the tool; subsequent attempts were requested by the user. No runtime patch, fabricated URL/window, or policy override was used.
Relevant distinction
Desktop logs for this installed release report
browser_use_availability_resolved available=true platform=Windows reason=available. This does not match thewsl-disabledrecovery case described above. It also does not prove that the separate Chrome extension path is connected or that native URL extraction succeeds.The localization hypothesis discussed in this issue is consistent with this Korean-UI reproduction, but it has not been independently established as this machine's root cause. No language A/B test or live UIA-property trace was performed.
Please provide a supported fix or diagnostics that distinguish document identification, URL extraction, target-window association, and policy evaluation while preserving URL validation.
Posted with the user's explicit authorization. Private URLs, project/BOM contents, screenshots, account identifiers, local usernames/paths, credentials, and raw logs are omitted.
pavel444-byte commentedon Oct 10, 2026
Additional reproduction in Brave on Windows with Russian UI, checked on 2026-10-10. This extends the browser coverage of this issue: app/window enumeration succeeds, but native URL validation blocks even a read-only window-state request.
Verified environment
10.0.26200.0; registry display version25H2, build26200.8457; x64.ru-RU. Computer Use configuration locale:ru-RU.26.1007.21434. The registered MSIX package version was not independently obtained.openai-bundled/computer-use/26.1007.21434.@oai/sky:0.7.6.149.1.91.175.node_repl+@oai/skyentry point.Permission and initialization checks
@oai/skyand callingsky.list_apps()succeed.app: "Brave". In the controlled retest its title isGoogle – Brave.Actual observations
Google – Bravewindow. A read-only call,Native browser actions were stopped after each error. No helper patch, injected URL, fabricated browser identity, policy override, or security-setting change was attempted.
Relevant local diagnostics
The current desktop session logs show:
The last line is reduced to non-identifying fields; the unique pipe identifier is omitted.
A separate startup warning concerns the unified Computer Use MCP server:
The Russian message means the system cannot find the specified path. A subsequent startup entry reports empty tools for that server. This is recorded as a separate observation: the native
@oai/skypath initialized and enumerated Brave successfully, so the warning is not established as the cause of its URL-validation failure.The startup extension-sync diagnostic also reports the Chrome plugin/extension as missing at that time. Current extension installation was not independently verified, and no dependency between that extension and the native URL check was established.
Interpretation and limits
The confirmed failure boundary is between successful native browser-window enumeration and protected state/input access. These observations do not distinguish URL extraction, UIA document identification, window-to-tab association, or confidence/policy evaluation.
This Russian-UI reproduction is consistent with localization reports already in the thread, but no language A/B test or live UIA-property trace was performed. Browser Use reporting available also does not prove an external Brave connection works. Other browsers and non-browser native apps were not tested in this diagnostic.
Could a supported diagnostic expose the failing stage and a non-sensitive reason code, and could maintainers identify a fixed build if available? Actual URL validation and denied/ambiguous-URL handling should remain enforced.
This report intentionally omits local usernames and filesystem paths, account/email identifiers, private content, session/window/pipe IDs, screenshots, and raw logs.
JOEWRKS commentedon Oct 11, 2026
Additional ko-KR reproduction and current-binary verification — 2026-10-11
Following the earlier localized Document analysis, we independently checked the currently installed binary with a different SHA-256. The locale-sensitive classifier is still present. This report adds current-build evidence; it does not establish the sole runtime cause.
Observed failure
On a Korean Windows environment, Browser Use reads a local test page URL and DOM successfully. Windows Computer Use lists the Chrome window, but get_window_state stops with:
The documented JavaScript-session reset and fresh connection did not recover it. Calls were stopped when instructed. Chrome and the diagnostic shell run at medium integrity; Chrome does not have accessibility-disable or language-override command-line flags. No policy overrides, binary patches, direct helper calls or OS-language changes were attempted.
Environment identifiers
Reproduction for maintainers
Static findings on this exact binary
Read-only PE disassembly indicates:
This is a locale-dependent Document classifier and a strong candidate for the observed failure. We did NOT capture the actual localized UIA value or executed branch from the refused request, nor run an OS-language A/B. Runtime causality and other possible causes remain unconfirmed.
No original binary, private window contents or raw personal logs are attached.
Requested provider investigation and correction
Please trace the Document classifier and native URL extraction on ko-KR. If confirmed, classify the element with the language-independent UIA_DocumentControlTypeId (50030), keeping localized text only for display. Retain target-window association, real URL extraction and rejection of ambiguous or prohibited URLs. Please provide the supported release/build containing the correction or an official diagnostic procedure.
Acceptance checks: ko-KR and en-US; multiple windows/tabs and active-tab changes; correct allowed URL; prohibited/ambiguous URL still rejected; no weakening of normal policy enforcement. None of these post-fix checks has run yet.
Documentation
AI-Banner commentedon Oct 12, 2026
Additional ko-KR Windows reproduction and patch request — 2026-10-12
Posted at the operator's explicit request, prepared with Codex assistance.
Verified environment
Observed reproduction through the official native API
The same failure occurred on multiple existing Chrome windows and on subsequent user-requested tests. Window activation succeeded but did not resolve it. After each stop, native inputs were stopped; no click or typing was performed to bypass the refusal.
Independent working control
The official Chrome extension Browser Use path successfully enumerated six existing tabs and, after explicit authorization, bound an existing tab and read its page/accessibility state. This establishes that the separate Browser Use channel can work while native Windows URL detection fails. It does not establish native Computer Use repair.
Diagnostic limits
Patch request
Please investigate the native URL-discovery path on this current signed component, particularly localized Document-role identification. If confirmed, use language-independent UIA ControlType identity (Document 50030) while retaining correct target-window/tab association, real URL extraction, and rejection of prohibited or ambiguous URLs.
Please provide a signed supported fix/build or a supported diagnostic that distinguishes document identification, URL extraction, window/tab association, and policy evaluation. Acceptance should include ko-KR and en-US, multiple tabs/windows, allowed URLs, and continued rejection of denied/ambiguous URLs, followed by a native state read, benign authorized action, and post-action verification.
Private URLs, account/email identifiers, usernames, local paths, screenshots, cookies, credentials, and raw personal logs are intentionally omitted. No mail or calendar changes were made.
Alexvas19 commentedon Oct 12, 2026
Additional ru-RU Windows reproduction, checked 2026-10-12.
Environment: Windows 11 Pro build 26200, Get-UICulture and Get-WinSystemLocale
both ru-RU; MSIX 26.1007.2314.0; internal app / Computer Use bundle
26.1007.21434; @oai/sky 0.7.6; Chrome 154.0.8037.98.
The serving Rust helper SHA-256 is
58fff5e2359aa09528f48ef37651b9013b204f99e2fd381f0d3d980cf9d2e88d,
identical to the component analyzed in
#25271 (comment) .
Read-only PE byte verification on this machine confirms the cited vtable-call
offset and the reference to the eight-byte English literal document. This adds
a matching ru-RU environment; it does not establish the executed runtime branch.
Supported sky API observations: list_windows and get_window succeed;
get_window_state stops because the browser URL cannot be determined with
enough confidence to enforce policy. No alternate channel was used to inspect
the blocked object. The relevant current processes have Medium integrity in
Session 1. Four selected copied-runtime hashes match the MSIX files.
Current list_apps succeeds in 455 ms. An earlier list_apps timeout followed by
an active-request error cannot be reconstructed after an external OS reboot.
Static transport inspection shows that the client's 10-second timeout can
expire before the server handler clears its active flag, particularly when
end_turn and the main operation have separate timeout budgets. This mechanism
is not claimed to explain the URL detector failure.
The installed supported codex doctor --json did not complete within a bounded
45-second local diagnostic run; no valid report was produced. No relationship
to the native browser failure is established.
Could maintainers provide a supported diagnostic reason code distinguishing
Document classification, URL extraction and target-window association, and
identify a signed fixed build? Please investigate localized Document matching
for this exact helper and ru-RU. Preserve real URL validation and rejection of
ambiguous/disallowed URLs. No executable patches, policy changes, OS-language
changes, profile clearing or application restarts were performed by us.
This comment contains no personal paths, account identifiers, private page URLs,
window/session/pipe IDs, screenshots, credentials or raw logs.
ksson0330-crypto commentedon Oct 15, 2026
Reproducible Windows native URL-confidence stop after an empty text-only state response
This is a sanitized follow-up for openai/codex issue #25271. No business content, internal URL, username, cookie, token or original session log is included.
Environment verified locally
Isolated reproduction, 2026-10-15
Stop 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. Stop your work and send a final message noting why Computer Use ended.
Readable JavaScript boundary inspection
The installed Windows client accepts include_text and forwards it unchanged. Its response normalizer maps absent/null accessibility to null. With screenshots disabled, even a raw empty object becomes the input window plus accessibility:null and screenshots:[]. Ten offline checks using the real installed JS class with a wholly fake transport verified this behavior, preserved valid trees, option forwarding, error propagation and lack of a null-result cache. Therefore the first resolved response is not proof that a native observation succeeded; the actual raw response from that live call is unknown. Readable desktop JS also passes method/parameters and the transport result through unchanged. No native helper executable was inspected or changed, and no private protocol client was used.
Scope and uncertainty
Requested fix while preserving policy enforcement
Please reject or explicitly classify an incomplete state response when requested observation data is absent, rather than normalizing it into apparent success. Please confirm whether Windows include_text currently guarantees an attempted UIA collection and expose a diagnostic reason when it returns no accessibility data. Please distinguish UIA collection, Document classification, URL extraction, window/current-tab association and policy-verdict failures, without exposing sensitive URLs. If translated UIA role strings are involved, use stable ControlType identifiers and regression tests for Korean/English UI while retaining real URL validation and all deny/stop semantics. Please provide a signed supported fix or a documented supported recovery procedure.
Regression acceptance
A normal, uniquely selected, visible HTTPS tab must support repeated independent state observations and the requested accessibility data, or an explicit diagnostic reason. Ambiguous/disallowed targets must retain their existing restrictions. Popup/dialog and capture tests should be evaluated separately.
jxy1998tiger-arch commentedon Oct 15, 2026
Additional Windows reproduction on 26.1007.71326 — 2026-10-15
Native Computer Use still stops when reading a Chrome window showing https://example.com/, including after
sky.activate_windowcompletes successfully.Environment
26.1007.71326, installedBuildVersion20398, release channelprod. The configured updater returnedup_to_dateon 2026-10-15.26.1007.9446.0. This is a separate version field.26.1007.71326; runtime@oai/sky:0.7.7.155.0.8059.40.Reproduction through the documented native API
load, with final URLhttps://example.com/.node_repl, import@oai/sky. Callsky.list_windows()and select the unique returned Chrome window titledExample Domain - Google Chrome.sky.get_window({id, app}).sky.activate_window({window}). It completes without an error.sky.get_window_state({window, include_screenshot:true, include_text:true}).The state request returns:
No screenshot or accessibility state is returned. The turn ends as instructed. No native click or text input follows the stop.
An earlier separately authorized test on the same public URL failed with the same error without an explicit activation call. Before that failure, the separate browser-skill connection could read the URL and page structure. This establishes a working browser connection, not successful native URL detection.
Component checks and limits
@oai/sky/package.json, its entry point, Node, node_repl, the native Computer Use executable and Swift helper match the bundled files by SHA-256.codex-computer-use.exeSHA-256:D36AE6626BDCED7AE07935D1A91BE14425E8F6CE7C9B5C69F2D8D7DF0C130D83.These checks found no copy/version mismatch in the inspected files. They do not establish the cause of the URL failure. Window activation returned success, but the subsequent state request failed, so no native screenshot independently confirms the final capture target. No live UIA trace or language A/B test was performed.
Could maintainers provide a supported diagnostic that distinguishes URL extraction, document identification, target-window/tab association and policy evaluation, or identify a signed build containing a fix? Real URL validation and rejection of ambiguous or disallowed targets should remain enforced.
This report contains only the public test URL, component versions/hashes, documented API steps and the error. It omits personal paths, account identifiers, business content, screenshots and raw session logs.
parkjongkook commentedon Oct 15, 2026
Additional Windows reproduction and request for login workflow parity with macOS — 2026-10-16 (KST)
Please investigate this Windows Computer Use failure and provide a supported fix so an authorized browser login can complete, including clicking the username field, selecting the browser's existing saved-account autofill suggestion, and submitting the login form.
The user reports that the same workflow worked on macOS yesterday. That macOS result is user-reported and was not independently reproduced during this Windows investigation.
Observed on Windows
up_to_date(release26.1007.71326, build20398).@oai/sky:0.7.7; Chrome:155.0.8059.41.@oai/skypackage again,sky.list_windows()succeeds.sky.get_window({ id, app })succeeds.sky.get_window_state({ window, include_screenshot: true, include_text: true })call then returns:No screenshot or accessibility state is returned, so the authorized native click and saved-account selection cannot proceed. Work stopped when instructed. Resetting the control session did not resolve the failure.
Requested outcome
Please fix the Windows URL-discovery/window-state path, or provide supported diagnostics and recovery steps identifying the failing stage. The expected acceptance check is successful native window-state acquisition, a physical-style click on the username field, selection of the existing autofill suggestion, and a verified successful login. Please preserve actual URL validation and existing security checks.
This report is posted at the user's explicit request. Private site URLs, account identifiers, credentials, cookies, screenshots, local paths, and raw logs are omitted. The underlying internal root cause has not been established.
markstd-007 commentedon Oct 16, 2026
zh-CN Windows 补充实测与分阶段诊断请求（2026-10-16）
经电脑使用者明确授权发布。以下仅包含公开测试页、组件版本及脱敏结果，不包含账号、会话ID、私人路径、Cookie、Token、截图或原始日志。
环境与组件
10.0.22631；UI culture/system localezh-CN。26.1007.21434/ build13901；Windows应用包26.1007.2314.0（分别列出，不混淆版本字段）。26.1007.21434；@oai/sky0.7.6；Chrome155.0.8059.40；官方Chrome扩展1.26.901.11451。codex-computer-use.exeSHA-256：58fff5e2359aa09528f48ef37651b9013b204f99e2fd381f0d3d980cf9d2e88d；Authenticode Valid，OpenAI签名。与评论 Computer Use cannot determine Chrome URL on Windows, even on chrome://newtab/ #25271 (comment) 的组件一致。原生路径
https://example.com/；另轮公开localhost HTTP静态页也曾出现相同失败。sky.list_windows()、按唯一返回窗口调用get_window()成功。activate_window()请求成功返回。get_window_state({window,include_screenshot:true,include_text:false})仍返回无法可靠确认当前浏览器URL的停止错误；没有返回截图。按指令立即结束当轮，没有换通道继续被拒绝的操作。激活请求返回成功不等于已独立证明实际前台状态。对照与已排查条件
browser_use_availability_resolved available=true platform=Windows reason=available，以及原生管道startup ready；不匹配评论5600407297的wsl-disabled案例。当前启动桌面日志为空，不能据此保证当前内部状态。nodeRepl.fetch request failed错误；未修改此处原生helper、URL校验或策略。扩展通信恢复不能证明原生故障恢复。请求
请提供受支持的脱敏诊断，区分UIA初始化、Document识别、真实URL提取、目标窗口/活动标签关联和许可判定；阶段名称、数值类型和成功/失败原因码即可。若本版本存在本地化Document匹配缺陷，请提供签名修复及适用版本。须保留真实URL验证及对禁止/歧义目标的拒绝。
没有应用评论中的二进制偏移补丁，没有改系统语言、安全判定或浏览器登录数据。本条由AI协助整理，根因仍未确认。