Repository navigation
[Windows] Computer Use stops at get_window_state: cannot determine current browser URL (Chrome and Edge) #51524
Description
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
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.
Environment
- Windows (exact build not collected)
- Both Microsoft Edge and Google Chrome
- Computer Use skill/plugin path version observed: 26.930.61225
node_replwith@oai/sky- Desktop app version not independently verified
Reproduction
- Open a browser page.
sky.list_apps()successfully returns the browser and its window title.- Select the returned window with
sky.get_window({id, app}). - Call
sky.get_window_state({window, include_text:true}). - The error above is returned immediately and the tool instructs the agent to stop.
Checks performed
- Reproduced in Chrome and Edge.
- Reproduced in normal Edge windows and InPrivate windows.
- Reproduced on Pearson course home, assignment launch, and Office Simulation windows.
- Reopening windows and showing the address bar did not resolve it.
- Restarting the app and fully rebooting the computer did not resolve it.
- No browser input was performed after the safety stop.
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.
Activity
afonseca08 commentedon Oct 7, 2026
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.
tangjue3 commentedon Oct 7, 2026
Additional Windows reproduction and read-only diagnostics from October 7, 2026.
Environment:
Observed through the supported node_repl + @oai/sky API:
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 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.
IT-EXPRESS-Bayern commentedon Oct 7, 2026
Additional reproduction on 7 October 2026, submitted at the user's request.
Verified local versions:
Minimal observed sequence:
skyfrom@oai/skyin the providednode_repl.sky.list_apps()successfully returns the Edge app and one live window.sky.get_window({ id, app }).sky.get_window_state({ window, include_screenshot: true, include_text: true }).Exact result:
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.
Cvety-tmn commentedon Oct 8, 2026
Windows, 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 недоступны, поэтому восстановление проверить не удалось. Нужен поддерживаемый способ исправления.
R122-code commentedon Oct 8, 2026
Additional Windows reproduction, observed 2026-10-09 (Asia/Tokyo).
Environment:
Verified sequence:
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.
osamaJamel commentedon Oct 10, 2026
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:
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:
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.
aaa75111 commentedon Oct 10, 2026
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
codex plugin list --jsonexits 0 and listscomputer-useandunified-computer-useas installed and enabled, both version 26.1007.21434.Already-observed failure through the supported API
In the preceding task turn:
skyfrom@oai/skyin the provided Node REPL.sky.list_windows()initially has no Chrome window. Launch the existing installed Chrome executable throughsky.launch_app.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: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.
lvkangtao-ai commentedon Oct 11, 2026
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:
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.
Follow-up on 2026-10-14: native non-browser control verified; browser URL issue remains unverified
Same desktop 26.1007.21434/build 13901, MSIX 26.1007.2314.0 and bundled CLI 0.162.0-alpha.17.2. Chrome is now 155.0.8059.40.
The bundled Computer Use skill's documented @oai/sky entry point successfully enumerated apps and read a newly opened File Explorer window. A fresh screenshot-backed observation, address-bar click, literal local-folder path input, Enter and a subsequent state read confirmed navigation. The test window was then closed. No business files or other open windows were changed.
A browser-oriented tool exposing no native APIs was insufficient to diagnose the separately installed native plugin. An initial AX-only click lacked coordinate geometry; refreshing screenshot-backed state and selecting the target window resolved that test setup issue. This does not establish a product patch.
The original native Chrome URL-confidence refusal was not retried without an official recovery basis, so #51524 remains unresolved on this installation. Please distinguish native non-browser availability from the native browser URL-recognition failure. No helper patch, alternate URL, raw CDP or security-check bypass was used.
This update contains only generic diagnostics, software versions and aggregate timings; no raw logs, screenshots, credentials, private paths, chat contents or identifiers are attached.
AgentBenji commentedon Oct 13, 2026
Additional independent reproduction observed on 2026-10-13 (Asia/Shanghai), submitted at the user's request.
Environment: Windows desktop; Microsoft Edge and Google Chrome. App/plugin versions were not independently verified.
Using the supported Node REPL +
@oai/skypath:sky.list_apps()enumerated the browser windows.sky.get_window_state()stopped with the same URL-confidence policy error for Edge, including a newly opened Edge window, and for a newly launched Chrome window. The stop occurred before a screenshot, accessibility tree, or page input was returned.5.This reproduces the browser-specific failure across Edge and Chrome while a non-browser control succeeds. No browser input was issued after the safety stop. No private page URLs, credentials, screenshots, or cluster details are included.
Please advise whether this is a known Windows browser URL-acquisition/window-to-tab association issue and provide a supported diagnostic or fix while preserving the safety checks.
opus99999 commentedon Oct 13, 2026
Additional Windows/Edge occurrence from retained evidence,
observed 2026-10-13T03:43:51.633Z.
Computer Use through node_repl and @oai/sky attempted an existing
Edge-tab click followed by a window-state read in one batch.
The returned message was:
“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 batch result does not establish which inner action triggered
the rejection or whether the click took effect.
Installed Computer Use documentation bundle: 26.1007.21434.
Executing helper binary version: not independently established.
A separate preceding browser-tab binding returned a 10000ms
Emulation.setFocusEmulationEnabled timeout. A causal relationship
has not been established.
No browser reproduction, reset, restart, reinstall, permission
change or policy bypass was performed during the subsequent
diagnosis.
Please identify a supported recovery procedure that preserves
URL/destination enforcement and existing sessions. Is there a
documented safe way to determine the continuing capability state
after this per-turn stop?
This report contains no private project content, conversation
identifiers, credentials, screenshots or session logs.
opus99999 commentedon Oct 13, 2026
Follow-up to comment #6144030199 with newly completed, read-only
static diagnostics.
Both documented stock checks ran once and exited successfully:
The Edge native-host manifest checker reported the expected
host name, expected extension origins and registry-to-manifest
path matching. Its implementation does not validate the actual
host executable or establish a live messaging connection.
The configured Edge extension checker reported the extension
installed, registered and enabled in its selected Default
profile. Enabled is the stock heuristic; the returned state was
null with no disable reasons. Association with the intended
visible browser profile remains unestablished.
These checks reported no actionable static setup defect within
their coverage. They do not establish debugger attachment,
live connectivity or restored URL/destination enforcement.
Current installed component evidence:
Codex Appx 26.1007.2314.0 x64;
Computer Use documentation/plugin bundle 26.1007.21434;
@oai/sky package 0.7.6;
observed Edge executable path with on-disk version 153.0.4234.32;
Windows build 26200.9457 x64.
These are current observations, not verified historical executing
versions. No update-caused regression has been established.
Retained successful operations used extension-based browser
control. A later extension focus timeout and the separate native
Windows Computer Use URL-confidence stop remain distinct
failures with no established causal relationship.
Please identify the next supported diagnostic or recovery action
that preserves destination enforcement and existing sessions.
Should extension attachment and native URL acquisition be
investigated separately, and what specific evidence is needed?
No browser reproduction, restart, reinstall, permission change
or policy bypass was performed during these diagnostics.
No private project content, conversation identifiers, credentials,
screenshots or raw logs are included.
5 remaining items
qingqiu-bai commentedon Oct 16, 2026
Additional Windows/Chrome reproduction on October 15, 2026.
Environment:
Observed behavior:
sky.list_apps()successfully identifies the intended Chrome window.sky.get_window()obtains the window.sky.get_window_state({window, include_screenshot:true, include_text:true})immediately stops with the 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."
The browser window was available, but no trustworthy URL or page state was returned. No browser interaction or alternative control method was attempted after the safety stop.
Please advise whether a supported diagnostic procedure or fixed build is available for Windows browser URL detection. We do not want to bypass the safety enforcement.
entry98 commentedon Oct 16, 2026
Windows Computer Use URL detection failure — ru-RU, @oai/sky 0.7.8
I have reproduced the same Windows Computer Use URL-confidence failure on a newer, officially signed runtime.
Environment
14D5E9C7336DD34AA8476F218DD45E033B8416BDAD6C58FA79C84169AE59F2F3Observed behavior
sky.list_windows()successfully detects Chrome.sky.get_window()successfully resolves the window.sky.get_window_state()stops because the current browser URL cannot be determined with enough confidence to enforce policy.Findings
The general window discovery and state acquisition mechanisms work for ChatGPT.
The Chrome-specific URL verification fails before browser contents become available.
The system locale is ru-RU. The localized UIA Document-role defect documented in #53026 is therefore a relevant hypothesis, but it has not been confirmed in this installation.
The installed @oai/sky 0.7.8 native helper has a different SHA-256 from the 0.7.6 and 0.7.7 builds investigated in the issue.
Request
Could maintainers confirm:
No binaries were modified, no safety checks were bypassed, and no private browser content was captured.
Thank you.
Assaf750 commentedon Oct 16, 2026
Additional sanitized diagnostic evidence from Windows, 16 October 2026, submitted at the affected user's request.
The earlier native
sky.get_window_statecall in this task stopped with the same browser URL-confidence error before returning usable state. This comment does not claim a fresh native reproduction or a repaired native path.Current verified versions:
up_to_date.@oai/sky0.7.8,@oai/browser-desktop0.1.1,@oai/cua-repl0.1.0.Read-only checks: sampled desktop, Chrome main-browser and CUA runtime processes share the same Windows interactive session, are non-elevated and have Medium integrity (RID 8192). Chrome sandbox renderers were excluded from this comparison. Desktop, Chrome, Edge, Node and Node REPL signatures validate against their vendors. Active Node, Node REPL and Sky package metadata hashes match the installed MSIX copies. This excludes an elevation mismatch for these sampled processes, not every permission problem. No binary, URL policy, access permission or internal configuration was modified.
In the new user turn, the exposed official unified tool explicitly disables native computer APIs and enables only the browser surface. A standalone native Node REPL tool is not exposed. Therefore the requested non-browser native control and native URL/state retest could not be performed. We did not invoke the native package from a shell or substitute lower-level input.
The independent official in-app Browser Use path did successfully open a public example page, return its actual URL and accessibility state, click the observed link to IANA, verify the destination URL, and capture a screenshot. The Chrome extension backend also appears in the official browser inventory. These observations do not prove native window-to-tab association or native capture is working.
Could maintainers provide a supported diagnostic route for a browser-only tool surface and identify how to distinguish URL extraction, window-to-tab association and policy-service failures? We cannot establish a local repair or the lower-level root cause from the available evidence. Native Computer Use remains unverified, while the separately authorized Browser Use path is usable.
No account identifiers, private URLs, local usernames/paths, cookies, credentials, screenshots of user content, or raw application logs are included.
tanaka-collab commentedon Oct 16, 2026
Additional Windows reproduction (2026-10-16; submitted with the account owner's authorization).
Verified environment
26.1013.3656.0.up_to_date.Observed failure
Scope and limits
Could maintainers confirm an officially supported diagnostic path for distinguishing URL acquisition, browser-window association, and safety-policy evaluation, and identify a signed Windows build that fixes this failure without weakening URL checks?
This report intentionally omits organization names, private URLs, account information, filesystem paths, identifiers, and site content.
Cvety-tmn commentedon Oct 16, 2026
Update from the same affected account, 16 October 2026.
The native Windows browser URL detection failure persists after the user fully restarted both the computer and Codex. The current Computer Use skill bundle is 26.1013.31256; this is not an independently verified desktop app version.
A fresh sky.list_apps() successfully discovered the new Microsoft Edge window. No cached window handle was reused. The first sky.get_window_state({window, include_text:true, include_screenshot:true}) immediately stopped before any page content was returned:
“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 error occurred before the reboot. No clicks, typing, navigation, messages or alternate control route were attempted after the stop. Website authentication failure has not been established.
Please provide a supported diagnostic procedure that distinguishes URL acquisition, window-to-tab association and policy evaluation, or identify an official fixed build. We are not requesting a bypass or weaker safety checks.
No private page URLs, customer data, chat transcripts, credentials, local paths, screenshots or raw logs are included.
Cvety-tmn commentedon Oct 16, 2026
A narrowly scoped addition to our existing comment, using retained evidence only; no new browser test was run.
The failed node_repl/js tool item completed at 2026-10-16T12:35:17.788Z (started 12:35:17.382Z), tool item ID exec-38d8c35b-8737-4731-93b3-8887844a380e. Its batch bound the returned Edge window and requested get_window_state(include_text:true, include_screenshot:true). It returned the URL-confidence safety stop; telemetry error_code was "unknown". No native-backend correlation ID or finer failure-stage code was exposed. Full thread/turn correlation is retained locally for private support.
Desktop updater 26.1013.31256/build20586/prod/up_to_date was independently verified later that day; this is distinct from the skill-bundle version in our earlier comment and does not independently identify the helper executing the failed call.
The official local-security documentation distinguishes extension-backed Browser Use from native Computer Use operating a browser:
https://learn.chatgpt.com/docs/enterprise/chatgpt-work-local-security#browser-sessions-and-existing-sign-ins
For this correlated refusal, what signed supported repair or content-free diagnostic identifies the failing stage, and what is the documented scope of the stop with respect to extension-backed Browser Use? We have not treated extension availability as recovery or permission to substitute another route, and have made no alternate-access attempt.
li948872431-prog commentedon Oct 16, 2026
Request for a supported recovery path, submitted with the affected user's authorization on October 17, 2026 (Asia/Shanghai).
An earlier official Windows Computer Use attempt in this environment stopped with:
"could not determine the current browser URL on Windows with enough confidence to enforce policy"
No verified URL, page body or screenshot was obtained at that stop. We retained the failure and did not run another native browser test for this support request.
We have now read the installed Computer Use skill, guidance and documented window2 API from bundle 26.1013.31256. This identifies the documentation bundle only; it does not establish the active native helper or desktop app build. The documented recovery covers lightweight-call timeouts and binding/state failures, but we found no URL-confidence-specific diagnostic or repair API. Generic ready status or window enumeration is not treated as recovery.
Could maintainers identify a signed official fix or a supported content-free diagnostic that distinguishes URL acquisition, window/tab association and policy evaluation? Please also clarify the supported recovery boundary after this specific stop. We need the policy check to succeed correctly, not to disable it.
No retry through another browser/tool, private protocol, binary patch, permission/security change, VPN change, or blind reset/restart was performed as a workaround. There is no verified private-feedback receipt to attach. Private URLs, identifiers, window titles, business information, local paths, credentials, screenshots and raw logs are omitted.
Update, 18 October 2026: a distinct own-app window association observation, not a reproduction of the earlier browser URL-confidence stop and not a claim of the same cause.
Installed documentation bundle: computer-use 26.1013.40934; active helper build not independently established. A locally built WinForms/WebView2 app was started normally. Documented sky.list_windows and get_window identified exactly one matching intended app window. get_window_state returned app/title metadata and a UIA tree consistent with the intended app, but the displayed screenshot showed a different application. An indexed click was refused by the documented tool because its point was over that other application. One documented activation + fresh-state + same-action retry produced the same refusal; input stopped, and no task was submitted.
A later read-only developer observation for the intended exact PID/start time/HWND reported a visible, enabled, responsive, non-minimized Normal window, no owner/NOACTIVATE/TOPMOST/cloaking, and foreground equal to that HWND at that later sample. This later sample does not establish hit-testing or foreground state during either refused click. After that new sample, one reselected read-only state capture still showed a mismatching screenshot with a UIA tree consistent with the intended app; no third click was performed.
No other application was operated, no private transport or alternative input/capture route was used, and no policy, permission, security, or network changes or reset/restart were performed for this observation. Is there a supported content-minimal window/capture/hit-test association diagnostic or repair? Real titles, product names and application identities, HWND/PIDs, message IDs, paths, screenshots, and raw logs are omitted.
Waterkyuu commentedon Oct 17, 2026
Additional reproduction on Windows (2026-10-17)
I encountered the same URL-confidence stop while trying to inspect an open Chrome window through the documented
@oai/skyComputer Use path.Reproduction:
sky.list_apps()returned one Google Chrome window.sky.get_window()succeeded for that returned window, and activation succeeded.sky.get_window_state({ window, include_screenshot: true, include_text: true })call stopped with:No screenshot, accessibility state, or verified active-tab URL was returned. I stopped after the error and did not click, type, navigate, or submit anything through native Computer Use.
I also tried the dedicated Chrome browser channel. The tab-binding request timed out, and the browser inventory exposed only the Codex in-app browser (with no tabs) and MCP Apps; no Chrome extension backend was listed. I cannot determine whether this is related to the native URL-confidence failure or a separate browser-backend discovery problem.
Please clarify the supported Windows recovery path and provide diagnostics that distinguish URL acquisition, window-to-tab association, and policy evaluation failures. The safety checks should remain enabled; I am not requesting a bypass.
djdjw522-lab commentedon Oct 17, 2026
Additional occurrence on 2026-10-17 (Windows, Google Chrome). This is a symptom match; the underlying cause on this machine has not been established.
Environment verified from local installed files/logs:
Sanitized log excerpt from this session's last attempt, approximately 2026-10-17 08:27 UTC (16:27 Asia/Shanghai):
No repeated initialization is being attempted now. No binary patch, private transport invocation, policy change, alternate browser tool, or project browser automation is being used to bypass the stop. Unrelated source-code work continues offline.
Please confirm an official fix or supported diagnostic procedure that preserves URL and policy enforcement. Window enumeration alone does not establish that URL detection is working.
This excerpt intentionally omits private browsing titles/URLs, account information, local user paths, cookies, credentials, and unrelated session logs. It is a sanitized event excerpt, not a complete raw session log.
Cvety-tmn commentedon Oct 17, 2026
Follow-up from the same affected account, 17 October 2026: a distinct failure in the built-in browser. We are not claiming that it has the same root cause as the native Windows URL-confidence error above.
The approved HTTPS target was https://ret.saby.ru/ (public service origin only). Browser inventory succeeded. At 2026-10-17 15:27:38.493 UTC, creating an in-app browser tab failed after about 21 seconds with:
Timed out running CDP command "Page.navigate" for tab 2Tool call:
call_467999ead04549c2b92498742d4a56dd. Tab enumeration still succeeded. At 15:27:57.075 UTC, binding that tab returnedBlocked browser navigation by Browser Use URL policy: data:...(callcall_f6e2cd66816c4a9697ebcce61470bff4). The generated error-page URL indicated ERR_TIMED_OUT; the full data URL and page contents are omitted. This does not establish that the original HTTPS origin is policy-blocked.In a later user-authorized turn, the failed tab was absent from inventory. One fresh-tab attempt through the same in-app browser to the same HTTPS origin also ended with Page.navigate timeout after approximately 21.7 seconds. We did not then read the generated error page, change policy, switch browser/control routes, or alter network settings. No customer orders were retrieved.
What supported same-in-app-browser recovery is appropriate for this sequence, and which navigation stage timed out? How can the original approved HTTPS destination be recovered without allowing or reading the generated data error page or weakening URL enforcement? If this belongs in a separate issue, please advise.
This addition contains no customer data, passwords, private infrastructure addresses, country/location details, account-specific service URLs, screenshots, or raw logs. No new application-version check was performed for these navigation attempts.
hxy286864072 commentedon Oct 18, 2026
Additional static diagnostic information, 2026-10-18. No new browser reproduction was performed.
A retained 2026-10-15 occurrence stopped at the documented @oai/sky get_window_state operation because the current Windows browser URL could not be established confidently enough to enforce policy. No browser state was returned; the product-owned capture had not executed. The retained item is a controller receipt, not the original native payload. Historical request flags, correlation ID, backend identity and numeric code remain unknown.
Current installed metadata, measured 2026-10-18 05:06 UTC:
These are installed candidates, not proof of the currently loaded backend or a fixed algorithm. Static inspection also found that the Windows nativePipe pending-response error branch constructs an Error from the message alone, discarding received code/data. Whether the historical occurrence used that branch or carried any code is unknown. No installed client/helper was modified.
Could maintainers identify the applicable supported app/client/backend combination and a content-minimal diagnostic or official repair? Useful distinctions are URL acquisition failure, window/tab association failure, unsupported about:blank/opaque-origin handling, policy denial and policy-service failure. Please clarify a supported fresh-run recovery procedure that retains URL enforcement. Desired diagnostics are typed phase/reason, numeric error/HRESULT and opaque correlation; no page content, full URL, title, profile, credentials or raw logs. No local binary patch or alternate capture/control route is requested.
Waterkyuu commentedon Oct 18, 2026
I found a workaround: using an Edge extension instead of Chrome resolves the issue. As long as I avoid using Chrome, everything works fine.
trevor94899234-maker commentedon Oct 19, 2026
Additional redacted Windows reproduction — 2026-10-19
The affected user reports that native Computer Use cannot inspect an already signed-in Chrome page, although the website works manually. The observed symptom matches this issue; the underlying cause on this machine is unconfirmed.
Environment verified during this diagnostic session
26.1013.40934, build20770, production channel. The configured updater reportedup_to_datewhen checked.OpenAI.Codex 26.1013.4894.0, status Ok. This uses different version numbering from the desktop release.26.1013.40934.155.0.8059.82.1.26.1005.11759, installed in the active Chrome profile.Retained reproduction
sky.list_windows()returned the intended Chrome window.sky.get_window()successfully bound that returned window.sky.get_window_state()stopped before returning usable page text or a screenshot:A previously requested retry after a normal Chrome restart produced the same stop, including a text-only state request. These are retained observations; no new native browser test was performed during the subsequent diagnostic review.
Read-only diagnostic findings
Three explicitly approved desktop logs from 2026-10-19 record Computer Use native pipe startup ready, multiple
node_replevents ending instatus=readywitherror=nullandfailureReason=null, and Browser Use availability on Windows. Chrome extension synchronization reportsisExtensionInstalled=true,isPluginInstalled=true,installedPluginStatus=current, andchromeExtensionSyncAction=keep_installed.These are startup/inventory observations, not proof of successful native-window/tab URL association. The selected logs did not expose the exact low-level URL-detection failure.
codex doctor --jsonreported installation consistency, configuration loading and app-server handshake as OK. It reportedCODEX_WINDOWS_REGISTERED_COREmissing only in the standalone CLI invocation; active thread overrides were not inspected, so this has not been established as the failing tool's root cause.An early plugin-cache refresh warning mentioned
unified-computer-use; subsequent inventory events reported that plugin current. No causal connection to the URL failure has been established.Request
Please identify an official signed fix, or a supported content-minimal diagnostic that distinguishes URL acquisition, native-window/tab association and policy-evaluation failure. Please clarify the supported recovery procedure after this specific stop while retaining URL verification and policy enforcement.
No raw logs, credentials, cookies, email addresses, account identifiers, private page URLs, personal filesystem paths, screenshots or conversation contents are included. No configuration, registry, permissions, runtime binaries or security controls were changed as part of this diagnostic review. Native Computer Use remains unresolved.
mrliuxinxin commentedon Oct 19, 2026
Windows Computer Use URL-detection failure
Versions: desktop app and Computer Use plugin 26.1013.40934, build 20770, production channel; @oai/sky 0.7.8; Chrome 158.0.8106.0 and Edge 155.0.4283.62. The configured updater reports up_to_date.
Window enumeration succeeds, but the first read-only get_window_state stops because the current browser URL cannot be determined with sufficient confidence to enforce policy. No input follows the safety stop.
All seven current registered bridge paths exist and remain identical after standard path normalization. This is metadata validation, not a complete helper binary comparison.
Browser Use can list a connected Chrome extension in one conversation while another reports local browser use disabled. Native failure also occurred when browser inventory was available, so a shared cause is unproven.
Current host logs, including live WAL, provide no typed failure code or resolver source in the relevant query window.
Please provide supported diagnostics identifying the failing resolution stage or a confirmed fixed build. We are not requesting any URL-policy bypass, relaxed security, or permission override.
Cvety-tmn commentedon Oct 19, 2026
Follow-up from the same affected account, 19 October 2026. This requests an actionable resolution of our retained native Windows failure, not another reproduction or a duplicate issue.
Our exact event and client tool item are already recorded here: #51524 (comment) (2026-10-16 12:35:17.382–12:35:17.788 UTC). No native-backend correlation ID or typed failure stage was exposed; error_code was "unknown".
New verified metadata: on 19 October the configured desktop updater reported installedVersion 26.1013.40934, build 20770, production, up_to_date. This does not identify the helper that executed the historical failure, prove a fresh reproduction on this release, or establish recovery. The blocked native operation has not been retried for this follow-up.
Could the Windows native URL-resolution component owner provide one actionable next step:
Please distinguish this native failure from our separate in-app navigation-timeout comment. A community extension workaround is not being treated as a repair or permission to bypass the native stop. URL verification and policy enforcement must remain enabled. No customer data, private infrastructure addresses, location details, credentials or raw logs are attached.