codex - 💡(How to fix) Fix Codex browser automation inside VS Code has been failing repeatedly during local UI verification

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Codex browser automation inside VS Code has been failing repeatedly on this Windows workstation during local UI verification. The failure happens before page interaction begins, while the browser automation runtime is being bootstrapped through the Node REPL helper.

This appears to be an agent/browser-plugin runtime startup problem rather than a TradeTrack2 page-rendering problem. The same pages can be built, served, and checked with direct HTTP requests.

Error Message

The error occurs during Browser plugin bootstrap, before any meaningful Playwright/DOM action runs. 4. Existing long-lived child processes or stale runtime state may make process setup more fragile, though the observed browser error is distinct from .NET file locks.

Root Cause

Codex browser automation inside VS Code has been failing repeatedly on this Windows workstation during local UI verification. The failure happens before page interaction begins, while the browser automation runtime is being bootstrapped through the Node REPL helper.

This appears to be an agent/browser-plugin runtime startup problem rather than a TradeTrack2 page-rendering problem. The same pages can be built, served, and checked with direct HTTP requests.

Code Example

node_repl kernel exited unexpectedly

node_repl diagnostics:
{
  "kernel_status": "running",
  "kernel_stderr_tail": "windows sandbox failed: spawn setup refresh",
  "reason": "stdout_eof"
}

---

if (!globalThis.agent) {
  const { setupBrowserRuntime } = await import(
    "C:/Users/eriks/.codex/plugins/cache/openai-bundled/browser/26.519.81530/scripts/browser-client.mjs"
  );
  await setupBrowserRuntime({ globals: globalThis });
}
if (!globalThis.browser) {
  globalThis.browser = await agent.browsers.get("iab");
}
await browser.nameSession("Performance UI check");
if (typeof tab === "undefined" || !tab) {
  globalThis.tab = await browser.tabs.new();
}
await tab.goto("http://localhost:5077/Analysis/Performance?TimeRange=3Y&Accounts=264121256");

---

node_repl kernel exited unexpectedly
windows sandbox failed: spawn setup refresh
stdout_eof
RAW_BUFFERClick to expand / collapse

What version of the IDE extension are you using?

26.519.32039

What subscription do you have?

Pro

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex browser automation inside VS Code has been failing repeatedly on this Windows workstation during local UI verification. The failure happens before page interaction begins, while the browser automation runtime is being bootstrapped through the Node REPL helper.

This appears to be an agent/browser-plugin runtime startup problem rather than a TradeTrack2 page-rendering problem. The same pages can be built, served, and checked with direct HTTP requests.

Current Failure Signature

Observed while trying to use the bundled Browser plugin against a local TradeTrack2 page at http://localhost:5077/Analysis/Performance?....

node_repl kernel exited unexpectedly

node_repl diagnostics:
{
  "kernel_status": "running",
  "kernel_stderr_tail": "windows sandbox failed: spawn setup refresh",
  "reason": "stdout_eof"
}

The error occurs during Browser plugin bootstrap, before any meaningful Playwright/DOM action runs.

What steps can reproduce the bug?

Reproduction Attempt

The failing step was the Browser plugin's documented first-cell bootstrap:

if (!globalThis.agent) {
  const { setupBrowserRuntime } = await import(
    "C:/Users/eriks/.codex/plugins/cache/openai-bundled/browser/26.519.81530/scripts/browser-client.mjs"
  );
  await setupBrowserRuntime({ globals: globalThis });
}
if (!globalThis.browser) {
  globalThis.browser = await agent.browsers.get("iab");
}
await browser.nameSession("Performance UI check");
if (typeof tab === "undefined" || !tab) {
  globalThis.tab = await browser.tabs.new();
}
await tab.goto("http://localhost:5077/Analysis/Performance?TimeRange=3Y&Accounts=264121256");

Actual result:

node_repl kernel exited unexpectedly
windows sandbox failed: spawn setup refresh
stdout_eof

What is the expected behavior?

Expected result:

  • Node REPL helper remains alive.
  • Browser runtime initializes.
  • In-app browser tab opens local URL.
  • Agent can inspect DOM and/or capture screenshot.

Additional information

Correlated Local Findings

Prior local troubleshooting notes point to several Windows/VS Code runtime hazards on this workstation:

  • VS Code user settings use Git Bash as the Windows integrated terminal default.
  • Previous agent runtime issues involved Git Bash path semantics leaking into extension/agent contexts.
  • Native Windows tools failed on Git Bash-style /tmp/... paths; D:\tmp\agent-python was adopted as the shared scratch path.
  • uv run python became the reliable cross-shell Python path; bare python / python3 were no longer considered reliable.
  • WSL visibility differed between contexts and should be checked from the same VS Code/extension context that is failing.
  • Local dev server processes frequently lock .NET build outputs on Windows; agents need to stop stale processes or use isolated output paths.
  • Previous UI tasks explicitly recorded that in-app browser automation was unavailable and local HTTP smoke tests were used as fallback.

These findings suggest an environment boundary problem around process spawning/session setup rather than a normal Playwright locator/page issue.

Hypotheses

Most likely:

  1. The Node REPL helper process cannot complete browser-client spawn/setup inside the VS Code Windows sandbox.
  2. The failure is sensitive to VS Code extension environment inheritance, especially Git Bash/default shell path semantics.
  3. Temp/scratch path assumptions may still be mixed between native Windows and Git Bash contexts.
  4. Existing long-lived child processes or stale runtime state may make process setup more fragile, though the observed browser error is distinct from .NET file locks.

codex-browser-automation-failure-report.md

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING