[Bug] DeepSeek V4 Flash Responses multi-tool continuation fails with reasoning_text 400 on 2.12.0

[Hzzz7]

Client or integration

Codex App

Provider or upstream service

Official DeepSeek API (https://api.deepseek.com)

OpenCodex version

2.12.0

Endpoint or capability

DeepSeek native Responses route (/responses), thinking/reasoning metadata replay, and multi-tool continuation for deepseek/deepseek-v4-flash.

Current behaviour

DeepSeek V4 Flash routed through the native Responses adapter completes plain-text turns and a simple single-tool continuation, but a controlled multi-tool continuation fails with:

The `reasoning_text` in the thinking mode must be passed back to the API.

The upstream failure is exposed to Codex App as HTTP 400, so the turn fails immediately without retrying.

The same controlled task completes successfully with DeepSeek V4 Pro.

Controlled comparison, all read-only with thinking effort high:

Task shape	V4 Flash	V4 Pro
Plain-text response, no tools	Success	Success
Read one file using one tool, then answer	Success	Success
Read a local health endpoint and one file, then synthesize the result	HTTP 400 reasoning_text, turn failed	Success

Flash failure sequence in one conversation:

1. Initial request: HTTP 200
2. Tool continuation request: HTTP 200
3. Later continuation request: HTTP 400 in 137 ms

Redacted request IDs:

• ocx-msq223nj-7e: HTTP 200
• ocx-msq227gx-7p: HTTP 200
• ocx-msq229y1-7q: HTTP 400, 137 ms

Pro control for the same multi-tool task:

• ocx-msq225tn-7l: HTTP 200
• ocx-msq22c1t-7r: HTTP 200
• Final answer completed

Expected behaviour

Every reasoning item returned before tool calls should be preserved and replayed in the subsequent stateless DeepSeek Responses request. This must continue to hold for later continuations involving multiple tool calls/results.

The multi-tool Flash turn should complete in the same way as the plain-text, single-tool, and Pro controls.

Minimal redacted request or reproduction

# Environment:
# - Windows
# - Codex App
# - OpenCodeX 2.12.0
# - official DeepSeek provider
# - model: deepseek/deepseek-v4-flash
# - thinking effort: high
# - no explicit providers.deepseek.modelAdapters override

# In a new Codex App task, ask Flash to:
# 1. Read the local OpenCodeX health endpoint using a read-only tool:
#    http://127.0.0.1:10100/healthz
# 2. Read the first line of an existing local text file using another read-only tool.
# 3. Synthesize both results in the final answer.

# Controls:
# A. Plain-text answer without tools: succeeds.
# B. Read one file with one tool, then answer: succeeds.
# C. The multi-tool sequence above: later continuation fails with HTTP 400.
# D. Repeat C using deepseek/deepseek-v4-pro: succeeds.

Actual response or error

HTTP 400

{
  "error": {
    "message": "The `reasoning_text` in the thinking mode must be passed back to the API.",
    "type": "invalid_request_error",
    "param": null,
    "code": "invalid_request_error"
  }
}

The Codex turn is marked failed and no automatic retry occurs.

Upstream documentation

• DeepSeek thinking-mode tool-call replay requirement:
  https://api-docs.deepseek.com/guides/thinking_mode#tool-calls
• DeepSeek Responses API compatibility:
  https://api-docs.deepseek.com/guides/responses_api

The expected behaviour is also a concrete client/provider requirement: DeepSeek rejects a thinking-mode continuation when prior reasoning is not passed back.

Suggested mapping or implementation notes

Please preserve and replay the complete plaintext reasoning item for DeepSeek's stateless Responses continuation, including later continuations after multiple tool results.

OpenCodeX 2.11.1 and 2.12.0 both contain the Flash Responses registry default, so this is not caused by 2.12.0 introducing the route. OpenCodeX 2.12.0 also includes requiresAdjacentResponsesToolResults for DeepSeek, but this controlled reproduction still fails.

The persisted provider configuration uses openai-chat as its provider adapter and has no explicit modelAdapters override; Flash uses the registry default openai-responses route for Responses inbound.

Additional context and attachments

This appears related to, but is not identical to, #875:

• [Bug] DeepSeek V4 Flash Responses route stalls after tool calls #875 described a stall after tool calls with HTTP 200 and no follow-up function_call_output.
• This reproduction sends follow-up requests, but a later continuation receives an explicit HTTP 400.

Related upstream/client issue:

• DeepSeek thinking mode: missing reasoning_content in assistant messages causes 400 error openai/codex#24500

No secrets, raw request bodies, complete logs, configuration files, account details, or credentials are attached.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Hzzz7]

