Repository navigation
Injected function_call_output without call_id bricks the whole thread (Windows + DeepSeek Responses, app-server 0.154.0-alpha.6.2) #45227
Description
Summary
On Windows with a custom provider using wire_api = "responses" (DeepSeek), inputs injected by the app server as a standalone function_call_output are sent without a call_id. The provider rejects the request with HTTP 400 and the bad item is persisted into the rollout, so the whole thread — including plain user messages — fails from then on.
Related: #41690 (Windows/DeepSeek), #43515 (macOS/Kimi), #41799 (Azure).
Error (verbatim)
Failed to deserialize the JSON body into the target type: input: missing field call_id at line 1 column 88555 (type: invalid_request_error)
Environment
- Windows 10 Pro 19045 (zh-CN)
- Codex Desktop app build 26.908.40834; embedded app-server / command-runner 0.154.0-alpha.6.2 (windows-x86_64)
- Provider
[model_providers.deepseek]: base_url https://api.deepseek.com/ , wire_api = "responses", API-key auth - Model deepseek-v4-flash, reasoning effort high
Steps to reproduce
- Sign in with a custom Responses-compatible provider and an API key.
- Open a thread and attach a heartbeat / cron automation (or use create_thread / send_message_to_thread delegation).
- When it fires, the injected standalone
function_call_outputhas id/name/namespace/output but nocall_id; the first request fails in ~1 s with HTTP 400, the item is persisted, and every later turn of that thread fails identically.
Observed failures (16 distinct turns)
2026-09-09 18:46:18Z col 274443; 20:46:20Z col 276054; 22:31:53Z col 71761; 22:46:52Z col 277225; 2026-09-10 00:47-04:49Z x6 cols 278396 / 279567 / 286213 / 287897 / 288090 / 292214; 10:28:07Z col 292359; 2026-09-13 12:31:21Z col 88555; 12:40:13Z col 89716; 12:42:58Z col 91591; 12:44:06Z col 67518. Timestamps match a 2-hour heartbeat cadence.
Impact
3 threads affected (one with a 70 MB rollout); no recovery path in the UI; the only working fix is manually editing the rollout JSONL to convert/remove the orphaned item.
Note on a wrong local diagnosis
This is not an "~88 KB request-body limit": the reported column is just the offset of the malformed item, and the same error appeared at 16 different offsets (67,518 -> 292,359).
Suggested fix
Never emit standalone function_call_output items without call_id (or convert injected inputs into message items); validate the outgoing payload and drop/repair orphaned items; surface a recoverable error instead of permanently failing the thread.
Activity
github-actions commentedon Sep 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
function_call_outputwithoutcall_id, permanently breaking the target session (400 missing field call_id) #44723Powered by Codex Action
Cekxri commentedon Sep 13, 2026
Additional data point from Windows + Agent Router (OpenAI-compatible Responses API), same app-server
0.154.0-alpha.6.2.wire_api = "responses", modeldeepseek-v4-flash.send_message_to_threadfrom thread A into thread B injects a standalonefunction_call_outputwithid/name/namespace/outputbut nocall_id, and with no matchingfunction_call. The first request fails with HTTP 400input: missing field call_id. The malformed item is persisted into thread B's rollout, so subsequent plain user messages in thread B also fail.function_call_outputwith a randomcall_idbut no matchingfunction_call-> HTTP 400:No tool call found for tool output with call_id ....function_call+ matchingfunction_call_output(same generatedcall_id, namesend_message_to_thread, namespacecodex_app) -> HTTP 200 withresponse.created/response.in_progress/response.output.function_call_output, also emit a matchingfunction_callwith the samecall_id(or normalise the injection to a message if that is the intended semantics), validate the outgoing payload, and avoid persisting the malformed item.No API keys, private conversation content, or local paths are included.
dajiaohuang commentedon Sep 13, 2026
The cross-provider reproductions show a standalone function_call_output without a call_id, followed by a provider rejection and a persisted malformed item. Before patching, could maintainers confirm the intended app-server representation for an injected cross-thread message: a paired function_call and output, a normal message item, or another typed envelope? This affects protocol compatibility and malformed-item recovery.