[Bug] DeepSeek V4.1 Ark Responses tool calls leak as DSML via Codex Switch 1.5.26

[xiaoatongxue]

Summary

Codex Switch 1.5.26 does not preserve structured tool calls for a custom openaiResponses provider using Volcengine Ark DeepSeek V4.1. DSML tool-call markup is returned as assistant text, and later requests fail with Messages with role 'tool' must be a response to a preceding message with 'tool_calls'.

Environment

• Codex Switch 1.5.26, Windows
• Codex proxy: http://127.0.0.1:15722/v1/responses
• Provider: deepseek V4.1
• apiFormat: openaiResponses
• Base URL: https://ark.cn-beijing.volces.com/api/v3
• Ark endpoint: ep-20260917113440-bdxh9

Expected

response.output[].type == "function_call" should become a structured Codex tool-call event, preserving call_id, name, and arguments. DSML must not be emitted as normal assistant text, and function_call_output must reference the matching call_id.

Actual

The assistant message contains literal DeepSeek DSML tool-call markup instead of executing the tool. Proxy logs show an orphan role: tool message on the next request.

Control test

Calling the same Ark endpoint/model directly with a minimal tool-call probe returned standard reasoning,function_call events and no DSML text. This indicates the upstream model/endpoint supports structured tool calls and the failure is in the Codex Switch proxy conversion/association path.

Request

Please fix the Responses-to-Codex tool-call conversion so structured calls and their call_id associations are preserved. API keys, account tokens, and private paths have been omitted.

[piperhex]

能提供一下转发失败的日志吗

[xiaoatongxue]

Thanks @piperhex. I exported the local proxy diagnostics for the failure window.

Environment:

• Codex Switch 1.5.26, Windows
• Provider: deepseek V4.1, apiFormat=openaiResponses
• Base URL: https://ark.cn-beijing.volces.com/api/v3
• Ark endpoint: ep-20260917113440-bdxh9

The primary failing request ID is 170ea257-c720-4550-9ea2-759270ac92ea. Its sequence was:

• 14:48:47.000 (Asia/Shanghai): request received; upstream attempt started
• 14:48:47.000: first upstream result was HTTP 400 after 774 ms
• 14:48:55.000: second upstream result was HTTP 200 after 8,613 ms
• 14:48:59.000: response stream finished; 124,405 bytes; terminalEventSeen=true
• Matching error-log entry at 14:48:55.759: Messages with role 'tool' must be a response to a preceding message with 'tool_calls'

The incoming request body was 247,193 bytes (35ed351997576af5), while the forwarded request body was 247,218 bytes (e31aa2dd2a47f7e5), a +25 byte transformation by the proxy. Both had 234 input items, store=false, and stream=true.

Attached:

• local-proxy-diagnostics.issue26-focused.jsonl: all events for the 30 requests routed to this provider during the failure window
• local-proxy-diagnostics.full.jsonl: complete current diagnostics log for before/after comparison
• error-logs.issue26.csv: matching application error rows
• README.md: environment, timeline, request IDs, hashes, and privacy notes

I checked the exported diagnostics for API keys, bearer tokens, JWTs, OAuth tokens, cookies, and email addresses and found none. The diagnostic log stores metadata rather than the response SSE body, so the DSML text itself is not present in these files, but the request/response lifecycle and the +25-byte forwarded-body change are captured.

A direct minimal tool probe against the same Ark endpoint/model returned standard reasoning,function_call output with no DSML. This is why I suspect the conversion/association path after the proxy request transformation rather than the upstream endpoint.

Download codex-switch-issue26-logs.zip