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

[insideyourr009-debug]

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.3698.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Browser automation is broken on Windows in multiple Codex control modes.

Environment:

• Windows 11 x64
• Codex/ChatGPT app: 26.818.3698.0
• Feedback ID: no-active-thread-01a0271f-cb67-7373-8c80-6bcb446c05fd

Reproduction / observed behavior:

1. Chrome plugin

• example.com can be read, clicked, and navigated successfully.
• On duolie.com, manually opened pages remain stable when Codex is not controlling them.
• After Codex claims the Chrome tab, with no click, refresh, navigation, DOM read, or JavaScript execution, the tab becomes about:blank after approximately 20–30 seconds.
• This reproduces on:
  • https://www.duolie.com/home
  • https://www.duolie.com/login
  • /newtalent/talentlist pages

2. Computer Use

• Tested with both Chrome and Microsoft Edge.
• Computer Use stops 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."

3. Built-in Browser

• example.com renders normally.
• Attempting to click the "Learn more" link fails with:
  "js execution timed out; kernel reset, rerun your request"

4. Previous stale-version issue found and fixed

• chrome-native-hosts-v2.json contained a stale resourcesPath pointing to OpenAI.Codex_26.818.2872.0.
• The stale cache was backed up and regenerated.
• The regenerated cache correctly points to 26.818.3698.0.
• Current Appx package status is OK.
• The current 26.818.3698.0 installation contains npm/index.js and the undici module.
• Chrome plugin navigation on example.com works after this fix.

Expected:
Codex should be able to control Chrome, Computer Use, and the built-in browser reliably on Windows without tabs becoming about:blank, URL-detection failures, or JS execution kernel resets.

Actual:
All three browser-control paths have separate failures as described above.

What steps can reproduce the bug?

Feedback ID: no-active-thread-01a0271f-cb67-7373-8c80-6bcb446c05fd

What is the expected behavior?

Codex should reliably control supported browsers on Windows.

Expected behavior:

1. The Chrome plugin should keep claimed tabs stable and should not cause tabs to become about:blank.
2. Computer Use should be able to identify the current browser URL in Chrome and Microsoft Edge on Windows and continue the task.
3. The built-in browser should be able to click and navigate on a simple page such as example.com without the JavaScript execution kernel timing out.
4. Browser control should continue working after the Codex app updates without stale runtime paths referencing an older app version.

Additional information

This issue has been reproduced repeatedly after restarting Windows and repairing the ChatGPT/Codex app.

Important diagnostic findings:

• Current installed Appx package:
  OpenAI.Codex 26.818.3698.0
  Status: OK

• A stale local browser cache previously referenced:
  OpenAI.Codex_26.818.2872.0

• The stale chrome-native-hosts-v2.json file was backed up and regenerated.

• The regenerated cache now contains 26.818.3698.0 and no longer contains 26.818.2872.0.

• Chrome native messaging host exists and is valid.

• Current npm/index.js exists.

• Current node_modules/undici and undici/package.json both exist.

After fixing the stale path:

• Chrome control works correctly on example.com.
• The remaining failures described in this issue still reproduce.

The duolie.com about:blank behavior was tested without clicking, DOM reads, JavaScript execution, refresh, or navigation:

• /newtalent/talentlist -> about:blank after ~20 seconds
• /home -> about:blank after ~20 seconds
• /login -> about:blank after ~30 seconds
• The same pages remain stable when Codex is not controlling the tab.

No sensitive user data or site content is included in this report.

[github-actions]

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

• [Windows][26.814.5517.0] In-app Browser page commands consistently stall for ~21 seconds, causing the 30-second Node REPL deadline to reset the control session #39766

Powered by Codex Action

[Fireotics]

they broke codex :C

[Fireotics]

i keep geting bad requests Error

[K389113273]

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.

[songluyi]

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.

[aGVybWFu]

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.

[MilkyWay008]

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

[vbzgn2rc98-ctrl]

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.