Additional reproduction: a text-only user question became a two-tool continuation

I reproduced the same reasoning_text HTTP 400 in another fresh Codex App task. This adds an important boundary condition to the original report: the user prompt itself did not request tools, but the agent autonomously chose to inspect local context with two read-only shell calls.

User prompt, translated/summarized:

I am a lawyer planning livestream content on Douyin, Xiaohongshu, and WeChat Channels about automobile consumer-fraud cases. How should I organize the livestream work?

This could have been answered as a text-only strategy question. However, the Flash turn decided to inspect the current project directory and local memory/context before answering.

Actual event sequence

The official DeepSeek Flash request used:

• provider/model: deepseek/deepseek-v4-flash
• adapter: openai-responses
• inbound protocol: responses
• thinking effort: max
• no explicit modelAdapters override

First official Flash request:

• request ID: ocx-msq2rii7-1j
• HTTP 200
• duration: 19,796 ms
• input tokens: 23,674
• output tokens: 2,111
• reasoning output tokens: 1,940
• emitted two shell_command function calls

Both corresponding function_call_output items were recorded by Codex App. The immediate continuation then failed:

• request ID: ocx-msq2ry33-1l
• same conversation
• HTTP 400
• duration: 130 ms
• error: The reasoning_text in the thinking mode must be passed back to the API.
• no automatic retry; turn marked failed

No assistant answer was displayed.

Separate preceding failure

The same task initially attempted amd-radeon/DeepSeek-V4-Flash and received HTTP 429 (rate_limit_exceeded). That was a separate provider/adapter path and is not the reasoning_text failure. The reproduction above occurred afterward on the official DeepSeek provider with a new turn, where the first official Flash request returned HTTP 200 and only its tool continuation returned HTTP 400.

Why this matters

The risk is not limited to prompts that explicitly request multi-tool work. A seemingly text-only prompt can enter the failing path when the Codex agent autonomously calls multiple tools to inspect workspace or memory context.

A more precise trigger boundary is therefore:

1. Flash produces reasoning and one or more tool calls;
2. Codex records the tool outputs;
3. a subsequent stateless DeepSeek Responses continuation is sent;
4. the prior plaintext reasoning item is incomplete or absent in the replay;
5. DeepSeek rejects the continuation with HTTP 400.

All IDs above are local non-secret request identifiers. No raw request bodies, reasoning text, tool outputs, file contents, configuration, account information, or credentials are included.

[Hzzz7]

Successful control: Web Search completed inside one Responses request

A new fresh Codex App task using the same official deepseek/deepseek-v4-flash model and thinking effort max completed successfully. This successful control helps narrow the failing boundary.

The user asked the same lawyer-livestream strategy question. In this run, Flash chose Web Search and produced the final answer successfully.

OpenCodeX request record

Only one official Flash request exists for the entire completed turn:

• request ID: ocx-msq3509u-24
• provider/model: deepseek/deepseek-v4-flash
• adapter: openai-responses
• inbound protocol: responses
• HTTP 200
• duration: 52,808 ms
• send count: 1
• no recovery attempts
• input tokens: 43,682
• output tokens: 5,042
• reasoning output tokens: 3,145

Codex App recorded this event sequence within that turn:

reasoning
assistant commentary
web_search_call completed
reasoning
assistant final answer

There was no second OpenCodeX/DeepSeek HTTP request for a client-side tool-result continuation.

Contrast with the failing reproduction

The failing reproduction recorded:

official Flash request HTTP 200
two shell_command calls
two function_call_output items
second official Flash HTTP request
reasoning_text HTTP 400

This suggests that the defect is probably not all tool use in general. The stronger boundary is likely a client-managed tool-result continuation that requires a new stateless DeepSeek Responses request and replay of the previous reasoning item.

A Web Search that completes within one Responses request can succeed, while local shell/file tools that require Codex to submit function_call_output in a subsequent request can hit the replay defect.

AMD 429 is not required

The earlier real-world failing task did have a separate preceding amd-radeon/DeepSeek-V4-Flash HTTP 429, and that attempt shared the same OpenCodeX conversation identifier with the later official-DeepSeek turn. However:

• the AMD 429 produced no assistant message, reasoning item, or tool call;
• the original controlled Flash failure in this issue reproduced the same reasoning_text 400 without any preceding AMD request;
• therefore the AMD 429 may be an extra state/routing variable, but it is not necessary to reproduce the bug and is unlikely to be the direct cause.

No search results, final-answer content, internal reasoning text, raw request bodies, local file contents, configuration, account information, or credentials are included here.

[Wibias]

Hey @Hzzz7 please update to our latest version and report again! Thanks!

[Hzzz7]

Retest on OpenCodeX 2.13.0: original failure path now passes twice

Per the maintainer request, I updated from OpenCodeX 2.12.0 to the latest stable release, 2.13.0, and reran the original client-managed continuation path.

Upgrade validation

• previous version: 2.12.0
• tested version: 2.13.0
• /healthz: status=ok, version 2.13.0
• ocx ready: ready
• ocx config validate: valid
• persisted configuration SHA-256 was unchanged across the upgrade
• no explicit providers.deepseek.modelAdapters override
• Codex App was restarted after the catalog update; ocx doctor confirmed the in-memory app-server catalog matches the on-disk catalog

The 2.13.0 release notes include relevant fixes such as preserving parallel reasoning replay and binding reasoning replay to route identity.

Retest A

Fresh Codex App task, official deepseek/deepseek-v4-flash, thinking effort high.

Required sequence:

1. first independent local shell_command: read http://127.0.0.1:10100/healthz
2. after its result, second independent local shell_command: read the first line of an existing local text file
3. after both function_call_output items, synthesize a final answer

The task completed successfully. OpenCodeX recorded three requests in the same conversation, all through openai-responses:

• ocx-msqbz8nu-c: HTTP 200
• ocx-msqbzbqi-e: HTTP 200
• ocx-msqbzcxa-f: HTTP 200

For all three records, requested, selected, and actual model were deepseek-v4-flash. No recovery attempt and no reasoning_text error occurred.

Retest B

A second fresh task reversed the two local-tool operations while keeping them sequential and separate:

1. read the first line of the local text file
2. request /healthz
3. synthesize the final answer

It also completed successfully, again with three official Flash Responses requests in one conversation:

• ocx-msqc01hy-j: HTTP 200
• ocx-msqc0448-l: HTTP 200
• ocx-msqc05ug-m: HTTP 200

Again, requested, selected, and actual model were all deepseek-v4-flash, adapter openai-responses, with no recovery and no HTTP 400.

Current result

The exact class of failure that reproduced on 2.12.0 — multiple local tool calls followed by client-managed function_call_output continuations — did not reproduce in either of two fresh 2.13.0 tests.

On this Windows/Codex App environment, the 2.13.0 reasoning-replay fixes appear effective for the reported case. I will continue normal use and report again if the 400 reappears under a different continuation shape.

No raw request bodies, internal reasoning text, tool output contents, full logs, configuration, account data, or credentials are included here.

[Ingwannu]

Thanks for the detailed retest. Your two fresh 2.13.0 controls exercised the original client-managed multi-tool continuation path with three Responses requests each, and all six requests completed without the reasoning_text 400. That matches the reasoning replay and route-identity fixes shipped after 2.12.0.

I am closing this as resolved in 2.13.0. If it recurs on a current release, please open a new report with the exact version and the smallest redacted continuation sequence so we can distinguish a new replay shape from this fixed case.