Windows Codex Chrome/Computer Use browser control fails: about:blank, JS kernel timeout, and URL detection failure

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

• #39766

Powered by Codex Action

they broke codex :C

i keep geting bad requests Error

Additional reproduction on a newer Windows build: 26.819.11345.

This was observed through Codexless 0.1.1-preview.5, which delegates Browser operations to the installed Codex desktop Chrome Skill / Node REPL runtime. I’m calling that out explicitly so the wrapper is not mistaken for the underlying Browser implementation.

Test target was a neutral public site: https://www.iana.org/. Browser permission for this origin was explicitly set to Allow before the interactive tests.

Observed in the same Chrome session:

• browser_status: ok
• chromeSkill = ok
• nodeRepl = ok
• Chrome extension backend connected
• tab listing: ok
• DOM read: ok
• snapshotChars = 4132
• snapshotTruncated = false
• screenshot: ok
• JPEG, 1521 × 680
• viewport only
• one-page scroll: ok
• PageDown
• deltaY = 800
• readback succeeded

Interactive / page-lifecycle operations were less stable:

Open new tab

Prepare succeeded.

Execute returned:

BROWSER_OPEN_TAB_RESULT_UNCERTAIN

with:

js execution timed out; kernel reset, rerun your request

No retry was attempted. A later tab listing verified that exactly one requested tab had actually been created.

Navigate existing tab

Prepare succeeded.

Execute returned:

BROWSER_NAVIGATE_RESULT_UNCERTAIN

with the same:

js execution timed out; kernel reset, rerun your request

No retry was attempted. A later tab listing showed that the tab was still on the original URL, so the requested navigation did not complete.

Prepare click

A prepare-only click test targeted a simple semantic link:

• role: link
• text: About

No actual click was executed.

It failed before producing an approval reference with:

BROWSER_RUNTIME_ERROR

and:

js execution timed out; kernel reset, rerun your request

Immediately after the reset, a fresh browser_status again returned:

• status = ok
• chromeSkill = ok
• nodeRepl = ok
• Chrome extension backend connected

So in this reproduction, metadata/read/screenshot/scroll operations are healthy, while several page-lifecycle or interaction-preparation paths can reset the JS kernel.

No authenticated site content, cookies, credentials, account data, or private browsing data are included in this report.

Reproduced again on Windows after Codex updated to 26.818.41509.

The active Browser/Chrome plugin was 26.818.41509, but [shell_environment_policy.set] still overrode the runtime with stale 26.814.41957 values:

• NODE_REPL_TRUSTED_SERVICES referenced a deleted 26.814.41957/browser-service.mjs
• BROWSER_USE_CODEX_APP_VERSION remained 26.814.41957
• NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S contained the previous client hash

This caused Browser/Chrome initialization to fail before tab discovery with “Cannot find module …/26.814.41957/scripts/browser-service.mjs”.

The Chrome Native Messaging registry entry and manifest were also missing after the update.

Manual recovery required:

1. Synchronizing all three settings to 26.818.41509
2. Recomputing the bundled browser-client.mjs SHA-256
3. Re-registering the bundled Chrome Native Messaging host

Requested fix:

• Update all versioned Browser/Chrome runtime settings atomically during desktop/plugin upgrades
• Validate that configured service paths exist before launching the trusted worker
• Regenerate stale hashes automatically
• Repair/re-register the Chrome Native Messaging host when missing
• Provide a supported one-click self-healing action

This is a recurring upgrade regression and repeatedly costs users several minutes before browser-backed production work can continue.

Additional Windows reproduction: extension/native host healthy, CUA URL policy still fails

I can reproduce the same Windows Computer Use failure on the current desktop build, with a useful isolation point: the Chrome extension backend can read the exact HTTPS tab URL, while @oai/sky still rejects the matching Chrome window.

Environment

• Windows 11 Pro x64 (NT 10.0.26200.0)
• ChatGPT/Codex desktop: 26.818.8289.0
• Google Chrome Stable: 151.0.7922.174
• Computer Use plugin: openai-bundled/computer-use/26.818.61809
• @oai/sky: 0.6.17-202608171537-pr-1300023-7efba775c041
• ChatGPT Chrome extension: 1.2.27268.51612

