Windows Computer Use fails after trusted Node process exits; setup refresh had errors and native GUI APIs are unavailable

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

26.901.51231

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows 11 Home 10.0.26200 (AMD64)

What issue are you seeing?

Environment

OS: Windows
Codex Desktop / bundled plugin version: 26.901.51231
Computer Use plugin: computer-use@openai-bundled
Unified Computer Use plugin: unified-computer-use@openai-bundled
Bundled Node.js: 24.19.0

Problem

Windows Computer Use cannot initialize. The following error is returned:

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

A related Windows sandbox error was also observed:

helper_unknown_error: setup refresh had errors

Retrying after resetting the Node kernel, restarting Codex Desktop, and rebooting Windows produces the same result.

Actual behavior

After initialization:

cua.getState(): available
cua.listApps: undefined
cua.getApp: undefined

The in-app Browser surface is available, but Windows native application discovery and control are unavailable.

Diagnostics

The following files exist:

node.exe
node_repl.exe
codex-computer-use.exe

All three bundled executables have valid OpenAI signatures. The configured native pipe endpoint also exists, but codex-computer-use.exe is not visible as a running process during the failure.

The installed runtime and plugin files appear intact. The failure appears to occur during the trusted Node / Windows sandbox / native pipe initialization path rather than during skill-file loading.

Attempts already made

Restarted Codex Desktop
Reset the Computer Use JavaScript session
Rebooted Windows
Uninstalled and reinstalled the Computer Use plugin
Uninstalled and reinstalled the plugin through the available UI
Confirmed that the Computer Use automatic installation flag is enabled
Confirmed that the bundled runtime files and signatures are valid
Confirmed that the issue persists after plugin reinstallation

Expected behavior

Computer Use should initialize successfully and expose Windows native application APIs such as:

cua.listApps()
cua.getApp()

Related reports

This appears related to the Windows sandbox and node_repl startup failures reported in:

Could you confirm whether this is a known Windows runtime / sandbox / native-pipe regression in version 26.901.51231, and advise whether a diagnostic build, supported runtime reset, or workaround is available?

What steps can reproduce the bug?

Use Codex Desktop on Windows 11 with Computer Use enabled.
Open a local Windows workspace and start a new task.
Ask Codex to initialize Computer Use or inspect the Windows desktop using the computer-use:computer-use skill.

Run the documented initialization:

if (!globalThis.sky) {
  const { sky } = await import("@oai/sky");
  globalThis.sky = sky;
}

Attempt to enumerate Windows applications or initialize the Computer Use bridge.
Observe that initialization fails with:
trusted Node process exited unexpectedly; kernel reset, rerun your request
Reset the Node kernel and retry the same initialization. The same error occurs.
After initialization, cua.getState() is available, but cua.listApps and cua.getApp are undefined.
Restart Codex Desktop, reboot Windows, and uninstall/reinstall the Computer Use plugin. The issue remains reproducible.
The bundled runtime files exist and have valid OpenAI signatures, but Windows native Computer Use APIs remain unavailable.

What is the expected behavior?

Computer Use should initialize successfully without terminating the trusted Node process.

The documented initialization should expose the Windows native Computer Use APIs, including:

cua.getState()
cua.listApps()
cua.getApp()

cua.listApps() should return the available Windows applications and windows, and cua.getApp() should allow selecting a returned application for subsequent GUI interaction.

Resetting the Node kernel or restarting Codex Desktop should not be required for normal initialization, and the native Computer Use bridge should remain available after initialization.

Additional information

The issue is reproducible after:

Restarting Codex Desktop
Rebooting Windows
Resetting the Node/Computer Use session
Uninstalling and reinstalling the Computer Use plugin
Confirming that automatic bundled plugin installation is enabled

The bundled runtime files are present:

node.exe
node_repl.exe
codex-computer-use.exe

The bundled executables have valid OpenAI signatures. The configured native pipe endpoint also exists, but the native Windows application APIs are still unavailable.

The in-app Browser surface remains available, suggesting that the failure is specific to the Windows native Computer Use / trusted Node / sandbox initialization path.

Related Windows reports include:

No user files, credentials, private project contents, or personal documents are included in this report.

Related observation

A related Codex Windows environment reported that read operations and PowerShell execution were working, while only the Windows-side apply_patch helper failed with helper_unknown_error.

In that case, retrying through the normal apply_patch wrapper directly succeeded when using a small, controlled patch followed immediately by a diff check.

This may indicate that some helper_unknown_error failures are specific to an individual Windows helper path rather than the entire Codex environment. However, this workaround has not been verified as a solution for the Computer Use trusted Node / native GUI failure described in this issue.

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

