The latest Codex desktop update is causing an error in the sandbox, this message appears. I tested a read-only operation (Get-Location and git status) and the sandbox failed before running the command, with the same error: helper_unknown_error: setup refresh had errors. So, the problem is still with the local Codex environment startup, not the project.
Same here. No files in any UE project can be edited in a new Chat.
Welcome to the forum!
You are welcome to discuss Codex issues here. However, the official place to report and track them is the OpenAI Codex GitHub issue tracker.
I asked ChatGPT to look for the closest related issue, and it identified:
Some of the issue replies note some workarounds.
If that issue matches your problem, consider adding a 
reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.
If it does not describe the same problem, search the existing Codex issues for a closer match. If you cannot find one, open a new issue and include as much relevant detail as possible.
Codex version: 26.818.5229.0
Windows package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
Problem:
Codex cannot initialize its Windows sandbox. This prevents both ordinary
sandboxed commands and Computer Use from running.
Exact errors:
- exec_command: helper_unknown_error: setup refresh had errors
- node_repl: windows sandbox failed: helper_unknown_error:
setup refresh had errors - Node kernel exits with code 1 / stdout_eof before importing @oai/sky
Minimal reproduction:
- Open any local task in the Codex Windows app.
- Attempt a simple sandboxed command such as Get-Location.
- The command fails before process creation.
- Reset the Node REPL and execute:
nodeRepl.write(“node-repl-alive”) - The kernel exits during Windows sandbox setup.
Already attempted:
- Restarted Codex
- Used Windows App Repair
- Rebuilt the Codex runtime caches
- Fully uninstalled and reinstalled Codex
The failure persists after every attempt.
Additional checks:
- The CodexSandboxUsers local group exists.
- CodexSandboxOffline and CodexSandboxOnline exist and are enabled.
- The installed Codex package reports Status: OK.
- Elevated commands still work, but normal sandboxed commands do not.
Impact:
Computer Use is completely unavailable, so I cannot finish UI-based
application testing and evidence captures.
Please advise whether there is a sandbox-reset procedure or collect this
as a Windows Codex sandbox initialization defect.
Retested with Store build 26.818.8289.0. The defect persists unchanged.
Computer Use’s Node kernel exits before @oai/sky loads with:
“windows sandbox failed: helper_unknown_error: setup refresh had errors”
A clean kernel reset then reports:
“trusted Node process exited unexpectedly”
This can happen when codex fails to reassign ownership of .agents. Try checking:
$((Get-Acl -LiteralPath 'path/to/.agents').Owner)
it should correspond with:
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
I had an instance when it was owned by CodexSandboxOffline
For me it was just a matter of reassigning ownership to myself again. So from an elevated powershell, just run:
icacls /path/to/.agents /setowner [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
(or MACHINE/username)
This solved the issue for me.
Thanks, @Upasunda — your suggestion uncovered some permissions issues, although correcting it did not fully restore the elevated sandbox.
The repository and .agents were already owned by my Windows account, but the repository’s .tmp worktree directory and its descendants were owned by CodexSandboxOffline. I reassigned those to my account. I also found two explicit ACL entries for stale, unresolved SIDs on the repository root and .agents; I removed only those entries and preserved the current CodexSandboxUsers permissions.
After verifying the ACLs and restarting Codex, the elevated sandbox still failed with:
windows sandbox failed: helper_unknown_error: setup refresh had errors
What finally restored Computer Use was changing %USERPROFILE%\.codex\config.toml to:
[windows]
sandbox = "unelevated"
Computer Use initialized successfully immediately afterward and was able to control a Windows desktop application.
So the issue is operationally worked around, but I would not call the underlying elevated-sandbox problem fixed. According to the official OpenAI Windows sandbox documentation, elevated is preferred and unelevated is the weaker fallback mode. I plan to return to elevated once the setup-refresh problem is resolved.
It is possible that I inadvertently caused the issue by granting access to folders from my primary project to a new project, but I can not confirm that on my own.
I experienced a related Windows elevated-sandbox failure, although the exact error signature was different.
Codex Build -> 26.820.7780.0
In my case, sandbox setup refresh reported errors=[], but the command runner subsequently failed with Access is denied (error 5) while working with:
C:\Users\Default\.codex\.sandbox\cwd
This caused runner startup timeouts and apply_patch failures.
The recovery sequence that worked for me was:
- Temporarily set:
[windows]
sandbox = "unelevated"
-
Verified that
apply_patchcould create, read and delete a temporary probe file without changing Git status. -
Completed only one carefully bounded action while in the weaker
unelevatedfallback mode. -
Updated the Codex Windows app to the latest available version.
-
Installed the latest Windows updates.
-
Closed Codex, ChatGPT, VS Code and related background processes.
-
Used:
Windows Settings → Apps → Installed apps → Codex/ChatGPT → Advanced options → Repair
I selected Repair, not Reset.
- Restarted the application and restored:
[windows]
sandbox = "elevated"
- Ran another non-destructive health check.
Final result:
SANDBOX MODE: elevated
APPLY_PATCH: PASS
CREATE: PASS
READ: PASS
DELETE: PASS
ERROR: None
Git status remained unchanged.
I cannot confirm whether the successful recovery came from the Codex update, Windows update, App Repair, or their combination. Therefore, I would describe this as a confirmed recovery sequence—not a proven universal fix.
I also would not recommend copying ownership or icacls commands unless the affected user’s logs and read-only ACL inspection identify that exact problem. My failure involved the sandbox runner and C:\Users\Default, not .agents ownership.
A useful approach is to give the relevant logs to your own Codex agent and ask it to:
-
separate the primary failure from consequential timeout errors;
-
begin with read-only diagnostics;
-
preserve repository state;
-
recommend the least-destructive supported recovery;
-
avoid ACL changes, folder deletion or App Reset without explicit approval.
Hey everyone, This was resolved in the subsequent windows app updates. We will close this thread now. Apologies for delayed response.