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)

1. .codex/.sandbox/sandbox.<date>.log shows 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)

1. 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 MicrosoftWindows.Client.CBS_cw5n1h2txyewy`)

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).

1. 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.