Windows Computer Use fails to initialize: helper_unknown_error: setup refresh had errors #43255
Windows Computer Use cannot control native Windows apps — cua.getApp is not a function #42214

Powered by Codex Action

Additional machine evidence: Windows Temp write-ACL failure before trusted Node kernel startup

Static investigation status: STATIC_ROOT_PROVENANCE_NOT_EXPOSED for the exact CUA request. The public 0.153.4 Windows resolver is exposed, but the installed node_repl policy/env/override construction is not. Please treat this as supplemental evidence for the sandbox-refresh symptom in this issue, not confirmation of every API-availability claim in the original report.

Local repair is paused. No sandbox, node_repl/CUA smoke test, environment/config/ACL change, or patch was performed during this final static investigation. This report is submitted with the machine owner's authorization. User paths, account SIDs, workspace identifiers and pipe UUIDs are redacted.

Environment and historical reproduction

Windows 11 Pro, 10.0.22631, x64, Windows Native.
Codex Desktop package 26.901.6511.0.
Both standalone CLI and Desktop-cached CLI report 0.153.4.
CUA runtime manifest: 0.0.9 / 20260829001140-68931e022688; runtime directory cua_node/b474a88d5d105afa.
Bundled Node v24.19.0; installed @oai/sky 0.6.26.
Installed unified-computer-use launcher package 26.901.51231.
windows.sandbox is elevated; no explicit global sandbox_mode is set in the saved user config.
Subscription was not collected.

Historical steps on this affected machine:

Use the installed Windows Native Desktop with its generated trusted node_repl/Sky configuration.
Initial elevated/current-user sandbox provisioning reportedly succeeded; the user reported doctor then showed provisioning complete and zero hard failures.
Request Windows Computer Use initialization. Starting the trusted Node kernel fails with windows sandbox failed: helper_unknown_error: setup refresh had errors.
Existing logs show the cached Codex setup helper attempts to grant write access on the user's Local/Temp and returns Windows error 5. Normal local PowerShell remains usable.
A later saved doctor run reports elevated provisioning failed. This is a later state, not evidence contradicting the user's earlier successful provisioning. No doctor/provisioning command was rerun for this static report.

This is a historical reproduction on the affected machine, not a newly validated clean-install reproducer. We do not have the exact serialized historical CUA request/payload or original child PID; payload reconstruction would be speculation.

Saved configuration and observed process chain

Relevant configuration values, with location placeholders:

mcp_servers.node_repl.command =
  <LOCALAPPDATA>/OpenAI/Codex/runtimes/cua_node/b474a88d5d105afa/bin/node_repl.exe
mcp_servers.node_repl.args = []
CODEX_CLI_PATH =
  <LOCALAPPDATA>/OpenAI/Codex/bin/8e5b6932251c2c1c/codex.exe
NODE_REPL_NODE_PATH = <CUA_RUNTIME>/bin/node.exe
NODE_REPL_NODE_MODULE_DIRS = <CUA_RUNTIME>/bin/node_modules
NODE_REPL_TRUSTED_SERVICES = generated browser and sky service definitions
SKY_CUA_NATIVE_PIPE = 1
SKY_CUA_NATIVE_PIPE_DIRECTORY = <Desktop-owned named pipe>
CODEX_HOME = <USERPROFILE>/.codex

A saved Win32_Process snapshot established:

ChatGPT.exe Desktop PID 4932
  -> cached codex.exe app-server PID 23296
     -> runtime node.exe PID 15084, executing unified-computer-use/scripts/launch.mjs
        -> node_repl.exe PID 18220
     -> separate direct node_repl.exe PID 23040

The installed launcher reads CUA_REPL_NODE_REPL_PATH and CUA_REPL_ENABLED_SURFACES, constructs the selected trusted-service map, and invokes spawn(executable, [], { env: {...process.env, ...}, stdio: "inherit" }). The current generated cua_repl configuration selects browser only; the separate node_repl MCP configuration contains Sky for Windows native use. These routes must not be conflated. The inspected launcher exposes no argv-forwarding/refresh override.

Installed Desktop app.asar members .vite/build/main-DpnWwRdP.js and src-VqXTPopo.js show Desktop generating/listening on its native pipe (Wte/Qte) and lazily creating WindowsHelperTransport on a native request. The helper receives --parent-pid and CODEX_CLI_PATH; approvals route back through requestComputerUseApproval. The saved Desktop log reports native-pipe readiness at 2026-09-07T13:10:39.902Z. A previous filesystem enumeration found that pipe without connecting to it. This does not establish native helper/kernel readiness or successful Computer Use.

Relevant raw existing logs

Path substitutions only; timestamps retain their original local/UTC forms. Local time is UTC+3. The two overlapping starts below are preserved; no unique PID correlation is claimed.

[2026-09-07 16:11:44.761 codex.exe] START: <CUA_RUNTIME>\bin\node.exe --experimental-vm-modules --eval // Node's emulated realpath walks every ancestor. Windows may allow the
[2026-09-07 16:11:44.769 codex.exe] START: <CUA_RUNTIME>\bin\node.exe --experimental-vm-modules --eval // Node's emulated realpath walks every ancestor. Windows may allow the
[2026-09-07 16:11:44.942 codex.exe] setup refresh: spawning <CACHED_CLI_DIR>\codex-windows-sandbox-setup.exe (cwd=<WORKSPACE>, payload_len=6120)
[2026-09-07 16:11:44.955 codex.exe] setup refresh: spawning <CACHED_CLI_DIR>\codex-windows-sandbox-setup.exe (cwd=<WORKSPACE>, payload_len=6116)
[2026-09-07T13:11:44.968348500+00:00] granting write ACE to <USERPROFILE>\AppData\Local\Temp for sandbox group and capability SID
[2026-09-07T13:11:44.989790800+00:00] read-acl-only mode: applying read ACLs
[2026-09-07T13:11:46.630466600+00:00] grant read ACE failed on <USERPROFILE>\AppData for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-07T13:11:47.444734+00:00] grant read ACE failed on <USERPROFILE>\AppData\Local for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-09-07T13:11:47.449496900+00:00] setup error: read ACL run had errors
[2026-09-07T13:11:55.794580300+00:00] write ACE grant failed on <USERPROFILE>\AppData\Local\Temp: SetNamedSecurityInfoW failed: 5
[2026-09-07T13:11:55.798613800+00:00] setup refresh: processed 4 write roots (read roots delegated); errors=["write ACE failed on <USERPROFILE>\\AppData\\Local\\Temp: SetNamedSecurityInfoW failed: 5"]
[2026-09-07T13:11:55.798642800+00:00] setup error: setup refresh had errors
[2026-09-07 16:11:55.801 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))
[2026-09-07 16:11:55.802 codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))

Saved later doctor output:

Codex Doctor v0.153.4 · windows-x86_64
sandbox: elevated Windows sandbox provisioning recorded a structured failure
sandbox backend: elevated
sandbox provisioning: failed

Saved ACL observations: AppData and Local are owned by the current user, DACL protection is false, and inherited FullControl entries exist for SYSTEM, Administrators and the current user, without deny ACEs. Temp differs: its DACL protection is true, with FullControl for those principals and two additional allow entries. The user's earlier elevated grant on AppData/Local also returned Access Denied, whereas a test subfolder accepted the operation. These ACL operations were not repeated. The underlying reason Windows refuses SetNamedSecurityInfoW remains unknown; ownership alone does not establish that reason.

What the release source actually proves

Official tag rust-v0.153.4 resolves to commit 3d2ee51. This matches the release version; the exact build commit of the installed executables has not been independently established.

protocol/src/permissions.rs:780-812: the standard workspace-write policy inserts a writable symbolic Tmpdir entry unless exclude_tmpdir_env_var is true.
windows-sandbox-rs/src/resolved_permissions.rs:140-208: Windows removes generic Tmpdir/SlashTmp entries before normal resolution. If a writable Tmpdir entry exists, windows_temp_env_roots resolves both TEMP and TMP independently, using the supplied env_map value, or the Codex process environment only when that key is absent. Only absolute paths are retained. This Windows branch does not read TMPDIR.
setup.rs:614-666: gather_write_roots_for_permissions canonicalizes/deduplicates roots. Crucially, a supplied write_roots override replaces that computation. Explicit absolute permission entries are also a possible source.
setup.rs:1146-1155 passes request permissions/env_map and overrides.write_roots through build_payload_roots. setup.rs:322-389 constructs ElevationPayload.write_roots, sets refresh_only=true, serializes/base64-encodes it, then synchronously runs codex-windows-sandbox-setup.exe with Command::status. The observed spawning process is cached codex.exe, not the Desktop pipe server.
identity.rs:230 refreshes ACLs on the elevated execution path. setup_main/win.rs:811 delegates read ACL work; accumulated synchronous refresh errors fail at lines 1027-1032. Thus the Temp write failure is direct evidence for the synchronous refresh failure, while background AppData read errors must be distinguished.

