DeepSeek V4 Flash Responses tool calls stall in Codex App after upgrade from 2.8.0 to 2.10.0

[MAOKO1993]

Client or integration

Codex App

Provider or upstream service

DeepSeek official API

OpenCodex version

@bitkyc08/opencodex 2.10.0 (upgraded from 2.8.0)

Endpoint or capability

/v1/responses; tool-call continuation / MCP

Current behaviour

After upgrading OpenCodex from 2.8.0 to 2.10.0, I switched a Codex App session to deepseek/deepseek-v4-flash. The initial native Responses request succeeds, but the turn stalls when the model returns tools.

Observed on repeated retries:

• The request uses the native Responses path (inboundProtocol=responses).
• The upstream request returns HTTP 200 with non-zero output and reasoning tokens.
• The model returns tool calls such as list_mcp_resources, list_mcp_resource_templates, and exec_command.
• No corresponding function_call_output or follow-up Responses request is sent.
• Codex App remains inProgress with no final visible assistant answer.
• Plain-text turns without tools can complete normally.

Expected behaviour

After a tool call, OpenCodex should execute the tool, send its result as function_call_output, issue the follow-up Responses request, and deliver the final assistant answer.

Upgrading from 2.8.0 to 2.10.0 should not leave Codex App turns stuck after tool or MCP calls.

Minimal redacted request or reproduction

Environment: macOS; Codex App; OpenCodex proxy at http://127.0.0.1:10100/v1; official DeepSeek API.

1. Use OpenCodex 2.8.0.
2. Upgrade to @bitkyc08/opencodex 2.10.0.
3. In Codex App, select deepseek/deepseek-v4-flash.
4. Ask the agent to perform an action requiring an MCP or tool call, such as inspecting a local file or running a harmless command.
5. Observe a successful initial Responses request, followed by a tool call without a returned function_call_output or follow-up request; the turn remains in progress.

Actual response or error

No HTTP error is surfaced to Codex App.

Redacted local OpenCodex usage records for the retries show:
- status: 200
- errorCode: none
- upstreamError: none
- first output: approximately 1.1-1.7 seconds
- total duration: approximately 7-13 seconds

The failure occurs after the initial model response, during tool-result forwarding or continuation.

Upstream documentation

https://api-docs.deepseek.com/guides/responses_api/

Suggested mapping or implementation notes

The initial model routing appears correct: deepseek-v4-flash -> openai-responses, with the DeepSeek upstream path /responses.

Please inspect the Responses event handoff and reasoning-history replay after tool calls, ensuring that tool results are preserved as function_call_output and that the continuation request is issued.

Additional context and attachments

This is a fresh reproduction after upgrading from OpenCodex 2.8.0 to 2.10.0.

Related: #875, which is closed but describes the same Responses tool-call continuation failure.

No secrets or credentials are included.

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]

_{Automated translation bookkeeping — detected language: unknown.}

[Ingwannu]

Thanks for the fresh report. This is the same residual failure tracked in #875: a successful initial DeepSeek Responses request followed by no function_call_output continuation request and a Codex App turn that remains pending. New reproduction evidence was added to #875 after it had already been closed, so I have reopened #875 and will keep the investigation history there.

PR #940 is related, but its current opt-in SSE repair does not yet cover the built-in DeepSeek preset or the Codex App WebSocket JSON path. Closing this report as a duplicate of #875 so the two tracks do not diverge.