Repository navigation
DeepSeek thinking mode: missing reasoning_content in assistant messages causes 400 error #24500
Description
Description
When using Codex with DeepSeek models in thinking mode (e.g., deepseek-v4-pro, deepseek-reasoner), multi-turn conversations fail with:
400 Bad Request
{"error":{"message":"The `reasoning_content` in the thinking mode must be passed back to the API.","type":"invalid_request_error"}}
Root Cause
DeepSeek API requires that every assistant message in conversation history includes a reasoning_content field when thinking mode is enabled. This is documented at https://api-docs.deepseek.com/guides/thinking_mode#tool-calls.
Codex correctly captures reasoning content internally (ReasoningItem::raw_content in codex-rs/protocol/src/items.rs:120), but when building the messages array for the next API request, the reasoning_content field is not included in the serialized assistant message.
Steps to Reproduce
- Configure Codex to use a DeepSeek model with thinking mode
- Send a multi-turn conversation (any task requiring multiple API calls/tool calls)
- After the first turn produces reasoning content, the second API request fails with the above error
Expected Behavior
When using DeepSeek thinking mode, each assistant message in the API request should include:
{
"role": "assistant",
"content": "...",
"reasoning_content": "..."
}Affected Code
The conversion from ResponseItem::Reasoning → TurnItem::Reasoning in codex-rs/core/src/event_mapping.rs:156-182 preserves raw_content, but the downstream serialization to API-compatible messages does not map it to the reasoning_content field required by DeepSeek.
Related Issues
This is a known pattern affecting multiple projects using DeepSeek API:
- openai/openai-agents-js#791
- openai/openai-agents-python#2155
- RooCodeInc/Roo-Code#10175
- anomalyco/opencode#25311
Suggested Fix
When building the messages array for provider API calls, for DeepSeek models specifically, include reasoning_content from ReasoningItem::raw_content in every assistant message. For other providers (OpenAI), omit it as before (OpenAI ignores unknown fields but DeepSeek requires this field).
Environment
- Codex version: latest
- Model: deepseek-v4-pro (thinking mode)
- OS: macOS
Activity
Statusnone420 commentedon May 25, 2026
I took a quick look at current
main. This may not be a small field-mapping fix in Codex itself because custom providers now appear to be Responses-only:wire_api = "chat"is rejected, and streaming goes through/v1/responses.Codex does preserve reasoning as
ResponseItem::Reasoning.content, but DeepSeek’s documented requirement is specifically for Chat Completions history messages to replayassistant.reasoning_contentafter tool-call turns. If this is happening through a local Responses→Chat proxy, the missing replay may belong in that proxy/adapter rather than Codex’s native Responses request path.Could you share the exact provider config and whether a proxy/adapter is being used?
92645417d9e5c763259dbebc306e3e commentedon May 26, 2026
https://github.com/meomeo-dev/deepseekx
metrofun commentedon Aug 3, 2026
You can avoid the failing Chat
reasoning_contenthistory path by keeping Codex on its Responses client surface and routing that through DeepSeek's native Anthropic-compatible Messages endpoint using local compatibility gateway.Install Swobu:
curl -fsSL https://swobu.com/install.sh | sh -sIn TUI, create a workspace named
deepseek(ordev/work/<project name>), add a route, then add a target with:Point Codex at the workspace:
OPENAI_API_KEYcan be any non-empty placeholder for the loopback Codex provider; keep the real DeepSeek key inDEEPSEEK_API_KEYfor Swobu.I tested the released binary with the actual Codex CLI: Codex made a shell tool call, returned the tool result, and completed through
deepseek-v4-prowith thinking enabled.This is an alternate provider path, not a Codex fix. It avoids Responses→Chat conversion entirely, so there is no Chat assistant
reasoning_contentfield for Codex or a proxy to reconstruct.Disclosure: I maintain Swobu. If you try this with the original task, please share whether the multi-turn tool loop completes.