Supported configuration: established generic field, unestablished CUA contract

The versioned config schema includes sandbox_workspace_write.exclude_tmpdir_env_var, default false. core config resolution forwards it into the standard workspace profile. The official configuration reference documents it for workspace-write, describing TMPDIR.

This proves a general setting exists. It does not establish that the generated managed CUA/node_repl profile consults it, or that it can be scoped to this child. Removing symbolic Tmpdir would not remove an explicit absolute entry or write_roots override. No change was applied.

The inspected installed launch.mjs/Desktop resources and public release tree do not expose the matching node_repl Rust implementation that constructs the historical permissions, env_map and overrides/CLI arguments. Accordingly, we cannot uniquely attribute the observed Local/Temp root to TEMP, TMP, an automatic workspace rule, or an explicit CUA payload field. No launch semantics are inferred from that absence. An independent static reviewer reached the same conclusion.

The previously captured node_repl help advertised --disable-sandbox. That is rejected as a Computer Use repair: a generic unsandboxed kernel would not prove the trusted native path works. The flag was not exercised, no persistent workaround was installed, and CODEX_CLI_PATH was not removed/replaced.

Diagnostic-history caveat

An earlier subordinate investigator mistakenly ran codex sandbox windows --help as a help probe at 17:21:51 local time. In this installed CLI it was interpreted as a payload command, triggering refresh; it is not a safe help-only reproduction command and must not be repeated for this investigation.

Existing incident logs report zero write roots with synchronous errors=[], then asynchronous read-ACL failures; the nonexistent payload failed with CreateProcessAsUserW error 2. The vendor command runner was copied into its normal cache. Current source/cache runner hashes match, but there was no pre-probe cache backup. Subsequent comparisons found the user config and the three captured AppData/Local/Temp SDDLs unchanged; they do not prove all other security artifacts unchanged. This incident occurred before the present static-only stop decision and is disclosed to avoid presenting its results as a controlled test.

Artifact identity and request to OpenAI

Saved SHA-256 values:

node_repl.exe:
D8B7601D617554E606731A0A4524B7C3B244D862185D85E6FBF3E6EB61E7A414
cached codex.exe:
E5AA76D19C7C94E2E9EF9B707D590206A73AC0E97C8DDC8382181242494BEF75
source/cache codex-command-runner.exe:
8D88F3E1749704937E735FE2B0311E939BD2873010243030A6F0C023D3D7296D

Full baseline backups, unredacted local logs/SDDL, process snapshots, source blob identities and investigator records remain local. No auth files, full user config, raw base64 sandbox payload or private project content are uploaded.

Please provide the supported contract/workaround for this exact trusted runtime: which component generates the CUA kernel permission profile/env_map/write-root overrides, and can automatic Windows TEMP/TMP write roots be excluded or placed in a dedicated directory for this trusted CUA path only, while preserving sandboxing and native approvals? Specifically, does the documented exclude_tmpdir_env_var setting reach that generated profile, or is a fixed runtime build/another supported interface required? Please also identify a supported way to diagnose the error-5 ACL refresh failure without broad AppData ACL resets, owner changes, global sandbox disablement, or undocumented launcher changes.

No repair success is claimed. Local repair remains paused pending the supported contract.

Additional Windows reproduction + partial workaround signal from another affected machine.

I reproduced the same failure:

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

A clean-launch workaround was able to restore native Computer Use once, but it did not establish stability.

What I changed for that successful run:

completely terminated the previous Codex Desktop process tree before launch;
launched a fresh Desktop process tree with TEMP and TMP scoped only to a dedicated writable directory (C:\AstraTemp);
used a launcher that refuses to start while an old codex.exe process is still alive.

After that clean launch, native Computer Use successfully:

opened Notepad via Win+R;
typed ASTRA_CUA_OK;
visually verified the text.

So the native path can work on this machine after a clean process/environment reset.

However, the failure later reproduced. In a subsequent real task, native Computer Use failed during initialization before any app interaction with the same trusted-Node error. I then tried Browser Use for the same pending task; Browser Use also failed before reaching the UI with the same error.

That gives this sequence:

fresh process tree + dedicated TEMP/TMP -> native CUA worked once
later native CUA init                 -> trusted Node crash
Browser Use init                       -> same trusted Node crash

This makes the dedicated TEMP/TMP setup look like a partial workaround / diagnostic signal, not a root-cause fix. It also suggests the failure may be in a shared trusted-Node/sandbox runtime layer rather than in application discovery or browser navigation itself.

One extra observation: the launcher caught a lingering codex.exe process and intentionally refused to start until that process was terminated. This may be relevant when testing clean-start behavior.

