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.
Symptom
Section titled “Symptom”Invalid JSON data: Failed to deserialize the JSON body into the target type: messages[1]: missing field `content` at line 1 column 34911Codex 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.
Upgrade CC Switch from 3.19.1 to v3.20.4, which includes the #7454 fix.
Re-enable the local proxy with apiFormat=openai_chat, then send a message in Codex Desktop to verify title generation and regular chat requests.
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.
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.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 1 real issues
- 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.
Related problems
Section titled “Related problems”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.