Repository navigation
Windows Computer Use: Chrome window state blocked by URL confidence check, including New Tab #46200
Description
Summary
Windows Computer Use can enumerate Chrome windows, but a read-only window-state request is blocked before any click or keyboard input. This prevents native window operations such as maximizing Chrome.
Environment
- Windows release: 25H2; build 26200.9457; locale: zh-TW.
- Google Chrome: 153.0.8010.48.
- Computer Use plugin: 26.911.61220. Also reproduced earlier with 26.908.70816.
- Codex / ChatGPT desktop app: exact app release version not verified.
Steps to reproduce
- Open Chrome. The latest failing test used a window titled “新分頁 - Google Chrome” (New Tab).
- In the supported Computer Use JavaScript runtime, initialize
@oai/skyand callsky.list_windows(). Chrome is returned successfully. - Select that returned Chrome window and call:
await sky.get_window_state({
window: chromeWindow, // the actual object returned by list_windows()
include_screenshot: false,
include_text: true
});Actual result
Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.
No click or keyboard action executes. The agent stops as instructed.
Expected result
Safely identify the active URL and return the permitted window state, or provide an actionable diagnostic identifying the missing prerequisite.
Additional observations
- The error occurred on both an X broadcast page and a Chrome New Tab window.
- Browser-extension control previously read the actual Chrome tab URL and interacted with page controls. Native Windows window control is the failing path.
- Earlier OBS native desktop control worked.
- Chrome was present in the session allowed-app list during earlier checks; this does not establish that every permission layer is currently valid.
- The underlying cause is unknown. There is no evidence identifying antivirus software as the cause. No safety checks were disabled or bypassed.
- A desktop-app restart was suggested, but a complete restart was not independently verified.
Is this a known URL-extraction compatibility issue? What supported diagnostic or recovery procedure should be used while preserving the URL safety check?
This report was prepared with Codex assistance from observed tool responses. Personal paths, registration tokens, unrelated browsing content, raw logs, and the full conversation are omitted.
Activity
github-actions commentedon Sep 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hutaao commentedon Sep 19, 2026
I can also reproduce this issue with Google Chrome 153.0.8010.53, Codex desktop app 26.915.4065.0, Computer Use plugin 26.915.31945, @oai/sky 0.7.1, and CUA runtime 0.0.16 on Windows 11 25H2 build 26200.9457. Chrome is successfully returned by sky.list_windows(), but sky.get_window_state() stops immediately with the same URL-confidence error, including on the New Tab page. Native Computer Use works normally with Windows File Explorer, and the browser-extension path works with Edge. I posted the fuller environment and control-test results in #45996.
bushido54 commentedon Oct 10, 2026
Additional reproduction: separate activation succeeds; window-state capture stops (2026-10-11)
I can reproduce the same Windows native URL-confidence stop. The browser extension can read the target page, while the native state request is stopped. This report was prepared with Codex assistance from observed tool responses. No security checks were bypassed or modified.
Environment
Previously collected on 2026-10-10:
Manually checked by the user on 2026-10-11:
Latest reproduction
Example Domain.activate_windowcall completed successfully.get_window_state(include_screenshot=true, include_text=true)call stopped immediately:The turn ended immediately as instructed. No subsequent tool operations or browser-zoom input occurred that turn. This isolates the failing public call, not the internal failure stage.
Control and earlier observations
no screenshot targets found. After reselecting and activating it, one state call returned one screenshot; its text tree remained empty. No text was entered and no existing documents were read. This is limited evidence for that capture call, not proof of a unique cause or general Computer Use health.correct=true; registry and manifest paths matched. The diagnostic initially selected Profile 2 without the extension, while Default had it installed/enabled.chrome://version/is not an allowed protocol. No equivalent workaround was attempted; the user supplied the version manually. This is distinct from the native URL-confidence stop.Request
Please provide supported, privacy-preserving diagnostics that distinguish browser document discovery, URL extraction, native window-to-tab association, and policy initialization/evaluation. Please specify any minimal redacted diagnostic data needed while keeping URL policy checks enabled.
The root cause remains unknown. These observations do not prove that zh-TW, a Chrome version, empty Notepad text output, or a particular website is the cause. Native 200% browser zoom acceptance remains unverified. Personal paths, account data, private project details, raw logs and full conversation content are omitted.