I can provide the small launcher logic and additional logs if useful. No credentials, private project contents, or user data are included in this report.

使用5.5初始化微软原生应用然后5.6就正常了

@BFTwarrior

@BFTwarrior Thanks — I independently reproduced your workaround on another affected Windows machine.

What worked here:

Start native Computer Use under GPT-5.5.
GPT-5.5 successfully initialized the trusted native path through @oai/sky, opened Notepad, typed CUA_55_BOOTSTRAP_OK, and visually verified it via screenshot.
Without closing Codex Desktop, resetting Computer Use, or restarting the native bridge/process tree, switch the same live task to Astra.
Astra then reused the already-initialized native Computer Use session, typed ASTRA_AFTER_55_OK into the same Notepad window, and visually verified both lines.

So on this machine the sequence GPT-5.5 -> initialize native Computer Use -> switch to Astra works.

This does not yet establish the root cause or long-term stability, and I have not yet completed a direct cold-start Astra control after a fresh Desktop restart. But it is a strong independent reproduction of your 5.5-bootstrap observation, and it also appears to carry over successfully to Astra.

Thanks for the tip — it was genuinely useful.

恳请各位帮我测试一个东西，先让codex初始化桌面控制，如果还是返回浏览器接口可用，桌面控制接口不可用。
那就把下面的提示词给它

当 cua_repl 初始化失败时，不要判定桌面控制不可用，改用持久化 node_repl 执行 const { sky } = await import("@oai/sky"); globalThis.sky = sky;，再通过 sky.list_apps() 初始化并继续桌面控制。

看看这段提示词有没有用。

Verified workaround: process-scoped TEMP/TMP restores trusted node_repl + @oai/sky

I retested this on Windows with Codex Desktop package 26.908.9136.0.

The original blocking failure was reproducible on the default user temp path:

C:\Users\<user>\AppData\Local\Temp
write ACE grant failed: SetNamedSecurityInfoW failed: 5
setup refresh had errors

That prevented the trusted node_repl from starting, so @oai/sky never actually executed.

Controlled A/B test

I launched Codex Desktop in a fresh process tree with only process-scoped:

TEMP=C:\CodexTemp
TMP=C:\CodexTemp

No ACL, ownership, registry, global environment, Codex config, plugin, or sandbox configuration changes were made.

Environment inheritance was verified directly:

Desktop GUI      -> TEMP/TMP = C:\CodexTemp
Codex app-server -> TEMP/TMP = C:\CodexTemp
Node REPL host   -> TEMP/TMP = C:\CodexTemp
Node child hosts -> TEMP/TMP = C:\CodexTemp

Result

With the redirected TEMP/TMP:

granting write ACE to C:\CodexTemp for sandbox group and capability SID
setup refresh: processed 3 write roots (read roots delegated); errors=[]

Then:

trusted node_repl started successfully on retry;
const { sky } = await import("@oai/sky") succeeded;
sky.list_apps() succeeded;
native Windows applications were enumerated successfully (including Codex/ChatGPT, Explorer, Yandex, Visual Studio Code, and others).

So on this machine the native Windows Computer Use backend / Sky bridge is functional. The blocking failure is specifically the sandbox write-ACL refresh against the default %LOCALAPPDATA%\Temp path.

Remaining separate issues

Background read-ACE attempts still fail on:

C:\Users\<user>\AppData
C:\Users\<user>\AppData\Local

with SetNamedSecurityInfoW failed: 5, but they did not block the successful trusted node_repl -> @oai/sky path in this run.

Separately, the cua_repl path failed while parsing:

C:\Users\<user>\.codex\.sandbox\deny_read_acl_state.json

with:

EOF while parsing a value at line 1 column 0

That appears to be a distinct issue from the TEMP write-root failure.

Current status

This is a verified workaround / isolation result, not yet a permanent root-cause fix.

The clean discriminator is:

default %TEMP%       -> write ACE error 5 -> setup refresh fails -> node_repl cannot start
process-scoped TEMP  -> write ACE succeeds -> setup refresh errors=[] -> node_repl + @oai/sky work

This makes the TEMP write-root ACL refresh the primary blocking condition for the trusted native Computer Use path on this machine.

Final RCA update: Windows sandbox / AppData ACL propagation

Tested on Codex Desktop 26.908.9136.0, runtime 0.154.0-alpha.6.2, source commit b5bffd3ec4db487e7e3dec59663875b0ef7b72ca.

Summary

This investigation separated several Windows failure layers that initially looked like one Computer Use problem:

