[Windows][Desktop] Browser/Chrome sandbox helper fails before page execution

Open 💬 3 comments Opened Aug 27, 2026 by kuajingquanqiu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The built-in Browser/Chrome runtime in the Codex Windows desktop app fails before opening any page.

Exact error:

windows sandbox failed: helper_unknown_error: setup refresh had errors

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 day ago

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

  • #40889
  • #41012
  • #40596
  • #40215
  • #39697

Powered by Codex Action

kuajingquanqiu · 1 day ago

Additional diagnostics:

This is my personal computer and is not managed by a company, school, MDM, or Group Policy.

Device management results:

PartOfDomain=False
AzureAdJoined=NO
DomainJoined=NO
WorkplaceJoined=NO

The documented sandbox log was checked at both paths:

C:\Users\kuaji.codex.sandbox\sandbox.log
C:\Users\kuaji\.codex\.sandbox\sandbox.log

Result:

LOG_NOT_FOUND

I did not access or include any content from .sandbox-secrets.

I also tested the preferred elevated sandbox configuration:

[windows]
sandbox = "elevated"

The minimum Browser/Chrome health check still did not confirm a successful browser startup.

The new exact runtime error was:

trusted Node process exited unexpectedly; kernel reset, rerun your request

The earlier exact error remains:

windows sandbox failed: helper_unknown_error: setup refresh had errors

No project code was changed to bypass this failure.

I will next test the documented unelevated fallback mode and report the result here.

kuajingquanqiu · 17 hours ago

Additional diagnostic result:

The symlink / redirected CODEX_HOME hypothesis has been ruled out.

Read-only checks show:

  • CODEX_HOME source: default user directory
  • CODEX_HOME path: %USERPROFILE%\.codex
  • CODEX_HOME is not a symlink, junction, or reparse point
  • %USERPROFILE%\.codex\browser is not a symlink, junction, or reparse point
  • %USERPROFILE%\.codex\browser\config.toml exists as a normal file
  • full_cdp_access_enabled = true

I also confirmed in the desktop UI:

Settings > Browser > Developer mode > Enable full CDP access

is enabled.

The local Browser runtime now starts successfully in unelevated sandbox mode, and the local page at:

http://127.0.0.1:8765/

loads successfully.

However, the connected Codex agent still exposes only:

Browser capabilities:

  • visibility
  • viewport

Tab capabilities:

  • pageAssets
  • webmcp

No callable full CDP or native browser-event interface is exposed.

No site-specific CDP approval prompt is triggered.

As a result, the agent cannot directly collect:

  • pageerror events
  • requestfailed events

This is not the previous Windows sandbox startup failure. Browser startup has recovered. The remaining issue appears to be that the desktop setting is enabled and correctly persisted, but the full CDP capability is not bridged into the active Codex Browser session.

Please advise:

  1. Whether this is a known Windows desktop runtime/configuration-bridge issue;
  2. Whether a new Browser session, app build, or runtime reset is required after enabling full CDP;
  3. Whether full CDP is expected to be available in unelevated sandbox mode;
  4. Whether there is a supported Windows workaround for collecting pageerror and requestfailed events;
  5. Whether using @Chrome with the official extension is the supported fallback.

No cookies, account data, tokens, or other websites were accessed.

<img width="603" height="741" alt="Image" src="https://github.com/user-attachments/assets/61742715-75ef-4782-892f-756fffd06112" />