Windows: Node REPL and browser control exit before execution with sandbox setup refresh error #49515

Codex App version

26.924.2738.0 (installed OpenAI.Codex Windows package, checked September 30, 2026)

Subscription

ChatGPT Pro

Platform

Windows x64; Microsoft Windows NT 10.0.26200.0

Bug

Node REPL and browser/computer-control operations fail during runtime startup, before the requested JavaScript executes. Ordinary sandboxed shell execution also fails before process creation. This blocks read-only conversation preservation and browser-based recovery work. The failures are repeatable across tasks and tool entry points.

This is a serious operational regression: previously working preservation workflows are unusable, and repeated failed startup attempts consume user time and interrupt ongoing work. Please route this to the Windows runtime/sandbox engineering owner and provide a supported correction and actionable diagnostics, rather than treating it as a problem with the user's capture script.

Observed errors

Direct mcp__node_repl__js invocation on September 29, 2026:

node_repl kernel exited unexpectedly
kernel_pid: 21708
kernel_status: exited(code=1)
kernel_stderr_tail: windows sandbox failed: helper_unknown_error: setup refresh had errors
reason: stdout_eof
stream_error: null

The requested script imported node:fs/promises and attempted a read-only UTF-8 file read. It failed before producing its output.

Browser-control invocation on September 30, 2026, using cua.getBrowser for an existing authenticated ChatGPT conversation:

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

One retry returned:

node_repl kernel exited unexpectedly
kernel_pid: 36008
kernel_status: exited(code=1)
kernel_stderr_tail: windows sandbox failed: helper_unknown_error: setup refresh had errors
reason: stdout_eof
stream_error: null

The two browser calls failed after approximately 7.13 and 3.81 seconds. No browser state or conversation response body was obtained. Earlier cua.getState calls also failed with the trusted-Node-process error.

Normal sandboxed shell execution fails with:

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

The supported approval/escalation route does allow PowerShell and GitHub CLI execution in this environment. The failure is therefore not a blanket inability to execute any local process.

An independent task recorded the same Node startup error on September 29 (PID 38300). In that run, the outer functions.exec orchestration continued to another tool successfully. Outer orchestration JavaScript and the failing Node REPL runtime are distinct; describing all JavaScript as broken would be inaccurate.

Reproduction from observed runs

1. In Codex on the affected Windows installation, invoke Node REPL with a read-only local-file script.
2. Observe the kernel exit with code 1 and sandbox setup-refresh error before the requested result is produced.
3. Invoke browser control to obtain state or select an existing browser session, without sending a chat message or modifying the conversation.
4. Observe the trusted Node process exit; a bounded retry produces the same sandbox error.
5. Attempt an ordinary sandboxed shell command; process creation fails with the same setup-refresh error.

Expected behavior

The runtime should initialize and execute an authorized read-only operation. If setup fails, the application should identify the failing setup component and give a supported recovery route. Retrying the requested script should not be presented as the remedy for a persistent runtime-startup failure.

Historical control and scope

A preserved September 22 execution receipt confirms that mcp__node_repl__js previously performed local filesystem rendering, exclusive-create writes and exact readback verification successfully. That establishes prior successful execution, but does not establish which app update or component caused this regression.

The separate native history-reader problem, where shallow results may report hasMore=false, is NOT established as caused by this runtime failure and is not the subject of this ticket.

Potentially related: #49433 . That report identifies an inaccessible old cua_node runtime on another installation. We have NOT verified that stale-runtime/ACL cause on this machine. Please correlate the common setup-refresh error without assuming an identical root cause.

No credentials, cookies, request headers, conversation contents, or full account traffic are included in this report. No runtime repair, permission weakening, or application-state changes were performed as part of this filing.