Native Windows backend is healthy once sandbox initialization succeeds.
With process-scoped TEMP/TMP=C:\CodexTemp, trusted node_repl starts, @oai/sky imports, native apps/windows enumerate, and real native interaction works.
Default user Temp is a concrete sandbox blocker on this machine.
The default user temp path reproduces SetNamedSecurityInfoW failed: 5 during sandbox ACL setup and prevents trusted Node startup.
The deny_read_acl_state.json race is a separate reproducible bug, tracked in Windows sandbox helpers race while updating deny_read_acl_state.json #34013.
The remaining AppData/AppData\Local failure was traced with an exact-version instrumented helper and zero-loss ETW.

Real AppData trace

For the real failing run:

helper-attributed SetSecurity total: 22,486
SetSecurity failures:                    0
Create/open ACCESS_DENIED:              150
top-level SetNamedSecurityInfoW:          5

All 22,486 observed SetSecurity operations succeeded.

The observed STATUS_ACCESS_DENIED events were descendant Create/open operations during traversal, not observed SetSecurity failures. Therefore the log line:

SetNamedSecurityInfoW failed: 5

must not be interpreted as proof that the root SetSecurity operation itself was denied.

The 150 denied opens split into two measured classes:

122 events: CreateOptions=0x01200000, share 7
28 events: CreateOptions=0x01200021, share 3

The second class followed a distinct observed ntmarta branch family and a repeatable mixed sequence on several legacy-like paths:

Create success
QuerySecurity success
Create ACCESS_DENIED
Create ACCESS_DENIED
SetSecurity success
Create success
Create ACCESS_DENIED
Create ACCESS_DENIED

Both final denied opens in the two real setter windows belonged to that second class.

However, after the final AppData denial, another 1,861 successful SetSecurity operations completed before the top-level return 5.

Synthetic falsification #1

A disposable fixture with one known inaccessible descendant reproduced descendant ACCESS_DENIED opens.

Traversal continued, successful SetSecurity operations followed, and top-level SetNamedSecurityInfoW returned 0.

So “any inaccessible descendant is sufficient to produce return 5” is false.

Synthetic falsification #2

A second disposable A/B preserved security-descriptor access but removed only normal-user FILE_LIST_DIRECTORY in TREATMENT.

This reproduced the measured real second-class signature:

CreateOptions=0x01200021
share 3
STATUS_ACCESS_DENIED
all four observed ntmarta branch families
the same mixed success/denial sequence
the final normalized user-mode stack matched the terminal real AppData\Local denial

Yet:

CONTROL   SetNamedSecurityInfoW = 0
TREATMENT SetNamedSecurityInfoW = 0

The TREATMENT also showed partial propagation despite success:

6/7 objects received the sandbox RX ACE
one descendant file remained unchanged
helper exit code was 0

So top-level success does not guarantee complete descendant propagation either.

What is proven

native Windows backend / Sky bridge works once sandbox startup succeeds;
default user Temp is a blocking write-root on this machine;
the Windows sandbox helpers race while updating deny_read_acl_state.json #34013 deny-read state race is separate;
real AppData failure occurs after many successful descendant security writes;
observed ACCESS_DENIED events are descendant opens, not observed SetSecurity failures;
the measured real denied-open class / observed ntmarta branch / partial propagation are not sufficient to explain real return 5;
top-level return 0 can coexist with incomplete descendant propagation.

Not proven

the exact internal Windows condition that makes the real AppData traversal return 5;
a single causal descendant;
reparse/junction causality;
ESET or another filter driver as the cause;
a specific ntmarta defect.

At this point I am stopping synthetic search. Further black-box ACL permutations are unlikely to add useful information without new Windows-internal visibility.

Upstream implication

The sandbox currently reduces a much richer recursive Windows ACL operation to one top-level status. The evidence here shows that neither direction is safe to over-interpret:

return 5 does not imply the root security write itself was denied;
return 0 does not imply every descendant received the intended ACL.

Potential areas to review include:

avoiding broad recursive ACL propagation through real user-profile trees where possible;
preferring app-owned/sandbox-owned scratch paths;
distinguishing root failure from descendant traversal failure in diagnostics;
validating the effective final state required by the sandbox instead of relying only on the aggregate recursive return.

I retained the exact-build provenance, zero-loss ETW traces, root descriptor snapshots, all 150 denied-operation records, synthetic A/B evidence, hashes, and sanitized summaries locally if a narrower developer-requested artifact would be useful.

Related: #34013, #43596

Additional reproduction on a separate Windows machine:

