This is fucking stupid: Computer Use refuses to use the browser just because it cannot identify the address bar

Start with src\policy\url_policy.rs and trace how Windows UI Automation candidates are selected and how the “could not determine” error is reached. Reproduce the overlapping AddressBarView and AddressTextfieldView case in Opera, then inspect the existing URL-policy tests. Done means valid HTTPS candidates are handled without terminating the turn and a Chromium-browser regression test covers the duplicate address-bar elements.

What version of the Codex App are you using?

Codex App: 26.715.9868.0

Computer Use plugin: openai-bundled/computer-use/26.715.72028

What subscription do you have?

Not specified

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Opera: 132.0.5905.114

What issue are you seeing?

Computer Use correctly discovers a unique Opera window on Windows:

{
  "app": "process:C:\\Program Files\\Opera\\opera.exe",
  "id": 2431952,
  "title": "微博 – 随时随地发现新鲜事 - Opera"
}

The browser is already logged in and displaying a normal HTTPS page. The user explicitly asks Codex to control this exact window and upload a specific video.

However, the first attempt to capture the window state with sky.get_window_state() immediately terminates the entire Computer Use turn:

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 failure occurs before any screenshot, click, text entry, upload or submission.

A separate attempt to focus the address bar with sky.press_key({ key: "Control_L+l" }) is also terminated before the key is executed.

This is not because Opera fails to expose its current URL. A direct read-only inspection of the same window through Windows UI Automation finds two overlapping editable elements representing the same visible address bar:

Name: 地址栏
AutomationId: view_1013
ClassName: AddressBarView
FrameworkId: Chrome
ControlType: Edit
Value:
IsOffscreen: False
IsEnabled: True
Bounds: 253,172,1003,29

Name: 地址栏
AutomationId: view_1005
ClassName: AddressTextfieldView
FrameworkId: Chrome
ControlType: Edit
Value: https://channels.weixin.qq.com/...
IsOffscreen: False
IsEnabled: True
Bounds: 298,172,954,29

The empty element is the outer AddressBarView container. The inner AddressTextfieldView contains a valid HTTPS URL and occupies the same visible address bar.

Computer Use appears to select the first editable element named “地址栏”, read the empty value from the outer container, and stop without checking the inner text field or any other valid URL candidate.

The executable contains a dedicated URL-policy implementation at:

src\policy\url_policy.rs

It also has separate errors for unsupported browsers, blocked URLs, unverifiable URLs and URLs that cannot be determined with sufficient confidence. This case reaches the “could not determine” branch even though Windows UI Automation exposes a valid URL.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows with Computer Use enabled
2. Open Opera using a normal user profile
3. Navigate to a normal HTTPS page and log in
4. Ask Codex to control the currently visible Opera window
5. Run sky.list_windows()
6. Confirm that exactly one Opera window is returned with the correct page title
7. Rehydrate that returned window using sky.get_window()
8. Call sky.get_window_state() with screenshot or accessibility text enabled
9. Observe that Computer Use terminates the entire turn before returning the window state
10. Inspect the same Opera window through Windows UI Automation
11. Observe an outer empty AddressBarView and an overlapping inner AddressTextfieldView containing the valid URL

What is the expected behavior?

Computer Use should inspect all plausible address-bar candidates instead of stopping after the first empty editable element.

At minimum, URL selection should:

• Prefer AddressTextfieldView over the outer AddressBarView
• Ignore empty container values when another overlapping candidate contains a valid URL
• Validate candidates by parsing non-empty HTTP or HTTPS values
• Associate the chosen address field with the active browser window
• Add a regression test for Chromium-based browsers that expose both an outer address-bar container and an inner text field
• Return a recoverable diagnostic or user-confirmable fallback instead of terminating the entire turn when a valid candidate exists

The current behavior turns a URL-extraction bug into a non-overridable safety failure and makes all Computer Use actions impossible in the affected browser, including harmless screenshot capture and address-bar focus.

Related issues

• #25271 — Computer Use cannot determine Chrome URL on Windows
• #31007 — Computer Use cannot be used with Microsoft Edge
• #31221 — Edge URL detection fails even though Windows UI Automation can read the address bar