Reproduction and diagnostics

1. The bundled Chrome diagnostics report the extension installed and enabled in the selected Default profile (exitCode: 0).
2. The native-host diagnostic reports correct: true: the registry path matches the manifest, the native executable exists, and all expected extension origins are present.
3. The Chrome extension backend connects successfully. chrome.user.openTabs() returns the live tabs and URLs.
4. I claimed a blank test tab and navigated it to https://example.com/. The Chrome backend immediately returned title: Example Domain and url: https://example.com/.
5. sky.list_apps() returned a Chrome window titled Example Domain - Google Chrome. An exact-title filter produced one target, and sky.get_window() succeeded.
6. Calling sky.get_window_state({ include_screenshot: true, include_text: true }) on that exact window stops the turn 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.

No Computer Use click, typing, keypress, scroll, drag, or navigation action was performed before the failure.

Expected behavior

Once the extension backend and native host have both verified the live https://example.com/ tab, Computer Use should associate that URL with the selected Chrome window and allow a read-only state capture.

This evidence appears to isolate the remaining failure to the Windows Computer Use browser URL confidence/policy path rather than extension installation, native-host registration, or Chrome tab discovery. A more specific diagnostic for the failed confidence check would also make this easier to troubleshoot.

The about:blank hitting only duolie.com while example.com survives is the tell, the tab-claim path is nuking that specific page, so before blaming the update again, test a clean Chrome profile with extensions disabled to isolate the site's own scripts. The stale chrome-native-hosts-v2.json you already fixed is the same recurring upgrade pattern as the version-pinned env vars songluyi found, so it's worth re-checking both after every app update. Oh also btw, I built a portable Hermes OTG and run it on USB as my rescue agent, super handy for quick diagnose & fix after updates like this, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG

Additional Windows reproduction on 26.825: Chrome and Edge URL-confidence failure, plus stale native-host state

I can reproduce the same Computer Use failure on a newer Windows/Codex build. No browser input action was performed before the safety stop.

Environment

• Windows 25H2 x64, build 26200.9168
• ChatGPT/Codex AppX: 26.825.3734.0
• bundled Chrome plugin/native host: 26.825.31414
• bundled Computer Use plugin: 26.825.31414
• Google Chrome Stable: 152.0.7977.64
• ChatGPT Chrome extension: 1.2.27268.51612

Computer Use reproduction

1. An ordinary authenticated HTTPS tab was selected in Chrome.
2. sky.list_apps() returned exactly one Chrome window with the expected site title.
3. sky.get_window() succeeded.
4. The first read-only state capture, sky.get_window_state({ include_screenshot: true, include_text: true }), stopped the turn 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.

The same result reproduced repeatedly after reboot and also reproduced against Microsoft Edge, including its new-tab page. No click, typing, keypress, scroll, navigation, or screenshot was completed before the stop. Expanding filesystem permissions and setting extension site access to “all sites” did not change the result.

Chrome/native-host isolation

• The Chrome extension is installed and enabled in the selected Default profile.
• Native Messaging registry and manifest exist and point to the current bundled extension-host.exe.
• chrome/latest resolves to 26.825.31414; the current browser-client path exists.
• The local schema-v2 runtime registry contains 30 historical entries.
• The current 26.825.31414 entry has valid current paths but does not contain trustedBrowserClientSha256s.
• Its stored presence metadata referenced a no-longer-running PID while a newer extension-host.exe process was active.
• Current bundled browser-client.mjs SHA-256: c52ba09202f0e82caa6f6d2a6463a8635c1b1316567975d9b91c1a05fb5af501.

The Chrome extension/plugin was reinstalled twice and Windows was rebooted; neither changed the failure. No unsupported proxy, trust injection, or manifest rewrite was attempted.

This appears to reproduce the Computer Use URL-confidence failure in this issue while also showing the stale-entry/trust-data pattern described in #40357. A supported self-healing action that atomically refreshes v2 entries, live presence metadata, and browser-client trust data would be valuable.

No authenticated page content, cookies, credentials, account identifiers, local usernames, full local paths, WebSocket tokens, or session IDs are included.