Repository navigation
Windows sandbox setup fails with error 32; browser control and commands blocked #51777
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.1002.52244, build 13536
What subscription do you have?
Business
What platform is your computer?
Microsoft Windows NT 10.0.26300.0 x64
What issue are you seeing?
Browser control and local commands fail before they can start.
Error:
helper_unknown_error: setup refresh had errors
The sandbox log reports:
runtime read/execute validation failed
open ACL target for root-only update
The process cannot access the file because it is being used by another process. (os error 32)
The failure initially named node_repl.exe inside Codex’s bundled runtime. After stopping four node_repl.exe processes, the next failure named VCRUNTIME140_1.dll under:
...\node_modules@oai\sky\bin\windows\swift\x64\
Process Explorer showed codex-computer-use-swift.exe loading that DLL. Stopping this helper caused ChatGPT.exe to launch it again with a new PID.
Restarting the app, restarting Windows, stopping the helpers, and shutting down the ChatGPT process tree before reopening did not restore command execution.
Related reports: #51601 and #51668.
Please provide a supported fix or rollback procedure that preserves my chats and files.
What steps can reproduce the bug?
Open the Windows desktop app and enter a Codex chat.
Ask Codex to open a website using browser control or read a local file.
The tool fails before the requested action starts with:
helper_unknown_error: setup refresh had errors
The sandbox log reports Windows error 32 while validating Codex’s own runtime files.
The failure persists on my installation after restarting the app and Windows.
What is the expected behavior?
Codex should complete Windows setup and run authorized browser actions and local commands while its own runtime helpers are running.
Additional information
App version: 26.1002.52244, build 13536. The app update checker reported that it was up to date.
Related reports: #51601 and #51668.
This prevents me from using browser automation for my work. Please provide a supported fix or rollback procedure that preserves my chats and files.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
DaYipperBot commentedon Oct 7, 2026
Unclear if its the same issue.
Cyber-neeXia commentedon Oct 7, 2026
I fixed it temporarily.
Tested October 7, 2026. This is a workaround, not a confirmed product fix.
ERROR 1: "AbsolutePathBuf deserialized without a base path" (-32602)
"Please reply and run only hostname. Report its output and exit code.
Do not edit files, change settings, or resume earlier work."
and hostname returns your computer's name with exit code 0.
If the browser works but the desktop app still fails, make the same selection
in the desktop chat and test there too. Check the selected mode in each
affected chat/client; do not assume another client's selection has carried over.
Why this may help: matching reports link Custom mode to an extra sandbox-path
override in the submitted request. Choosing a built-in permission mode can
avoid that request path. Ask for approval retains workspace limits and asks
for manual approval before going beyond them.
Verified result: this restored direct browser messaging in the SAME original
chat, and hostname completed successfully. Native desktop composer recovery
was still awaiting verification. The separate cross-chat messaging tool still
failed. The stored mixed cloud/Windows path was not changed.
OpenAI permission modes:
https://learn.chatgpt.com/docs/permission-modes
Matching request comparison:
#50332
ERROR 2: "setup refresh had errors" (-32603)
Only use this separate, temporary workaround if Windows command execution
fails during elevated sandbox setup. The permission-mode change above does
not repair that setup failure.
Open Settings > Configuration > Open config.toml in the desktop app.
The usual location is %USERPROFILE%.codex\config.toml.
Save a backup copy of the file before editing it.
In the existing [windows] section, change only:
sandbox = "elevated"
to:
sandbox = "unelevated"
If there is no [windows] section, add that section and its sandbox entry
once. Keep every other setting unchanged; avoid duplicate sections/keys.
Save the file. Once running work has finished, fully quit the desktop app
and reopen it.
Send the hostname-only diagnostic above and verify a completed result.
Unelevated is a documented fallback with weaker Windows isolation, including
weaker network isolation. Treat it as temporary. After a build containing the
setup fix is available, change the value back to elevated, restart, and test.
Keep elevated only when that execution check succeeds; if the same setup error
returns, the stronger sandbox is not yet repaired on that installation.
OpenAI Windows sandbox guidance:
https://learn.chatgpt.com/docs/windows/windows-sandbox
Merged fix matching the active-runtime file-lock failure we diagnosed:
#51822
These steps preserved the original chat, history, and project files. No task
recreation, app reset, database editing, or Full access mode was required.
pro-pete commentedon Oct 8, 2026
I'm experiencing the same issue with version 26.1002.52244 on Windows 11. I am using a Business subscription.
I need to approve every basic command inside the sandbox.
This was the Codex summary of the issue:
Cyber-neeXia commentedon Oct 8, 2026
Your error 32 appears to match the Windows runtime file-lock bug addressed by OpenAI’s PR #51822. The three successful commands are encouraging, but we should check whether normal sandbox execution remains working.
In the affected chat, select Ask for approval, then ask Codex:
“Run only hostname using the normal sandbox. Do not request execution outside the sandbox, stop helpers, change settings, or edit files. Report the output and exit code, or the exact sandbox error.”
If it fails, please share the error and the wording of one approval prompt, with private details removed. That will help distinguish a recurring setup failure from a permission-setting issue.
If error 32 persists, OpenAI documents windows.sandbox = "unelevated" as a temporary fallback. It provides weaker isolation, and your organization may restrict its use.
pro-pete commentedon Oct 8, 2026
This was the response after submitting the suggested prompt:
hostnamedid not start. No output or exit code was produced.Exact sandbox error:
CreateProcess { message: "Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")" }fenghaoxiang77-web commentedon Oct 8, 2026
Adding observations from my installation, including a recovery case that may help distinguish local execution from delegated-task execution.
Versions
26.1002.7124.026.1002.52244, build135360.162.0-alpha.2Failure and file ownership
Ordinary delegated commands using
use_defaultfailed before command launch:helper_unknown_error: setup refresh had errors.This affected basic
Get-Date, file-read, and file-write probes.The sandbox log reported
runtime read/execute validation failed,open ACL target for root-only update, and Windowsos error 32, involvingnode_repl.exeandVCRUNTIME140_1.dll.Module inspection and Windows Restart Manager identified
codex-computer-use-swift.exe, parented byChatGPT.exe, as the process loading the exact DLL involved. One targeted stop was followed by immediate helper respawn; ordinary delegated commands still failed. Restarting/updating had also not resolved the problem at that stage.Local success did not initially mean delegated success
Local Codex first reported configuring
[features] prefer_mxc = trueand passing its local tests. However, both an existing delegated task and a freshly created delegated task continued to fail before launch. These delegated tasks were initiated through dot rather than the successful local Codex conversation.Recovery observed, with limitations
Local Codex subsequently reported configuring
[windows] sandbox = "mxc"and removing the previousprefer_mxcflag. The app was also relaunched as administrator during this recovery sequence.At 2026-10-08 02:24:55 UTC, ordinary delegated
use_defaultexecution successfully wrote a small file within the task's allowed workspace and read it back exactly; exit code was0. No per-command escalation was requested for this successful probe.A separate project directory outside that task's allowed writable roots remained write-denied, while reads succeeded. This later access denial should not be confused with the earlier pre-launch setup failure. A Chinese-character path was verified as valid; garbled error output was a display issue.
I do not have independent confirmation of the selected sandbox backend. The configuration changes, app relaunch, and administrator launch were not tested independently, so this sequence does not establish which factor caused recovery. Persistence across another restart and a non-administrator launch remain unverified. This is a recovery observation, not a universal fix or a recommendation to change security settings.
The merged #51822 matches the runtime ACL/file-sharing failure, but I cannot confirm its inclusion in this installed bundle. Successful execution after changing configuration does not prove that the installed build contains the patch.
Could maintainers clarify the supported MXC configuration and expected behavior for delegated tasks, and identify the first Windows app build containing the runtime ACL fix?
Mirli-JVR commentedon Oct 8, 2026
Additional independently reproduced case from Windows 11 build 26300 (x64), ChatGPT Desktop / Codex & OWL 26.1002.52244, MSIX OpenAI.Codex 26.1002.7124.0, personal non-enterprise-managed PC. Detailed original report: #52090.
Local PowerShell command execution consistently fails before command launch with
exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors. Sandbox setup logs consistently reportruntime read/execute validation failed,open ACL target for root-only update,node_repl.exe, andos error 32(sharing violation). Reproduced October 8, 2026, 14:03:55 Europe/Madrid, including after full Windows reboot and a clean ChatGPT exit/restart with no remaining ChatGPT/Codex/Node processes before restart.Procmon comparison on the same node_repl.exe path, by codex-windows-sandbox-setup.exe:
CreateFile, Desired AccessRead Attributes, Synchronize, ShareModeRead, Write, Delete, OptionsOpen Reparse Point.CreateFile, Desired AccessRead Attributes, Synchronize, Maximum Allowed, ShareModeRead, Write, Delete.Additional checks:
node_repl.exeAuthenticode signature VALID, signed by OpenAI OpCo, LLC; no obvious ACL anomaly; Sysinternals Handle showed two node_repl.exe processes descended from the same ChatGPT.exe → codex.exe process tree, but did not establish a blocking file handle. McAfee Framework Host accesses this executable and themfesecminifilter is attached to C:, but McAfee causality is unproven. No AV disabling, ACL rewriting or sandbox-mode changes attempted.Please provide a supported patched version or safe recovery/rollback procedure preserving local files, projects and chats. Consolidating this case into #51777 rather than maintaining a duplicate issue.
Andy-rateria commentedon Oct 8, 2026
Same issue
SimplyShapedGames commentedon Oct 9, 2026
Additional independently reproduced case, 2026-10-09.
Environment:
After changing this chat from Full access to Approve for me, ordinary workspace execution failed before process launch:
Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")Sandbox logs at 2026-10-09 19:50:08 and 19:50:44 UTC identified:
runtime read/execute validation failedopen ACL target for root-only updateThe process cannot access the file because it is being used by another process. (os error 32)Affected runtime path, with user directory redacted:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\3dd31cfff853001c\bin\node_repl.exeRead-only process inventory showed running node_repl.exe processes from that runtime, but did not identify the specific conflicting handle owner. No helpers were stopped, ACLs reset, protection disabled, or sandbox configuration changed.
Control: the same command submitted with require_escalated passed automatic review and reached PowerShell. A separate exact-path deletion test removed a newly created 40-byte workspace probe using Remove-Item -Recurse -Force; exit 0 and ExistsAfter=false. Thus automatic review works, while ordinary sandbox startup remains broken. This is distinct from the Full access / approval_policy=never dangerous-command denial.
PR #51822 matches the ACL sharing-violation failure. Direct source checks found its directory-only MAXIMUM_ALLOWED change absent from both rust-v0.162.0-alpha.2 and rust-v0.162.1 acl.rs. This checks those source tags, not the contents of every desktop build. Local doctor reported a newer desktop build, but inclusion of the fix and eligibility were not verified, and no update was installed.
Please identify the first supported Windows desktop build shipping #51822 and a safe upgrade/recovery procedure that preserves active chats and projects.