Repository navigation
Codex on Windows: Native Computer Use stops because it cannot determine Chrome’s current URL #43880
Description
Hello OpenAI Support,
I am reporting a reproducible issue with native Windows Computer Use in the Codex desktop app. It detects the official Google Chrome window but stops when attempting to inspect it.
Environment:
- Windows 11
- Codex MSIX package version: 26.901.6511.0
- Official Google Chrome: 152.0.7977.82
- ChatGPT Chrome extension: 1.26.901.11451, installed and enabled
- Computer Use/browser plugin version: 26.901.51231
- @oai/sky: 0.6.26
- Reproduced on September 9, 2026
Steps to reproduce:
- Enable Computer Use and Chrome control in Codex.
- Open official Google Chrome and navigate to example.com or YouTube.
- Ask Codex to inspect or operate Chrome through native Windows Computer Use.
- Chrome is successfully detected by sky.list_apps(), and get_window succeeds.
- Calling get_window_state with include_screenshot: false and include_text: true stops Computer Use with this message:
“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.”
Expected:
Codex should reliably identify the current URL in supported Chrome and continue permitted browser operations.
Actual:
Native Computer Use repeatedly stops at window inspection. This occurred on multiple websites and persisted after restarting Chrome and Codex. Manually focusing Chrome’s address bar with Ctrl+L did not resolve it.
Diagnostic findings:
- Chrome extension-based control successfully opened YouTube, entered a search, clicked Search, and read result titles and links.
- Codex’s built-in browser also completed that search workflow.
- Native desktop control successfully operated Studio Pro, including creating and saving an empty project.
- Read-only checks of the Chrome native messaging host manifest and current-user registration passed.
These results suggest the failure may involve URL detection in the native Windows browser-control path, but the root cause has not been established. Similar functionality worked for me in older versions; I do not know which update introduced this issue.
Please investigate and advise which Codex diagnostic logs or session identifiers would help isolate the failure.
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ls077969-ship-it commentedon Sep 8, 2026
Thanks for flagging #42766. It appears to describe the same failure: native Windows Computer Use detects Chrome, but stops when inspecting the window because it cannot reliably determine the current browser URL.
I can reproduce this with Codex MSIX package 26.901.6511.0, Chrome 152.0.7977.82, and ChatGPT Chrome extension 1.26.901.11451. Chrome extension-based control and the built-in browser both work, and native control of a non-browser Windows application also works.
I’ll leave this issue open pending maintainer confirmation, since it provides additional version details and diagnostic results. If #42766 is the preferred tracking issue, please feel free to consolidate this report and close it as a duplicate.
order-zero commentedon Oct 16, 2026
Additional Windows/Chrome reproduction on October 16, 2026. Chrome 155.0.8059.79; Codex initially 26.930.61225 (build 13232), then updated and restarted to 26.1013.31256 (build 20586), reporting up_to_date.
Native Computer Use can discover and select Chrome, but clicking Reload on a visible locally hosted web app stops with “could not determine the current browser URL on Windows with enough confidence to enforce policy.” The failure persists after updating and restarting. Separately, the Chrome extension can read the page URL. In-app feedback has been submitted. Is there a supported diagnostic or fixed release for this?
JDE11 commentedon Oct 17, 2026
Additional controlled navigation/readback comparison on October 17, 2026 (UTC).
Windows 11 build 26200, en-US, Chrome 146.0.7680.178, desktop app updater version 26.1013.40934/build 20770/prod, MSIX 26.1013.4894.0. The supported app updater reports up_to_date.
In one visible maximized Chrome window on a secondary monitor, two Forward/Back pairs between Example Domain and New Tab passed with a 2000 ms delay after input returned and before text-only
get_window_state(include_screenshot:false, include_text:true). The subsequent immediate Back readback in the same session failed with the URL-confidence stop. Back returned at 2026-10-17T05:53:15.286Z; readback began in that same recorded millisecond and did not return. Requested accessibility was populated before the control. The post-Back destination was not verified, and the turn ended as directed.This comparison supports investigating a navigation/readback timing issue. The small sample does not establish the internal cause, prove that all reports share a cause, or guarantee that a 2000 ms delay prevents recurrence. No native runtime implementation or policy check was changed.
Please provide either an eligible fixed desktop/runtime build or a supported diagnostic reason code distinguishing URL acquisition, transient document selection, window association, and policy evaluation. A supported readiness/retry mechanism should continue to validate the current URL. The observed delay comparison is not a request to relax URL policy.
No screenshots, private page contents, profiles, user paths, account identifiers, raw logs, or session transcripts are included in this handoff.