Skip to content

Windows Codex CLI Computer Use cannot determine Chrome URL after Chrome Browser Use confirms active NAVER tab #40474

Open
Open
Windows Codex CLI Computer Use cannot determine Chrome URL after Chrome Browser Use confirms active NAVER tab#40474
Labels
CLIIssues related to the Codex CLIbrowserbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

Description

@Daikisong
Daikisong
opened on Aug 24, 2026

Summary

On Windows, Codex CLI Computer Use can initialize its standalone @oai/sky
helper and discover the active Chrome window, but the first read-only
get_window_state request terminates the turn because it cannot determine the
current browser URL. In the same fresh Codex session, Chrome Browser Use can
open the same URL, confirm its final origin, inspect its DOM, and identify the
active tab successfully.

This is a current CLI/standalone-helper reproduction of the URL-detection
failure reported in #25271 and recently observed again in #40048.

Environment

  • Windows NT 10.0.26200 x64
  • Codex CLI 0.149.1
  • Codex app package 26.818.8289.0 (installed, status OK; not required to stay open)
  • Bundled Chrome and Computer Use plugins 26.818.61809
  • @oai/sky 0.6.17-202608171537-pr-1300023-7efba775c041
  • Google Chrome 151.0.7922.170
  • Codex Chrome extension 1.2.27268.51612_0, installed and enabled
  • ChatGPT Pro

Reproduction

  1. Start a fresh normal Codex CLI session with the standalone Computer Use
    configuration (SKY_CUA_NATIVE_PIPE=0).
  2. Run the Browser Use runtime preflight. It exits 0.
  3. Through the bundled Chrome Browser Use plugin, select Chrome and call the
    real openTabs() RPC. It succeeds.
  4. Create one disposable controlled tab and navigate to
    https://www.naver.com/.
  5. Confirm through Chrome Browser Use that:
    • the final origin is exactly https://www.naver.com;
    • the title is NAVER;
    • recognizable Naver search/logo DOM elements are present;
    • the disposable tab is active.
  6. Initialize Computer Use normally with await import("@oai/sky").
  7. Call list_apps()/list_windows(). Computer Use successfully returns one
    targetable NAVER - Chrome window.
  8. Call exactly one read-only get_window_state request for that returned
    window, with screenshot capture and no click, typing, keypress, scroll,
    activation, or retry.

Actual result

The read-only state request fails immediately 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. Stop your work and send a final message noting why Computer Use ended.

The standalone helper connection and window discovery both succeeded. No input
action occurred. The disposable test tab was then closed through its original
Chrome Browser Use binding.

Expected result

Computer Use should obtain enough URL evidence to enforce policy and return the
read-only window state. When the bundled Chrome extension/Browser Use binding
already knows the active controlled tab and its final URL, the Windows Computer
Use URL check should be able to correlate that trusted tab information with the
target Chrome window instead of terminating before capture.

Notes

  • This is not a Naver origin denial: Chrome Browser Use navigated to and
    inspected the origin successfully in the same test.
  • This is not a missing native pipe: standalone @oai/sky initialization and
    Chrome window discovery both succeeded.
  • Restarting Codex or Chrome is not a reliable remedy; the failure occurs in a
    fresh CLI session after a clean preflight.

Activity

  1. github-actions commented on Aug 24, 2026

    @github-actions
    github-actionsbot
    on Aug 24, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  2. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    computer-use
    browser
    on Aug 24, 2026

  3. search620 commented on Aug 29, 2026

    @search620
    search620
    on Aug 29, 2026 – with ChatGPT Codex Connector

    This current-build reproduction matches the universal root cause isolated and validated in #25271.

    This is not another reproduction or workaround. The underlying Windows failure persisted across many Computer Use release generations. The duplicate and PR searches found no earlier public implementation-level fix. The linked result identifies the controlling helper defect, patches it, and verifies the original failure path in a fresh session.

    The Windows Computer Use helper identified Document nodes by comparing a UI Automation text label with the literal string document. Text labels are not stable control identifiers, so the Document node was skipped and the browser URL cache remained empty.

    The v8 root fix removes text-label matching entirely and uses:

    IUIAutomationElement::get_CurrentControlType == UIA_DocumentControlTypeId (50030)

    at RVA 0x1C046. After the change, sky.get_window_state() recognized the Chrome page Document and passed URL-confidence enforcement independently of the Windows or Chrome UI language.

    The full sanitized implementation evidence, including the related geometry/focus/UIA synchronization fixes and fresh-session AUDIT, is here:

    #25271 (comment)

    The final helper SHA-256 used for verification was 956b3897ff4dbec3999225d51c1a54013e78231b5ac9171f3b1dfd2beaaf3105. No executable, installed binary, user path, account data, tab/task identifier, or token is attached.

  4. AntMesh commented on Oct 1, 2026

    @AntMesh
    AntMesh
    on Oct 1, 2026 – with ChatGPT Codex Connector

    Additional read-only reproduction on Windows 11 26H2 with Computer Use bundle 26.928.31416. Browser Use succeeds while the first native window-state read is stopped during URL determination.

    Evidence compiled on 2026-10-01. This report identifies the failing stage, not a confirmed underlying cause.

    Observed behavior
    Chrome Browser Use through the official extension returns the expected HTTPS URL, page title and DOM. After bringing that tab to the foreground, native window discovery returns a unique Chrome window with the matching page title. Native get_window and activate_window succeed. The first read-only get_window_state then stops the turn with this actual tool return:

    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 failed call uses the official @oai/sky library through mcp__node_repl__js:
    await sky.get_window_state({ window, include_screenshot: false, include_text: true });
    The window argument is the fresh returned Window object for the uniquely matched Chrome window.

    No state text or screenshot is returned by that call. No credential entry, upload, download or file dialog is attempted in these diagnostic runs. The turn is stopped immediately as instructed by the tool.

    Environment

    • Windows 11 Pro, 26H2, OS version 10.0.26300, full build 26300.9457, 64-bit. Read from Win32_OperatingSystem and the Windows version registry.
    • Desktop updater readback: version 26.928.31416, build 12553, prod channel, up_to_date at the earlier recorded check. This is a point-in-time result, not a claim about a future release.
    • Running desktop MSIX package: OpenAI.Codex_26.928.3736.0_x64.
    • Computer Use bundle directory version: 26.928.31416. Exact @oai/sky package version was not captured.
    • Chrome product version: 154.0.8037.58.
    • Chrome extension exact version: not captured; Browser Use worked in the tested Chrome session.

    Reproduction coverage

    • A private HTTPS pre-release gate reproduces the failure with Computer Use bundle 26.928.31416. Only the gate was read; no login was performed. The private hostname is omitted from this public draft.
    • A separate fresh chat reproduces the same failure, so a problem confined to the original chat is insufficient to explain the observations.
    • The fresh chat ran from 2026-10-01 15:26:34 to 15:28:45 Asia/Shanghai (UTC+08:00), equivalent to 07:26:34 to 07:28:45 UTC. These are the enclosing turn times, not an exact timestamp for the failed native call.
    • An earlier public control on https://example.com/ also failed, using bundle 26.928.21956 and include_screenshot=true, include_text=false. The public control has not been repeated on 26.928.31416. Do not attribute its result to the newer bundle.

    Read-only configuration findings

    • User config has no explicit browser_use, computer_use or related surface feature settings and no named/selected profile settings.
    • The documented Windows system requirements.toml location has no file.
    • The documented Windows legacy managed_config.toml location has no file.
    • This project's .codex/config.toml has no file.
    • These are later on-disk observations. They do not prove the final policy loaded in the failed process. Cloud-managed requirements, saved app/site approval decisions, startup overrides, and the native check's effective policy have not been fully verified.
    • No policy, safety setting, browser flag or executable has been modified for diagnosis.

    Other evidence and limits

    • The registered and running Codex CLI executable paths differ, but their file SHA-256 values are identical. The path difference alone does not establish a binary version conflict. Other dependencies are not proven identical by this comparison.
    • Native-host registration metadata contains a stale presence record. It is cached metadata and does not prove the live binding or explain this URL failure.
    • Browser-returned URL and external title matching do not establish which URL, if any, the native safety check acquired or whether it associated that value with the target window.
    • The raw tool error does not report an explicit origin-policy denial. It does not establish that a correct native URL was obtained and rejected.

    Related public reports, verified Open on 2026-10-01

    Requested maintainer diagnosis
    Please inspect correlated private feedback/session logs to determine whether the native URL check obtained a candidate URL, whether it associated that candidate with the selected native window, and the specific reason the check stopped. Please distinguish URL determination failure from an explicit site-policy denial and identify a supported recovery path or fix that preserves URL validation.

    Feedback status and references
    No official feedback submission ID exists yet. Session/turn/call correlation details are kept separately in local diagnostic evidence for optional private feedback, not this public draft.
    Official submission guidance: https://learn.chatgpt.com/docs/reference/troubleshooting
    Managed policy locations and layering: https://learn.chatgpt.com/docs/enterprise/managed-configuration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbrowserbugSomething isn't workingcomputer-usewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions