Codex API image_generation silently ignores size/quality and returns gpt-image-2-codex auto output
What issue are you seeing?
Codex API image_generation silently ignores explicit size and quality parameters.
A request for gpt-image-2, quality=high, and size=2160x3040 is accepted through the Codex API / OAuth-backed image generation path, but the returned tool metadata is changed to:
model=gpt-image-2-codexquality=autosize=auto
The final PNG is not 2160x3040.
This makes the Codex API image path unreliable for workflows that require deterministic output dimensions.
Expected behavior
Codex API should either honor the requested size and quality, or return a clear error if deterministic size / quality is not supported by the Codex API image generation path.
It should not silently downgrade the request while still returning success.
Requested parameters
{
"type": "image_generation",
"model": "gpt-image-2",
"quality": "high",
"size": "2160x3040",
"output_format": "png"
}
Actual returned tool metadata
{
"type": "image_generation",
"model": "gpt-image-2-codex",
"quality": "auto",
"size": "auto",
"output_format": "png"
}
Observed PNG dimensions
1024x1536
1054x1492
1058x1487
1254x1254
1693x929
Clarification
This issue is not about the native OpenAI Images API.
It is specifically about the Codex API / OAuth-backed image_generation path silently converting an explicit gpt-image-2 high/custom-size request into gpt-image-2-codex with quality=auto and size=auto.
What steps can reproduce the bug?
Send a Codex API / OAuth-backed image_generation request with explicit gpt-image-2, quality=high, and size=2160x3040.
Example request shape:
{
"model": "gpt-5.5",
"instructions": "Generate the requested image.",
"input": [
{
"role": "user",
"content": "Create a professional vertical research infographic. The output must be exactly 2160x3040 PNG."
}
],
"tools": [
{
"type": "image_generation",
"model": "gpt-image-2",
"quality": "high",
"size": "2160x3040",
"output_format": "png"
}
],
"tool_choice": {
"type": "image_generation"
},
"store": false
}
Then inspect the returned response.created / response.completed tool metadata and the actual PNG dimensions.
Expected:
model=gpt-image-2
quality=high
size=2160x3040
PNG dimensions=2160x3040
Actual:
model=gpt-image-2-codex
quality=auto
size=auto
PNG dimensions are smaller than 2160x3040
What is the expected behavior?
Codex API should either honor the requested size and quality, or return a clear error if deterministic size / quality is not supported by the Codex API image generation path.
For a request with:
{
"type": "image_generation",
"model": "gpt-image-2",
"quality": "high",
"size": "2160x3040",
"output_format": "png"
}
The expected output should preserve the requested parameters:
model=gpt-image-2
quality=high
size=2160x3040
PNG dimensions=2160x3040
If Codex API cannot support this, it should fail explicitly with a capability or validation error.
It should not silently convert the request to gpt-image-2-codex, quality=auto, size=auto, and return a smaller PNG while reporting success.
Additional information
_No response_
7 Comments
Additional Timeline / Regression Window
This appears to be a regression rather than a long-standing unsupported behavior.
| Date / Time UTC | Observation |
|---|---|
|
2026-06-15 UTC| The same image generation workflow was still producing valid2160x3040PNG outputs that passed strict dimension validation. ||
2026-06-16 UTC| The same workflow started failing dimension validation. Requests still explicitly asked forgpt-image-2,quality=high,size=2160x3040, andoutput_format=png, but the returned PNGs were smaller. ||
2026-06-17 UTC| Repeated smoke tests continued to reproduce the downgrade through the Codex/OAuth-backed image path. |Hi Codex team, thanks for looking into this.
I did a quick re-check of the latest public state and wanted to share a concise update:
bug,app-server, andimagen.gpt-image-2as supporting configurablesize/quality.2160x3040size appears to be within the documentedgpt-image-2constraints.image_generationtool spec still appears to expose onlyoutput_format, withoutsize/quality.#28656,#29909) do not appear to address this silentgpt-image-2-codex / auto / autodowngrade.Could you please clarify whether deterministic
size/qualityis intended to be supported on the Codex/OAuth-backedgpt-image-2-codexpath?If it is not supported on that path, a clear capability or validation error would be much safer than completing successfully with smaller images.
The main production blocker for us is the silent downgrade behind an HTTP 200 / completed response. This makes it hard to distinguish “unsupported capability” from “successful generation” programmatically.
Thanks again.
This definitely doesn’t look intended. In it’s current state it’s hard to create small icons / pixel art, since I can’t properly control the downscale ratio. And directly generating a .webp also doesn’t work (anymore?)
<img width="1172" height="505" alt="Image" src="https://github.com/user-attachments/assets/b50f6cfa-9529-438f-95ff-b876273ef43a" />
also quality low is overridden to auto, lol.
Should I overload OpenAI server?
This was introduced when they rolled out the generations endpoints, I noticed it almost immediately, and they broke it both on responses and generations, neither one honors the size. It's also moderated much higher than API or even chatgpt endpoint.
Hi Codex team,
I ran an additional controlled A/B test to determine whether the downgrade was caused by the Responses image tool bridge or by the Codex image backend itself.
Both tests used the same active ChatGPT Pro OAuth account, prompt, and requested parameters:
Test A: Responses image-generation tool
200gpt-image-2-codex / medium / 1024x15361024x153641.5sTest B: Dedicated Codex Images endpoint
Endpoint:
200medium / 1024x15361024x153655.8sThe actual dimensions were verified directly from the PNG IHDR bytes rather than inferred from response metadata.
This suggests that the issue is not limited to the Responses tool bridge. The dedicated Codex Images endpoint also accepted the explicit
high / 2160x3040request but returned amedium / 1024x1536image.Could you please clarify whether deterministic
sizeandqualityare intended to be supported for the Codex OAuth image-generation path?If these controls are not supported, returning an explicit capability error would be much safer than silently completing with a lower-resolution image.
Thank you for looking into this.
If you want a script or skill, check https://github.com/luckyabsoluter/codex-imagegen-free-reference