DeepSeek thinking mode: missing reasoning_content in assistant messages causes 400 error

[nengqing-cpu]

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

1. Configure Codex to use a DeepSeek model with thinking mode
2. Send a multi-turn conversation (any task requiring multiple API calls/tool calls)
3. 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

[Statusnone420]

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 replay assistant.reasoning_content after 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]

https://github.com/meomeo-dev/deepseekx

[metrofun]

You can avoid the failing Chat reasoning_content history 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 -s

In TUI, create a workspace named deepseek (or dev/work/<project name>), add a route, then add a target with:

provider    DeepSeek
credential  env:DEEPSEEK_API_KEY
model       deepseek-v4-pro

Point Codex at the workspace:

model = "default"
model_provider = "swobu"

[model_providers.swobu]
name = "Swobu"
base_url = "http://127.0.0.1:7926/c/deepseek"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

OPENAI_API_KEY can be any non-empty placeholder for the loopback Codex provider; keep the real DeepSeek key in DEEPSEEK_API_KEY for 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-pro with 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_content field 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.