DeepSeek rejects the Codex turn where a resize notice separates a call from its output

Three conditions have to line up. Codex has to batch two `view_image` calls into a single turn. At least one image has to trip the resize path, which keys off pixel dimensions and not file size ^[12]. And the provider has to require that a tool output sit directly after its own call ^[14]. Remove any one of the three and the turn goes through: with a single image, the notice lands after the output and nothing breaks ^[15].

The rollout log the author pulled out of `~/.codex/sessions` covers the whole sequence in 573 milliseconds ^[18][9]. Two `view_image` calls went out at 26.172 and 26.350 seconds, the output for the first at 26.376, the `<image_resize_notice>` developer message at 26.377, and the second output at 26.382 ^[10]. So the notice landed one millisecond after the first output and five milliseconds before the second ^[20]. The 400 came back at 26.745 ^[10].

Codex resends the full history on every turn, so that same ordering goes back out with each subsequent message and draws the same rejection against the same call ID ^[4][3]. Resuming the thread replays it ^[4]. "I typed something much less polite. Same error, same call ID," the author wrote ^[16].

Neither the model nor the image is involved. According to the issue the post cites, deepseek-ai/awesome-deepseek-integration#740, OpenAI's Responses API matches a `function_call` to its `function_call_output` by `call_id` wherever the two items sit in the list ^[13]. DeepSeek's Responses-compatible endpoint wants them adjacent, and the issue reproduces the difference cleanly: put a developer message or a reasoning item between a call and its output and you get the 400, keep them adjacent and you get a 200 ^[14]. The same conversation JSON is valid against one endpoint and invalid against the other.

The width rule needs a caveat before it transfers to your setup. Pre-shrinking to 1500 px wide keeps a capture under about 2.5 million pixels only while it stays under roughly 1,667 px tall ^[19]. A full-page render of a long document clears that at any sensible width, so the viewport-only half of the rule is what keeps the resize path from firing at all ^[5]. The threshold figure of roughly 2048 px, or about 2.5 million pixels, comes from CodexPlusPlus#2275 as quoted in the post ^[12].

The evidence is three dead threads from one user on Codex Desktop, configured with `model_provider = "deepseek"` and `wire_api = "responses"` ^[7][6], plus the reproduction in issue #740 ^[14]. The first hypothesis in the post, a dropped image output or an oversized file, did not survive the log: the image was 91 KB and was resized on pixel count, and both `function_call_output` items were present ^[8][11].

The call ID in the error message is enough to find the evidence. Running `grep -rl` for it across `~/.codex/sessions` returns the rollout JSONL, where the item order is readable in plain text ^[9]. The author has packaged the prompt rules as an agent skill for Codex and Claude Code, published as unstuck-qa ^[17].