Repository navigation
Built-in image generation repeatedly fails with network error after July 9 desktop update #32297
Description
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 image_gen returns image data in session records but no image is shown, saved, or exposed as a path #32153, Invalid Value: 'tools'. Function 'image_gen.imagegen' conflicts with a hosted tool in the same request #32208, and forbidden error code 404 #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.
Activity
LastFlowerSociety commentedon Jul 11, 2026
Same issue.
weijie-he commentedon Jul 11, 2026
Same issue.
leo678910 commentedon Jul 12, 2026
same issue
zq123123667 commentedon Jul 13, 2026
same issue
zmq2163 commentedon Jul 13, 2026
same issue, anybody solve it?
jfbergado commentedon Jul 13, 2026
I got same issue, my alternative is Product Design plugin to generate image.
ivanchiu12 commentedon Jul 14, 2026
same here
acsghsc commentedon Jul 14, 2026
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.Windows Application event log (Event ID 1509) shows the trigger: the sandbox now provisions dedicated local accounts (
CodexSandboxOnline/CodexSandboxOffline), and profile initialization for them fails while copying TrustedInstaller-protectedWindowsAppsapp-execution-alias reparse points fromC:\Users\Default("Access is denied").The broken sandbox then can't run any tool — image generation surfaces this as a generic "network error" (the request likely never leaves the machine), and file-reading tools fail with "tool execution environment failed to start".
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.
Evolan-wu commentedon Jul 15, 2026
same issue
InfiniteRandomVariable commentedon Jul 15, 2026
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.
tuantuanmeow commentedon Jul 15, 2026
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.
xm2by commentedon Jul 15, 2026
same issue
waitingformywind commentedon Jul 15, 2026
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.
okokelly commentedon Jul 19, 2026
same issue today with my Mac version codex
tapingdance commentedon Jul 21, 2026
same issue
yangcai0731 commentedon Jul 23, 2026
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.
tonycky commentedon Jul 24, 2026
Try this and it works for me.
https://github.com/eagleagentic/codex-imagegen-143
Mindy2000 commentedon Jul 26, 2026
I have the same issue, and my version is the latest one. Sometimes it works, sometimes not
njiangk commentedon Jul 29, 2026
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.JarvisArt commentedon Jul 29, 2026
I'm encountering the same issue; I hope it can be fixed quickly.
seancheung commentedon Aug 1, 2026
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?
tf511421-ctrl commentedon Aug 13, 2026
同样的问题
1968532942-collab commentedon Aug 13, 2026
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.
cph748963966 commentedon Sep 4, 2026
Additional macOS reproduction with unusually consistent ~5-minute failures.
Environment
26.901.20858(build7658)0.153.0-alpha.526.6.1(build25G76), Apple Silicon (arm64)image_gen; no API-key fallbackObserved behavior
On 2026-09-04, built-in image generation repeatedly failed after approximately 5 minutes with:
A fresh diagnostic generation used a text-only, policy-safe historical illustration prompt with no reference images. It remained in progress for about 303 seconds, then returned the same network error.
Earlier attempts in the same environment showed the same pattern on both routes:
images/generations: failures after approximately 310, 310, and 326 secondsimages/edits: failures after approximately 311 and 312 secondsThere was no moderation-blocked result, HTTP status, structured backend reason, or safe request/correlation ID in the caller-visible failure.
Useful comparison
This is intermittent rather than a total loss of image capability:
The successfully returned PNG was about 3.0 MiB, only modestly larger than successful Codex-generated images, so result size alone does not explain the failures.
Request
Please investigate whether the Codex-specific image request is being terminated by an upstream/backend deadline near 300 seconds, or whether a completed result is being lost during response delivery. It would help to:
I can provide narrowly scoped, redacted timestamps if a maintainer identifies the exact diagnostic fields needed.
yxspace commentedon Sep 5, 2026
Additional macOS reproduction on Sep 5, 2026.
Environment
image_gen; no API-key fallbackObserved behavior
Ordinary Codex operations and browser access continued to work during the failures. No generated image file was returned or saved. The prompt was a benign Excel learning-material poster and explicitly avoided logos, fake sales, and outcome claims.
This looks consistent with an intermittent Codex image endpoint/backend deadline or response-delivery problem rather than a general local connectivity or prompt-policy issue. A structured failure reason, request ID, and retry guidance would make this much easier to diagnose.
flickerfox commentedon Sep 5, 2026
Additional macOS reproduction in Work (local task): built-in image editing repeatedly fails
Environment
Observed behavior
Multiple attempts to edit one valid, readable JPEG with the built-in image tool inside this Work/local task failed after several minutes. No edited image or partial result was returned. Text conversation within the task and local tools continued to work.
This report concerns the Work/local-task image tool specifically. A same-image comparison with ordinary ChatGPT Chat has not yet been performed in this environment. The Work context is supplied for routing and reproduction, not as a confirmed cause.
The exact error was:
One instrumented call showed five internal request failures roughly 61–63 seconds apart, producing a total wait of about five minutes. This means the overall duration should not be assumed to represent one continuous five-minute generation. The client reported failure before receiving HTTP response headers and did not expose a status code, detailed transport cause, or image request/job ID.
Expected behavior / request
Please investigate the built-in image-edit request lifecycle and expose a structured failure reason and a safe correlation ID. If a job can continue after the connection ends, a way to resume or retrieve its result would help avoid repeating the entire request.
No images, account identifiers, local paths, session transcripts, or raw logs are attached. The exact underlying cause has not been established.