Windows 11 build 10.0.26100.3775; Codex Desktop reports 26.917.51856 (build 10492), and the installed MSIX package is 26.917.6896.0. Bundled Node is v24.21.0.
cua.getState() fails immediately with trusted Node process exited unexpectedly; kernel reset, rerun your request. A minimal trusted node_repl call (nodeRepl.write('ok')) fails with the same error. The failure persists after resetting the Computer Use JS session and restarting Codex.
The saved windows.sandbox setting is unelevated. I tested elevated followed by a full Codex restart; no Windows setup/UAC prompt appeared, and both calls still failed. I restored unelevated afterward.
CodexSandboxService.OpenAI.Codex initially was stopped with Windows exit code 1067. Starting it made the service report Running, but did not change either failure. The RegisteredCore registry marker was absent; I cannot establish whether that is causal.
Windows app Repair and another restart also did not resolve it. The bundled node.exe runs directly, and the node.exe and node_repl.exe signatures validate.
In this reproduction, sandbox setup refresh logs report errors=[]. I did not observe the Temp write-ACL failure described in earlier comments. The available logs show the trusted Node start attempt but no actionable child exit reason.

This looks like the same user-visible trusted Node failure with a different or still unidentified underlying cause. Is there a supported diagnostic that captures why the trusted Node child exits when setup refresh reports no errors? No private workspace contents or user-specific paths are included here.

Follow-up to my earlier reproduction on Windows / Codex Desktop 26.917.51856: I found a distinct environment-filtering cause on this machine. Sandbox setup refresh reported errors=[].

A direct diagnostic of the installed node_repl.exe with the effective MCP environment exposed SyntaxError: "undefined" is not valid JSON at trusted-worker.js:19, where it parses process.env.NODE_REPL_TRUSTED_SERVICES. Yet codex mcp get node_repl --json contained a valid value. My shell_environment_policy.include_only omitted all 16 generated Node/Browser/Sky environment names, so the trusted process lost them. This resembles #42757.

Local workaround and verification:

Added the 16 generated names to shell_environment_policy.include_only. A minimal nodeRepl.write('ok') then worked, but sky.list_apps() still failed; typeof nodeRepl.rpc was undefined.
Added NODE_REPL_TRUSTED_RPC_ENABLED to that allowlist and set it to "1" under [shell_environment_policy.set]. Then nodeRepl.rpc was a function and @oai/sky enumerated Windows apps.
After a full Codex Desktop restart, trusted node_repl still runs, Sky lists Notepad/Chrome windows, and the Chrome plugin reads an existing open tab. Native Computer Use is usable.

The 16 generated names were BROWSER_USE_AVAILABLE_BACKENDS, BROWSER_USE_CODEX_APP_BUILD_FLAVOR, BROWSER_USE_CODEX_APP_VERSION, BROWSER_USE_TINYSKY_ENABLED, CODEX_CLI_PATH, CODEX_HOME, NODE_REPL_INSTRUCTIONS_USE_CASE_BROWSER, NODE_REPL_INSTRUCTIONS_USE_CASE_CHROME, NODE_REPL_NATIVE_PIPE_CONNECT_TIMEOUT_MS, NODE_REPL_NODE_MODULE_DIRS, NODE_REPL_NODE_PATH, NODE_REPL_TRUSTED_CODE_PATHS, NODE_REPL_TRUSTED_SERVICES, NODE_REPL_UNTRUSTED_ENV_ALLOWLIST, SKY_CUA_NATIVE_PIPE, and SKY_CUA_NATIVE_PIPE_DIRECTORY.

Remaining limitation: The separate cua_repl interface still returns cua is not defined after JS reset and app restart. Its generated config selects the browser surface, separate from the recovered node_repl + Sky native path. The TEMP/TMP scratch-folder experiment and Windows app Repair did not resolve this case; user TEMP/TMP values were restored.

This is a local workaround, not an upstream fix. It points to generated runtime variables being filtered by include_only and to the trusted RPC bridge needing a supported default/configuration path. No user-specific paths, credentials, or service values are included.

@ScottKemp

@ScottKemp Thanks — this is a very useful independent counterexample.

It confirms that the same trusted Node process exited symptom can occur even when sandbox setup itself reports errors=[], i.e. independently of the Temp/AppData sandbox failure documented above.

Your environment-filtering result adds another distinct failure layer:

shell_environment_policy
-> generated trusted Node / Sky variables removed
-> trusted worker fails before native RPC initialization

The fact that restoring those variables brought back node_repl + @oai/sky while the separate cua_repl path remained browser-only also reinforces the separation between:

