Image generation ("Codex Image 2") fails with generic "network request failed" — root cause is sandbox setup failing to create/init dedicated Windows accounts (CodexSandboxOnline/Offline)
Environment
- OS: Windows 11 Pro
- Codex CLI: @openai/codex 0.142.4 (also affects Desktop app, e.g. build 26.707.8168.0)
- sandbox_mode = "workspace-write", [windows] sandbox = "elevated" in config.toml
Symptom
Codex Image 2 (in-app image generation) fails with a generic "network request failed"
message, without generating any image. Restarting the Codex app as Administrator does
NOT resolve it.
Root cause found (via local log inspection)
.codex/.sandbox/sandbox.<date>.logshows repeated errors starting the day of a
client update:
``
write ACE failed on <project folder>: SetNamedSecurityInfoW failed: 5
write ACE failed on C:\tmp: SetNamedSecurityInfoW failed: 5
grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_<version>\app
for sandbox_group: SetNamedSecurityInfoW failed: 5
(Error 5 = ERROR_ACCESS_DENIED)
- Windows Application event log (Event ID 1509) shows the actual trigger: Codex's
Windows sandbox now provisions two dedicated local accounts,
CodexSandboxOnline and CodexSandboxOffline. During profile initialization for
these new accounts, Windows fails to copy protected reparse-point entries from the
Default profile template:
``
Windows cannot copy file \?\C:\Users\Default\AppData\Local\Microsoft\WindowsApps\Backup
to \?\C:\Users\CodexSandboxOnline\AppData\Local\Microsoft\WindowsApps\Backup ...
Access is denied.
(same for
These WindowsApps entries are TrustedInstaller-protected app-execution-alias
reparse points; a newly created standard/administrator account cannot copy them
without elevated system-level privileges beyond normal admin token. This appears to
break sandbox account provisioning, which cascades into the ACE-grant failures above,
which in turn appears to surface to the end user as a generic "network request failed"
during image generation (the sandboxed process likely never gets to the network call).
- Ruled out: no antivirus / Controlled Folder Access is active on this machine
(Defender real-time protection service not even running), so this is not a
third-party security software conflict.
Expected behavior
Either the sandbox account provisioning should tolerate/skip this WindowsApps alias
copy failure gracefully, or image generation should surface the real underlying error
instead of a generic network failure message.
Repro frequency
Started appearing in sandbox logs starting one specific day (client auto-update),
0 occurrences in logs from the prior ~2 weeks.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Update — tested the CLI directly, which gives a much more honest error message than the desktop app, plus verified the bug is still present in the latest builds:
@openai/codex0.144.4 (latest stable): any tool execution (codex execrunning a trivial read-only PowerShell command) fails immediately with:``
ERROR codex_core::exec: exec error: windows sandbox: helper_unknown_error: setup refresh had errors
@openai/codex0.145.0-alpha.12 (published 2026-07-15, so presumably including the July 13 windows-sandbox commits like #32864): identical failure.Note the CLI error string
setup refresh had errorsmatches verbatim the entries in.codex/.sandbox/sandbox.<date>.log(write ACE failed on <dir>: SetNamedSecurityInfoW failed: 5→setup error: setup refresh had errors). So the desktop app's "network request failed" during image generation and the CLI's sandbox error are the same underlying failure: sandbox setup never completes on machines where theCodexSandbox*account provisioning hit the WindowsApps reparse-point copy failure (details in the issue body above).Since provisioning of the sandbox accounts already failed once, newer builds appear unable to recover — possibly the broken account/profile state persists. If someone from the team can suggest how to fully reset the sandbox state (e.g. deleting the
CodexSandboxOnline/CodexSandboxOfflinelocal accounts + profiles and letting Codex re-provision), I'm happy to test.Side note: unrelated to the sandbox,
npm install -g @openai/codex@0.144.4on win32-x64 also failed to install the platform binary (Missing optional dependency @openai/codex-win32-x64); had to manually extract the0.144.4-win32-x64tarball into the package'snode_modules. Same for the alpha.I can reproduce this issue on the Codex Windows App, and I was able to isolate a difference between text-to-image generation and reference-image generation.
Environment:
Codex App: 26.803.10989.0
Windows 11 Home 25H2, OS Build 26200.9168
ChatGPT Plus
I ran two tests on the same machine in the same Codex session:
Text-to-image:
A simple prompt ("generate a red apple on a white background") completed successfully in 45 seconds.
Reference-image generation/edit:
I uploaded a reference image and asked Codex to generate a new image while preserving its visual style. After 11 minutes 13 seconds, Codex reported that the image-generation service encountered network transmission errors twice and no image was produced.
I have previously observed:
/codex/images/generations → network send failed
/codex/images/edits → network send failed
At the moment, /images/generations can work normally, while the reference-image /images/edits path appears to be significantly more unstable.
Restarting Codex and signing out/in did not resolve the issue. Regular ChatGPT image generation works normally with the same account.
I also checked the Windows Codex sandbox logs. Unlike #32937, my log does not contain setup refresh had errors or SetNamedSecurityInfoW failed: 5; the sandbox refresh reports errors=[]. Therefore, my case may not be caused by the same sandbox provisioning failure described in #32937.