You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows Computer Use / node_repl fails: spawn setup refresh uses AppData codex-windows-sandbox-setup.exe and returns os error 740 #25366
Running Codex as Administrator alone was not sufficient in this session while the thread stayed in Auto-review/default/workspace mode.
Switching the thread to Full access while Codex was running as Administrator allowed Computer Use to start successfully.
After that, Computer Use listed apps, targeted Notepad, typed text, and verified the document text.
Docs gap:
The Computer Use docs mention Windows active desktop behavior and that file/shell actions still follow sandbox settings. The Windows docs mention elevated/unelevated sandbox modes. I did not find a troubleshooting note that Windows Computer Use / node_repl may fail with spawn setup refresh / os error 740 unless the user runs Codex elevated and/or switches to Full access.
Suggested docs addition:
Add a Windows troubleshooting note to Computer Use docs for:
I tested it on my side and can confirm that switching the thread to Full access allowed Computer Use to start successfully. Before that, running Codex as Administrator alone was not enough in the default/workspace sandbox mode.
This confirms the issue is closely related to the Windows sandbox / node_repl startup path rather than Computer Use itself. Your explanation helped me unblock the feature, and I agree this would be useful to document as a Windows troubleshooting note.
The requested operation requires elevation. (os error 740)
The packaged helper under the WindowsApps resources path completes successfully, while the copied helper under the AppData bin path fails. Restarting Codex and invoking Computer Use directly with @Computer did not change the result.
What are any significant downsides to using unelevated vs elevated setting value? Obviously the Ai doenst know how to fix this inconcistency right? because the default seems to be elevated, but why does unelevated fix this? Should i be worried about security?
Activity
github-actions commentedon May 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
windows sandbox failed: spawn setup refresh#25226Powered by Codex Action
ElierHG commentedon Jun 1, 2026
I reproduced a related Windows Computer Use /
node_replfailure in Codex Desktop 26.527.7698.0 and found a workaround that may be worth documenting.Observed behavior:
Docs gap:
The Computer Use docs mention Windows active desktop behavior and that file/shell actions still follow sandbox settings. The Windows docs mention elevated/unelevated sandbox modes. I did not find a troubleshooting note that Windows Computer Use /
node_replmay fail withspawn setup refresh/os error 740unless the user runs Codex elevated and/or switches to Full access.Suggested docs addition:
Add a Windows troubleshooting note to Computer Use docs for:
windows sandbox failed: spawn setup refreshcodex-windows-sandbox-setup.exe ... requires elevation. (os error 740)amir-hasan666 commentedon Jun 3, 2026
Thanks, this was very helpful.
I tested it on my side and can confirm that switching the thread to Full access allowed Computer Use to start successfully. Before that, running Codex as Administrator alone was not enough in the default/workspace sandbox mode.
This confirms the issue is closely related to the Windows sandbox / node_repl startup path rather than Computer Use itself. Your explanation helped me unblock the feature, and I agree this would be useful to document as a Windows troubleshooting note.
MercYuriy commentedon Jun 3, 2026
Still reproduces on Codex Desktop Store package
26.601.2237.0after updating from26.527.3686.0.Environment:
en-US[windows] sandbox = "elevated"list_apps, Chrome automation, and minimalnode_replstartup fail before executionAfter the update, the failing helper path changed from:
to:
The new build still returns:
The packaged helper under the WindowsApps
resourcespath completes successfully, while the copied helper under the AppDatabinpath fails. Restarting Codex and invoking Computer Use directly with@Computerdid not change the result.MercYuriy commentedon Jun 3, 2026
What are any significant downsides to using unelevated vs elevated setting value? Obviously the Ai doenst know how to fix this inconcistency right? because the default seems to be elevated, but why does unelevated fix this? Should i be worried about security?
clark-mackey commentedon Jun 4, 2026
+1, same on 26.601.2237.0; unelevated workaround unblocks me
iceweasel-oai commentedon Jun 12, 2026
this is now fixed