sandbox startup,
trusted Node environment / RPC initialization,
managed CUA routing / surface selection.

This looks actionable upstream: required generated trusted-runtime variables should probably not be silently stripped by include_only, or the trusted worker should fail with an explicit diagnostic naming the missing variable(s) instead of surfacing only the generic kernel-exit symptom.

Thanks for the careful A/B and for documenting the exact recovery path.

Additional reproduction on 29 September 2026.

Environment

Windows 11 Business 10.0.26200, 64-bit
Codex Desktop 26.924.51851, build 12111, production channel
Updater reports the installation is current

Observed

Computer Use fails before it can attach to or inspect an existing Chrome tab.
Errors observed:
- windows sandbox failed: helper_unknown_error: setup refresh had errors
- windows sandbox failed: orchestrator_helper_exit_nonzero: setup helper exited with status Some(1)
- trusted Node process exited unexpectedly
The problem persisted after three complete application restarts, updating Codex, and fully closing and reopening Chrome.
A normal sandboxed read-only shell command also failed during helper setup. The same command succeeded outside the sandbox, indicating that the failure is below the Chrome/browser layer.

Expected
Computer Use should initialize and connect to the existing Chrome session.

Impact
Browser-based acceptance testing is completely blocked.

This functionality worked previously. The timing suggests a possible regression, but does not establish the update as the cause. No credentials, browser-session data, customer information, or private workspace content are included.

I had the same issue with the official Codex Desktop app installed from the Microsoft Store on Windows 10. After extensive troubleshooting, I found a workaround that completely restored browser automation.

The errors I encountered were:

node_repl kernel exited unexpectedly

trusted Node process exited unexpectedly; kernel reset

windows sandbox failed: helper_unknown_error: setup refresh had errors

reason: stdout eof

I also checked the Windows sandbox logs and found that Codex was failing to update permissions on node_repl.exe because the file was already being used by another process (os error 32).

I tried restarting Codex, reinstalling the application, rebooting Windows, and starting a fresh chat. None of these fixed the issue.

HERE IS THE FIX THAT WORKED FOR ME:

Completely close Codex Desktop.
Open PowerShell and enter this command:

notepad "$env:USERPROFILE.codex\config.toml"

Find the Windows configuration section.
Change the sandbox setting from "elevated" to "unelevated".

The final configuration should have a [windows] section with sandbox = "unelevated".

Save the file and restart Codex Desktop.

RESULT:

Browser automation immediately started working. Codex successfully detected my open browser tabs, read their titles and URLs, and opened Wikipedia on request.

The problem appears to be related to the elevated Windows sandbox initialization and a file-locking conflict involving node_repl.exe. The exact root cause is not yet confirmed.

IMPORTANT: The unelevated sandbox mode provides weaker isolation than elevated mode, so this should be considered a workaround rather than a permanent fix.

I hope this helps other users experiencing the same problem. I also hope the OpenAI Codex team can investigate and fix the elevated sandbox initialization issue in a future update.

Windows Computer Use fails after trusted Node process exits; setup refresh had errors and native GUI APIs are unavailable #43373

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Environment

Problem

Actual behavior

Diagnostics

Attempts already made

Expected behavior

Related reports

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Additional information

Related observation

Activity

github-actions commented on Sep 7, 2026

Freemlen commented on Sep 7, 2026

Additional machine evidence: Windows Temp write-ACL failure before trusted Node kernel startup

Environment and historical reproduction

Saved configuration and observed process chain

Relevant raw existing logs

What the release source actually proves

Supported configuration: established generic field, unestablished CUA contract

Diagnostic-history caveat

Artifact identity and request to OpenAI

Freemlen commented on Sep 8, 2026

BFTwarrior commented on Sep 8, 2026

Freemlen commented on Sep 10, 2026

BFTwarrior commented on Sep 17, 2026

Freemlen commented on Sep 18, 2026

Verified workaround: process-scoped TEMP/TMP restores trusted node_repl + @oai/sky

Controlled A/B test

Result

Remaining separate issues

Current status

Freemlen commented on Sep 19, 2026

Final RCA update: Windows sandbox / AppData ACL propagation

Summary

Real AppData trace

Synthetic falsification #1

Synthetic falsification #2

What is proven

Not proven

Upstream implication

ScottKemp commented on Sep 23, 2026

ScottKemp commented on Sep 23, 2026

Freemlen commented on Sep 23, 2026

rlliddiard commented on Sep 29, 2026

vasya6677ghjaaus-ctrl commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Windows Computer Use fails after trusted Node process exits; `setup refresh had errors` and native GUI APIs are unavailable #43373