Skip to content

messages[1]: missing field `content` (HTTP 400) — Codex

Quick fix

Upgrade CC Switch to v3.20.4; the converter skips additional_tools carriers without content, preventing strict upstream services from returning 400.

Error output
Invalid JSON data: Failed to deserialize the JSON body into the target type: messages[1]: missing field `content` at line 1 column 34911

Codex Desktop title generation and regular chat requests place an additional_tools carrier with a role but no content at the beginning of input. The Responses→Chat conversion in CC Switch 3.19.1 turns it into {"role":"system","content":null}, causing strict upstream services such as Agnes, which require content to be a string, to return HTTP 400.

v3.20.4 skips this carrier and merges its tools into the top-level tools. The user confirmed that upgrading restored normal operation. However, assistant messages with tool_calls still output "content":null. OpenAI Chat permits this format, but some strict gateways may still reject it.

  1. Upgrade CC Switch from 3.19.1 to v3.20.4, which includes the #7454 fix.

  2. Re-enable the local proxy with apiFormat=openai_chat, then send a message in Codex Desktop to verify title generation and regular chat requests.

  3. Run another conversation that invokes a tool. If it still returns 400 after the tool call, retain the outbound request body and error to confirm whether content:null in an assistant tool_calls message is the cause.

  4. If upgrading is not currently possible, rewrite missing or null content values in messages to "" in the local reverse proxy. Remove this workaround after upgrading and verifying the fix.

ToolCodex
Version3.19.1 受影响;v3.20.4 修复 additional_tools 导致的空 system 消息
PlatformsWindows
After upgrading to v3.20.4, do title generation and regular chats on Agnes work normally?
Yes. The reporter confirmed normal operation after upgrading.
Does v3.20.4 also replace content:null with an empty string in assistant messages containing tool_calls?
No. This version only fixes the conversion of the additional_tools carrier into an empty system message; assistant tool_calls messages may still contain "content":null.
What information should be provided if 400 is still returned after a tool call?
Provide the converted outbound request body and the upstream error to determine whether the strict upstream service rejects content:null in an assistant tool_calls message.

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.