Skip to content

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) #32937

Open
Open
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)#32937
Labels
appIssues related to the Codex desktop appbugSomething isn't workingimagensandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@acsghsc
acsghsc
opened on Jul 14, 2026

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)

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

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    imagen
    on Jul 14, 2026

  2. github-actions commented on Jul 14, 2026

    @github-actions
    github-actionsBot
    on Jul 14, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. acsghsc commented on Jul 15, 2026

    @acsghsc
    acsghsc
    on Jul 15, 2026
    Author

    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/codex 0.144.4 (latest stable): any tool execution (codex exec running 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/codex 0.145.0-alpha.12 (published 2026-07-15, so presumably including the July 13 windows-sandbox commits like Coalesce concurrent Windows sandbox setup requests #32864): identical failure.

    Note the CLI error string setup refresh had errors matches 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 the CodexSandbox* 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/CodexSandboxOffline local 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.4 on win32-x64 also failed to install the platform binary (Missing optional dependency @openai/codex-win32-x64); had to manually extract the 0.144.4-win32-x64 tarball into the package's node_modules. Same for the alpha.

  4. 1968532942-collab commented on Aug 13, 2026

    @1968532942-collab
    1968532942-collab
    on Aug 13, 2026

    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.

  5. xcai413 commented on Sep 7, 2026

    @xcai413
    xcai413
    on Sep 7, 2026

    Adding a matching Windows 11 / Codex Desktop reproduction with a sandbox-vs-host comparison.

    Observed:

    • Built-in image_gen failed repeatedly with network error: error sending request for url (https://chatgpt.com/backend-api/codex/images/generations) and later connection failed: error sending request.
    • The ChatGPT-authenticated account was not rate limited.
    • Inside the Codex sandbox, both curl and .NET Invoke-WebRequest failed during TLS initialization with Schannel SEC_E_NO_CREDENTIALS / 0x8009030E (AcquireCredentialsHandle: no credentials are available in the security package).
    • The same read-only HTTPS probe, using the same local HTTP proxy, succeeded outside the Codex sandbox and reached chatgpt.com (received an HTTP response from Cloudflare). This rules out a general Windows TLS outage and confirms that the proxy tunnel itself is reachable.
    • CryptSvc and KeyIso were running normally.
    • Local .codex/.sandbox logs repeatedly contain SetNamedSecurityInfoW failed: 5 and setup refresh completed with errors, including ACE failures on protected project metadata directories.
    • Fully exiting/restarting Codex did not resolve the failure.

    This appears to be the same Windows sandbox ACL/provisioning failure family described here, with Schannel credential acquisition as an additional downstream symptom. The built-in image tool currently surfaces only the generic network error, while the sandboxed TLS probe exposes the underlying 0x8009030E failure.

    All paths, usernames, project names, credentials, proxy provider details, and tokens have been omitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingimagensandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions