[xiaoyaner0201]

Summary

Refs #14617.

Codex GPT Image models now use the dedicated Codex Images API routes instead of the Responses hosted image_generation tool:

• gpt-image-* generation → /backend-api/codex/images/generations
• reference-image edit → /backend-api/codex/images/edits
• requested image model is forwarded unchanged
• upstream usage is preserved on the internal result for the follow-up usage-accounting slice
• existing GPT-5.6 *-image catalog entries remain on the hosted Responses tool path

This removes the hosted-tool failure mode where the backend pins the image model to gpt-image-2-codex and where the chat model can decline to call the tool. It does not claim that the backend's output alone proves which image model served a request; the fix establishes the correct dedicated route and request model contract.

The implementation keeps the existing Codex free-plan guard, sibling-account retry classification, error sanitization, response defaults, reference-image handling, and n>1 fan-out. Fan-out is capped at 10 per request, and response-body read failures become a controlled 502 instead of escaping as an unhandled exception.

Tests

Focused suite on the exact release/v3.8.51-rebased candidate:

34 passed, 0 failed

Also passed:

• ESLint on changed production/test files
• Prettier check
• file-size gate
• diff check
• changelog fragment changelog.d/fixes/14976-codex-dedicated-images.md

Focused coverage includes generation, n>1, response formatting, free-plan/access errors, sanitization, unreadable response bodies, multipart reference edits, route dispatch, and preservation of the GPT-5.6 hosted-tool path.

Boundary

size remains forwarded but is not asserted as a backend guarantee: the Codex Images backend chooses the actual output dimensions, as documented in the linked issue evidence.

[xiaoyaner0201]

I reviewed the exact Draft head 876f2eca7ecb62063030af05b373f2a157e47009 against #14617. The dedicated route shape and hosted-tool compatibility look right, but two guards need closing before this goes Ready:

1. Bound upstream response bodies before decoding. open-sse/handlers/imageGeneration/providers/codexImages.ts:217-219 calls response.text() for successful and error responses without a byte limit. A large or chunked upstream body is buffered in full; n can fan out up to 10 such responses. Check Content-Length where present and count actual streamed bytes (including chunked transfers), cancelling on excess. Keep separate success/error caps. This is an upstream-response limit, distinct from the edit route's ingress-image limit.
2. Reject malformed n before fan-out. The handler only guards requestedCount > 10 at :142-151; the outer handler normalizes n=0, negative, and fractional values to one call, so those requests succeed rather than receiving a 400. Validate a finite safe integer in the supported range at the new-path boundary; the hosted-tool path can remain unchanged.

I ran a three-case regression against that exact head in an isolated detached worktree with a mocked upstream: 0/3 pass. The n=0 case returned success; a response advertising a 1 GB Content-Length and a 41 MiB chunked response both reached the generic no b64_json image result rather than being stopped as oversized. These tests make no live provider request and touch no production instance. This is feedback on the current Draft head, not a claim that the backend serves a particular image model or that the separate pricing/accounting issue is solved.

[diegosouzapw]

Re-homed to release/v3.8.52: v3.8.51 entered its release freeze, so the branch now belongs to the release captain and development continues on the next cycle. Nothing is wrong with this PR — it just needed a live base. No action needed from you; CI will re-run against the new base.