Windows Computer Use: Chrome window state blocked by URL confidence check, including New Tab

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

1. Open Chrome. The latest failing test used a window titled “新分頁 - Google Chrome” (New Tab).
2. In the supported Computer Use JavaScript runtime, initialize @oai/sky and call sky.list_windows(). Chrome is returned successfully.
3. 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.

Reproduce the failure in the supported JavaScript runtime using @oai/sky.list_windows() followed by sky.get_window_state() on a Chrome window, including New Tab. Start by tracing the Windows URL-confidence check and its diagnostics; done means the permitted state is returned or an actionable prerequisite is reported without disabling the safety check.