Built-in image generation repeatedly fails with network error after July 9 desktop update
What version of the Codex App are you using?
Current Codex Desktop build installed after the July 9, 2026 update. The exact About-dialog version was not available in this session.
What subscription do you have?
ChatGPT subscription using the normal Codex Desktop sign-in.
What platform is your computer?
macOS, Apple Silicon.
What issue are you seeing?
The built-in image_gen tool repeatedly fails while sending the generation request to the Codex image endpoint.
The returned error is:
image generation failed: network error: error sending request for url
(https://chatgpt.com/backend-api/codex/images/generations)Ordinary text conversations and other Codex operations continue to work in the same session. This appears specific to the built-in image-generation route rather than a general loss of connectivity.
Two separate image-generation attempts failed in the same way. Each request remained in a generating state for several minutes before returning the network error.
What steps can reproduce the bug?
- Open Codex Desktop.
- Start a normal local task.
- Ask Codex to use its built-in image generation tool to create a new image.
- The request stays in the generating state for several minutes.
- It eventually fails with the network error shown above.
- Retry with a different, shorter prompt; the same failure occurs.
What is the expected behavior?
The built-in image generation request should complete and display or save the generated image. If the image service is unavailable, the app should fail promptly with a useful status instead of waiting several minutes.
Additional information
- Reproduced twice on July 11, 2026.
- The prompts contained no reference images or unusual input.
- Related recent reports after the same update window may include #32153, #32208, and #32038, although their visible failure modes are not identical.
- No full diagnostic bundle is attached because it may contain unrelated local environment information. Additional narrowly scoped diagnostics can be provided if maintainers specify exactly which fields are needed.
23 Comments
Same issue.
Same issue.
same issue
same issue
same issue, anybody solve it?
I got same issue, my alternative is Product Design plugin to generate image.
same here
Same issue here (Windows 11 Pro, CLI 0.142.4 / desktop 26.707.8168.0, started ~July 13 after auto-update). I did some local log digging and found what appears to be the root cause — it may not actually be a network problem. Full analysis in #32937 (also related: #32440).
Summary:
.codex/.sandbox/sandbox.<date>.logshows the sandbox setup failing repeatedly withSetNamedSecurityInfoW failed: 5(ERROR_ACCESS_DENIED) when granting write ACEs on project folders and even read ACEs on Codex's own install dir underC:\Program Files\WindowsApps\. Zero occurrences in logs before the update, dozens per day after.CodexSandboxOnline/CodexSandboxOffline), and profile initialization for them fails while copying TrustedInstaller-protectedWindowsAppsapp-execution-alias reparse points fromC:\Users\Default("Access is denied").Ruled out on my machine: antivirus/Controlled Folder Access (none active), proxy (none), TCP 443 connectivity to chatgpt.com/api.openai.com (fine). Reinstalling / running elevated does not help, consistent with reports here.
same issue
Temporarily solution is to use Gpt-5.5 for image generating tasks by reverting back to pre GPT-5.6 versions such as 0.138 or equivalent. The 0.144 is highly unstable, sometimes work, mostly not working for imagegen.
I used Qoder to fix the Codex, and it seems to be working.
C:\Users\admin\.codex\config.toml
find:
[windows]
sandbox = "elevated"
change to:
[windows]
sandbox = "unelevated"
This can bypass the problematic sandbox permission initialization. Note: This will reduce the security of sandbox isolation, but can restore image generation functionality, suitable as a temporary solution before waiting for an official fix.
same issue
Additional Windows reproduction on 2026-07-15.
Environment
26.707.9981.026200.8655, x64image_genusing the normal ChatGPT sign-in (no API/CLI fallback)[windows] sandbox = "elevated"Observed behavior
A new-image request with no reference images and an ordinary prompt remained in the generating state for roughly 3–4 minutes, then failed with the exact error reported here:
Normal Codex conversation and other tools continued to work in the same task.
Read-only checks
chatgpt.comwas available.SetNamedSecurityInfoW failed: 5setup refresh had errorshelper_unknown_errorERROR_ACCESS_DENIEDCodexSandboxOnlineorCodexSandboxOfflinewas found in the previous seven days.This confirms that the failure is still reproducible on a newer Desktop build. On this machine it does not match the sandbox-account provisioning failure described in #32937, so there may be more than one failure mode behind the same generic image-generation network error. The original report here is also on macOS.
It would help if the app exposed the underlying HTTP/auth/service error or a request correlation ID instead of collapsing these failures into a generic network error.
same issue today with my Mac version codex
same issue
Additional macOS reproduction on 2026-07-23.
Environment
26.715.72359(build5718)0.145.0-alpha.3015.4(build24E248)arm64Observed behavior
A built-in image-generation request fails with the same caller-visible error reported in this issue:
Normal Codex text conversation remains usable. The caller-visible failure is limited to the built-in image-generation request.
This app/runtime combination is newer than several builds already reported in this thread, so the problem remains reproducible on a later macOS build. The generic error does not expose an HTTP status, backend reason, or request/correlation ID, making it impossible to distinguish transport failure, queue timeout, rate limiting, authentication, or result-delivery failure from the client side.
Please expose the underlying structured error or a safe request ID, and investigate the Codex-specific image-generation request lifecycle.
Try this and it works for me.
https://github.com/eagleagentic/codex-imagegen-143
I have the same issue, and my version is the latest one. Sometimes it works, sometimes not
Additional reproduction from macOS on 2026-07-29 (UTC+8).
Environment
image_genarm64)0.145.0OPENAI_API_KEYwas used; this was the built-in image toolObserved behavior
A complete text-only UI concept generation succeeded once earlier in the same workflow. After that, at least seven attempts failed across both endpoints:
and, when editing the previously generated local PNG:
The failures reproduced with:
Normal Codex conversation, shell tools, web access, and GitHub operations continued to work.
Local connectivity checks
Unauthenticated probes from the same Mac showed that the relevant hosts were reachable:
chatgpt.com/backend-api/codex/images/generations: DNS/TCP/TLS completed; HTTP 403 without session credentials, as expected for an unauthenticated probeapi.openai.com/v1/models: DNS/TCP/TLS completed; HTTP 401 without an API keystatus.openai.com: HTTP 200These probes do not validate the authenticated long-running image request, but they make a general local DNS/TLS outage less likely.
Impact and request
This blocks a UI redesign workflow that requires an image concept before implementation. Please investigate whether the built-in image route is intermittently losing ChatGPT authentication/entitlement state, timing out in the image backend, or collapsing a structured backend response into a generic transport error.
It would help if failures exposed a safe correlation/request ID, the underlying HTTP/status category, and retry guidance rather than only
error sending request for url.I'm encountering the same issue; I hope it can be fixed quickly.
Can't generate a single image in the mac desktop app. I have to interrupt it and ask for the prompts to generate images on website and copy it back. So annoying. When will this be fixed?
同样的问题
I can reproduce what appears to be the same issue on the Codex Windows App.
Environment:
26.803.10989.026200.9168Previously, built-in image generation usually completed in about 2 minutes. Recently, the same type of image-generation task often takes 20+ minutes. Sometimes it eventually succeeds, while other attempts fail with a network send error.
I have observed failures on both routes:
/codex/images/generations→ network send failed/codex/images/edits→ network send failedAdditional troubleshooting:
So this does not appear to be limited to macOS, and in my case the issue affects Windows as well. The requests sometimes eventually succeed after 20+ minutes rather than always failing immediately.