Repository navigation
Windows Computer Use cannot determine the current Microsoft Edge 151 URL on Windows 11 #45996
Description
Environment
- ChatGPT/Codex desktop:
26.908.9136.0 - Windows Computer Use JS package:
@oai/sky 0.6.32 - Windows 11:
25H2, build26200.9457 - Microsoft Edge:
151.0.4129.107
Actual behavior
When the official Windows Computer Use API targets the unique live Edge window and calls get_window_state, the turn stops with:
Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.
Minimal reproduction
- Open
https://example.com/in Microsoft Edge. - Use
sky.list_windows()and select the single returnedMSEdgewindow. - Rehydrate that exact returned window with
sky.get_window(), activate it, and callsky.get_window_state({ window, include_screenshot: true, include_text: true }). - The URL-confidence error occurs before any screenshot or input can proceed.
Expected behavior
Computer Use should confirm the visible HTTPS URL and return the Edge window state while preserving the URL safety check.
Diagnostics completed
- Windows UI Automation reads the full visible HTTPS URL from Edge's omnibox (
AutomationId: view_1021,ClassName: OmniboxViewViews). - The visible
RootWebAreaURL matches the omnibox URL. - The failure also reproduces on
example.com, so page iframes are not the cause. - It reproduces with the Computer Use locale set to both
zh-CNanden-US; the original setting was restored. - Codex restart, fresh native pipe, fresh JavaScript sessions, and fresh live-window enumeration do not resolve it.
- Installed Computer Use binaries and JS client match the current official Codex package.
- The Edge browser-extension control path works, but it is a separate path and does not repair Windows Computer Use URL recognition.
Impact
Windows Computer Use cannot control Edge on this machine, including a simple search and page translation. Other Windows desktop-app control works, so the failure is isolated to browser URL recognition.
Reproduction identifiers
- Codex session ID:
01a08c3f-613e-71a0-be3e-4d78e18248c2 - Reproduction turn ID:
01a0ab16-9e50-7d93-a300-c89f3f8b33d8
A redacted diagnostic PDF containing exact reproduction events, environment details, sandbox-log evidence, and source hashes was already submitted privately through OpenAI Support. It can be provided privately to the engineering team if needed.
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
lyx9178 commentedon Sep 18, 2026
补充当前 Windows 版本的复现和只读检查结果。目标是在保留中文 Windows 与网址权限检查的前提下恢复原生 Computer Use。
环境：Windows 显示语言 zh-CN；Codex AppX 26.908.9136.0；内部应用及 Computer Use 组件 26.908.70816；@oai/sky 0.6.32；Edge 153.0.4234.32。
通过官方 @oai/sky 接口，可以枚举并唯一选择 Edge 窗口。刷新窗口对象并显式激活后，get_window_state({include_screenshot:false,include_text:true}) 仍因无法可靠确定当前浏览器网址而停止。收到停止信息后，没有继续该轮原生浏览器操作。
独立对照结果：
当前 helper 的只读静态检查发现：元素属性收集调用 get_CachedLocalizedControlType，保存非空的本地化名称；网页识别路径随后将该名称与英文 document 比较，成功后才进入后续页面值及网址记录逻辑。接口方法与本机 Windows SDK 10.0.26100.0 的 IUIAutomationElement 声明交叉核对过。Microsoft 的 Document 控件编号为不依赖语言的 UIA_DocumentControlTypeId / 50030。
这些结果确认当前构建仍有语言相关的控件选择逻辑，但没有通过其他控制通道读取被拒绝的 Edge 节点，因此不能证明它是本机失败的唯一原因。没有修改执行文件、伪造网址、替换传输协议、关闭网址检查或改变 Windows 显示语言。
请维护者确认以下事项：
截至 2026-09-18 的检查，正式更新清单显示 26.915.3509.0，但实际官方下载包仍与此前旧包相同，商店检查未提供可安装升级。这是检查时状态，不代表之后的发布情况。
报告由工具辅助整理。未附个人截图、原始日志、凭据、账号标识、私人网址或个人文件路径。
hutaao commentedon Sep 19, 2026
I can reproduce the same URL-confidence failure on newer Codex and browser builds. The failure also occurs with Chrome, so it does not appear to be limited to Edge 151.
Environment
@oai/sky: 0.7.10.0.16/20260915001755-492f19756c31Reproduction
sky.list_windows()successfully enumerates the browser window.sky.get_window_state()on that window stops the turn with:The same failure occurs with a newly started Chrome window on the New Tab page.
Control tests
This appears related to the browser-specific native URL recognition or policy-check path, but I have not identified the underlying cause. It also appears related to #46200.
Is there any additional supported diagnostic data I can collect for the maintainers, preferably through a private channel if it may contain sensitive information?
shadowmla commentedon Sep 23, 2026
Windows native Computer Use still uses a localized role string to select the root URL in the current signed component
Native Computer Use can enumerate and activate a Chrome window showing
https://example.com/, butsky.get_window_state({window, include_screenshot:false, include_text:true})ends the turn with the URL-confidence error. Browser-extension success is a separate observation and is not counted as native acceptance.Reproduction and version
@oai/sky0.7.1; Chrome 153.0.8010.53.The instruction was followed. No alternate channel was used to read the refused native page, and no further native input was sent that turn.
Read-only static findings in the current official binary
The component resolved by the running desktop application's startup log is byte-identical to the component in the installed official application package. Authenticode is Valid, signed by OpenAI OpCo, LLC. File size: 1,550,128 bytes. SHA256:
b49b868226c9eb6ab0c1a00903f7b3c7188f5ecc8c59a23488f83dc6ddf1ebc4Read-only disassembly, PE parsing and Windows SDK interface declarations establish this path:
IUIAutomationElement::get_CachedLocalizedControlTypestring. It callsget_CachedControlTypeand maps the numeric type to an invariant English role only when the localized string failed or was empty.IUIAutomationValuePattern::CurrentValue, then requires the node role to equal ASCII case-insensitivedocumentand CachedAutomationId to equalrootwebareabefore preserving a nonempty candidate URL.0x8000000000000002.Thus a nonempty localized Document role that is not the English word
documenthas a static reachable path to this exact failure even when the stable UIA ControlType is Document (50030). The invariant numeric-to-document mapping already exists, but the normal nonempty localized value prevents it from being used.This is not merely a comparison used for display text or body extraction: the checked value controls whether the RootWebArea URL candidate is retained. This also distinguishes the current confidence error from the separate “could not verify whether the current browser URL is allowed” error.
Confidence boundary
The static defect and path exist in this exact current official component. We have not dynamically captured the failing Chrome element's LocalizedControlType value, because the supported native tool stopped before exposing it. This report does not claim that every occurrence of this error has this one cause. Community reports include both locale-dependent recoveries and failures where the role was already English.
No component was patched, replaced, separately executed or attached to a custom client. No check, identity, permission or policy gate was changed. No Windows display-language or licensing change was made.
Requested product fix and diagnostics
Please use the invariant
UIA_DocumentControlTypeId(50030) for semantic root-document selection, retaining localized names only for display. Preserve root/active-window association, actual URL acquisition, URL validation and all current URL permission checks, including stopping when identity or URL remains ambiguous.Please supply a fixed official build or a supported diagnostic that returns only the failed stage/reason: window match, Document selection, ValuePattern availability, nonempty URL, active-root association, URL parse, or policy request/verdict. Booleans/reason codes can provide useful evidence without exposing URLs, page text or account data.
Suggested validation: native ordinary HTTPS navigation and click/readback on en-US and zh-CN; localized role text with stable type 50030; non-Document controls; missing/ambiguous/invalid URL values; denied URLs; policy initialization failure. Incorrect or unavailable URL evidence must continue to stop rather than silently allow access.
Related: #45996 and #46200. Local findings corroborate the narrow localized-role issue described in comment 5727020799 on #45996, with an updated official-binary identity.
arriannayfq commentedon Sep 23, 2026
Additional read-only reproduction on a different Windows build (2026-09-23):
@oai/sky0.7.1.b49b868226c9eb6ab0c1a00903f7b3c7188f5ecc8c59a23488f83dc6ddf1ebc4; Authenticode Valid, OpenAI OpCo, LLC).Using only the supported
node_repl/@oai/skypath,list_apps()returned exactly one Edge window. After selecting that returned window, the minimalget_window→activate_window→get_window_state({ include_screenshot: false, include_text: true })cell stopped with:No screenshot, accessibility tree, click, or keyboard input followed. A previous attempt on the same Edge window had the same error after fresh enumeration. Changing the window's displayed page/title did not resolve it. No browser, system-language, proxy, security, or helper setting was changed for this reproduction.
The identical helper hash means the localized-role code path described above is present in this installation. We have not observed the failing element's
LocalizedControlTypethrough the supported tool, so we cannot confirm that this is the sole dynamic cause. Could maintainers confirm whether an official fixed build or supported, privacy-preserving stage/reason diagnostic is available? The URL acquisition and permission checks should remain enforced.arriannayfq commentedon Sep 24, 2026
Follow-up on 2026-09-24: persists after the app/plugin update; requesting Windows Computer Use engineering triage
Following up on my earlier reproduction in comment 5798084888. This is blocking inspection and verification of actual browser-based project workflows.
Updated, locally verified environment
26.917.8451.0.26.917.62051;@oai/sky 0.7.1.0.0.16/20260915001755-492f19756c31.Current supported-API reproduction
Fresh
sky.list_apps()/sky.list_windows()enumeration identifies a Chrome window. Rehydrating that exact window, activating it after a minimized-state indication, rehydrating again, and callingget_window_state({ include_screenshot: false, include_text: true })still stops with the current-browser-URL confidence error. Native browser work stopped immediately after that rejection. This latest reproduction used an existing browser window; it is not claimed as a new isolated example.com test.New component identity and static corroboration
The installed host's native-pipe routing resolves the legacy
codex-computer-use.exe, while the coexisting Swift executable belongs to a separate capture integration. A fresh legacy helper process also appeared after the supported SDK enumeration. The legacy runtime executable and its counterpart in the installed AppX are byte-identical, 1,550,128 bytes, Authenticode Valid / OpenAI OpCo, LLC:2AA2A7A93F5CF48399987CA0959DE5588293E6C7F04B68860812FA3D5412598CRead-only static analysis of this updated binary corroborates the localized-role defect described above:
0x14002052b, node construction callsget_CachedLocalizedControlType. A successful nonempty value is retained; numericget_CachedControlTypeis only a fallback.0x14001c2d6–0x14001c2eacompares that role with ASCIIdocument. It additionally requires trimmed AutomationIdrootwebarea. ValuePattern CurrentValue has an additional fallback, so CurrentValue success alone is not a mandatory condition.0x14007710e, before normal URL-policy processing.UIA interface slots were cross-checked against Microsoft's UIAutomationClient.h. A nonempty localized role other than English
documentcan therefore exclude a genuine Document/50030 root. We have not obtained the rejected node's actual property values through the supported tool, so this is not a claim that this is the sole dynamic cause of this machine's failure.Questions for the owning team
The proposed correction is semantic selection by invariant
UIA_DocumentControlTypeId (50030), retaining localized labels for display and preserving actual URL acquisition, active-window association, validation, permission checks, and stopping on ambiguity.This feedback contains only versions, a component hash, error-stage information, and static findings. No project URLs, window titles, screenshots, raw logs, account identifiers, or private files are included. No executable, policy check, system language, or security setting was modified.
AurexLB commentedon Sep 26, 2026
Additional controlled reproduction from Windows, adding a Chrome/Edge comparison and foreground-timing evidence.
Environment
26.924.2738.026.924.221380.158.0-alpha.2.1154.0.8037.58153.0.4234.48codex-computer-use.exeResult
Browser Control resolves the active tab URL correctly in both Chrome and Edge:
https://example.com/But native Computer Use
get_window_statefails in both browsers with the same error:The failing Computer Use request returns no URL. This does not establish whether the native layer failed to acquire a URL or acquired one and then rejected it.
Strict Edge reproduction
A single automated flow was used, with no human window switching between foreground confirmation and the Computer Use request.
2295080/0x230528232082026-09-26T13:07:24.6645401Zget_window_stateinvoked:2026-09-26T13:07:24.685Z2026-09-26T13:07:24.728ZThis rules out the earlier test artifact where focus had returned to ChatGPT before the request.
Other controls already verified
https://example.com/Native diagnostic limitation
Read-only inspection of the installed runtime shows the default Computer Use pipe resolves to the Rust
codex-computer-use.exe; the binary contains a reference tosrc/policy/url_policy.rsand the refusal text. Those are only static navigation clues.The forwarding layer surfaces the generic error string, while the available logs do not expose:
So the current distribution does not let us distinguish "URL acquisition failed" from "URL was acquired but rejected as insufficiently trustworthy."
Request
Could a maintainer please provide one of the following?
We are not asking to bypass or lower BrowserURLPolicy. The goal is to preserve the current safety decision while exposing enough diagnostics to identify the failing stage.
fjsfry commentedon Sep 27, 2026
Additional Windows diagnostic evidence for the URL-confidence STOP, collected on 2026-09-28 (UTC+08):
26.924.22138, build11645, prod. The official updater reportsup_to_date.26.924.2738.0. Running Chrome file version:153.0.8010.53.0.158.0-alpha.2.1:codex doctor --summary --ascii --no-colorexited 0. It reports a consistent installation, configured authentication, healthy state databases, and successful desktop app-server initialization. These are general health checks, not a successful native browser URL check.codex doctor --jsonexited 0 and reported the same CDN reachable with HTTP 200. No network settings were changed. This transient warning has not been established as the cause.Could a maintainer provide either a fixed desktop build or a supported, read-only diagnostic procedure for the native browser URL-confidence decision? In particular, is there a safe way to obtain a reason code distinguishing URL extraction failure from native-window/tab association failure, without exposing browsing data or disabling enforcement?
I have not included session transcripts, account details, credentials, browsing contents, or project data.
stanchien-tw commentedon Sep 28, 2026
I am also experiencing this exact Computer Use URL-verification error on Windows with Microsoft Edge.
I have already submitted feedback:
01a0a36c-ca18-79c2-bcdc-bd010286c7aa
Repeated read-only attempts to identify the current browser URL stopped with the same error. This is blocking a browser-based validation workflow.
Could a maintainer link this feedback to the investigation and advise whether a fixed release or a supported recovery procedure is available?
We have respected the tool's stop instruction and have not bypassed the URL safety checks.
stanchien-tw commentedon Sep 28, 2026
Environment clarification for my report: I am using Windows 10, not Windows 11. My browser is Microsoft Edge; its exact version has not yet been collected.
The Windows 11 / Edge 151 environment in the issue title belongs to the original reporter and should not be attributed to my report.
My feedback/session ID is:
01a0a36c-ca18-79c2-bcdc-bd010286c7aa
I encounter the same current-browser-URL verification error on Windows 10.
HaoYue1027 commentedon Oct 2, 2026
Additional current-build reproduction: native Edge URL detection still fails on desktop package 26.930.2377.0 and @oai/sky 0.7.5, while Browser Use works after enabling TUN and starting a fresh CUA JavaScript session.
Environment
Observed native sequence
Work stopped immediately. No alternate control path was used after the stop to read the refused native page or continue interaction.
Controls collected before the final stop
Interpretation and request
The remaining observed failure is in the native browser URL-confidence path. This report does not identify the internal failing stage or prove that network policy, document selection, URL extraction or active-window association is the sole cause.
The localized Document-role analysis in comment #45996 (comment) is relevant, but its analyzed helper hash differs from ours. We have not disassembled this helper or captured the rejected element's localized role; therefore we do not claim that analysis proves the root cause of this build.
Could maintainers provide a fixed official Windows build, or a supported read-only diagnostic returning failed-stage/reason codes for document selection, URL extraction, active-window association, parsing and policy evaluation? Please retain real URL acquisition, validation, permissions and stopping on ambiguity. Native read/click/readback checks on ordinary HTTPS pages across en-US and zh-CN would help verify a fix.
No URL checks, security policy, system language or native helper were modified. This report omits personal paths, account information, private URLs, credentials, screenshots and raw session logs.
K230GT commentedon Oct 3, 2026
Additional reproduction on newer desktop/plugin builds, observed on 2026-10-03 at 04:36:55 UTC (12:36:55 Asia/Shanghai).
Feedback ID:
01a10000-963c-7b40-876d-5989902594b7(submitted through/feedback).Environment
26300.955026.930.3748.026.930.31428154.0.8037.93@oai/skyversions were not independently reverified in this run.Minimal reproduction and controls
@oai/skyAPI.charmap.exe) returns a screenshot and an accessibility tree with 27 indexed controls. Clicking its indexed Close control with the fresh screenshot ID succeeds; a fresh window inventory confirms it closed.https://example.com/and verify its title and URL.list_windows()returns exactly one matching window titledExample Domain - Google Chrome. Rehydrate that returned window usingget_window(), then activate it.The call stops with the same error:
No native browser screenshot is returned. No further application input or retry was attempted after this stop.
An initial mismatch between the extension-created test tab and the visible native window was corrected before this failing call: the visible window's original blank tab was navigated to the public URL, and the native window title was verified again.
The browser-extension path works. The same URL-confidence failure was previously observed with Chrome and Edge on app package
26.930.2377.0/ plugin bundle26.930.21537; a verified full app/helper restart, screenshot-only requests, and separate activation/state calls did not resolve it. Only Chrome was retested in the latest run.This confirms persistence after the app/plugin update and in a new conversation; it does not establish an OS-wide accessibility failure or the internal cause. Could maintainers identify the supported native Computer Use diagnostics needed for this URL-recognition failure?
Zachariah-Jack commentedon Oct 5, 2026
October 5, 2026: Edge New Tab captures fail URL-confidence verification; later capture succeeds
Adding a Windows / Microsoft Edge observation to this issue. The native Computer Use call stopped before returning a screenshot. This also interrupted an ordinary close-window workflow because the required observation failed before the last window's close command.
Environment and scope
@oai/skyAPI.sky.get_window_state({ window, include_screenshot: true, include_text: false }).Observed sequence
Exact safe error:
Interpretation and limits
The successful request used an outer tool-call description explicitly saying this was a newly opened Edge start page with a user-reported blank address bar. That is a difference between the attempts, not an established fix: approximately 21 minutes also elapsed after the previous failure, other state was not controlled, and no crossover test was performed. We have not established that a tool-call title, New Tab state, or any particular URL-extraction mechanism caused the result.
The File Explorer and Edge captures targeted different windows. They do not isolate browser-open state as the cause. The one later Edge success does not establish durable recovery or successful general browser automation.
This symptom is separate from an earlier Browser Use administrator-policy-verification-unavailable error. A common cause has not been established.
Expected behavior: identify the actual permitted browser state and return the requested capture while preserving URL enforcement; when identification fails, expose a supported, privacy-preserving failed-stage diagnostic. Please investigate the inconsistent result for an Edge start page and clarify how to distinguish URL acquisition, native-window association and policy-verification failures.
Private account and window titles, window identifiers, paths, task IDs, raw logs and screenshots are omitted. No attachment is proposed.
Current version snapshot (collected after the incidents)
Read-only inventory on October 5, 2026, UTC:
26.930.4958.0, x64, verified at 17:50:10 from the package manifest associated with the running executable.26200.9550, x64, observed at 17:48:18.154.0.4258.53, observed at 17:47:09.These are later local-environment measurements, not verified incident-time versions or a new reproduction on these builds. They do not identify the hosted dot/controller/backend build. Active extension and bundled-agent versions remain unverified.
Written by Aria, the user's AI assistant, at the user's request.