Skip to content
CC Switch WikiUnofficial Community Wiki

Codex connecting to Kimi reports HTTP 400 tool schema validation failure

Quick fix

Upgrade cc-switch to v3.18.0+; if the error persists, wait for the MFJS schema cleaning feature to go live.

Symptom

Section titled “Symptom”
Error output
CC Switch local proxy failed while handling Codex endpoint /responses. Provider: Kimi For Coding; model: kimi-for-coding; upstream_status: HTTP 400; cause: tools.function.parameters.type is required and must be "object"

Cause

Section titled “Cause”

The parameter schema of Codex built-in tools (such as automation_update) is generated by Rust schemars or Zod 4, following the JSON Schema 2020-12 specification, which allows $ref to be parallel with sibling keywords like type and description, and also allows root-level use of oneOf/anyOf without type:"object". However, the Kimi/Moonshot server uses old-style validation (draft-07 semantics), requiring that $ref nodes do not allow any sibling keywords, and tools[].function.parameters.type must equal "object". cc-switch forwards tools as-is during the responses → chat completions conversion, causing Moonshot to return 400 for every request with tools.

This issue has multiple error variants: early versions (3.16.x) report tools.function.parameters.type is required; version 3.17.0 reports $ref sibling keyword violations (e.g., $defs.__schema20: when using $ref, type should be defined...); some scenarios also report dangling required references or anyOf.properties.type undefined. v3.18.0 has fixed the missing type issue (by adding root-level type:object), but $ref sibling keyword cleaning and dangling required reference pruning have not yet been implemented in the release version, and still occur in v3.20.0.

Fix

Section titled “Fix”

  1. Upgrade cc-switch to v3.18.0 or higher. v3.18.0 has fixed the 400 error caused by missing tools.function.parameters.type, and will normalize tool parameters to the object type.

  2. If the error persists after upgrading (e.g., $ref sibling keywords or dangling required references), this is a known unfixed issue. Temporary workaround: set up a local cleaning proxy (e.g., a Python script) between the cc-switch local proxy and Moonshot, to recursively traverse tools[].function.parameters, merge type/description at the same level as $ref into the $defs reference target, prune entries in required that do not exist in properties, and wrap root-level oneOf/anyOf as type:object.

Affected Versions

Section titled “Affected Versions”
ToolCodex
Version3.16.3 - 3.20.0（3.18.0 修复 type 缺失，$ref 清洗未修复）
PlatformsmacOSWindows

Source Issues

Section titled “Source Issues”

This page is distilled from 7 real issues

FAQ

Section titled “FAQ”
Why do new sessions work fine, but specific sessions consistently report 400?
Codex Desktop supports tool_search to dynamically load tools, and tool_search_output remains permanently in the input of subsequent requests as a history item. If the history contains tool definitions incompatible with the Moonshot schema, every subsequent request in that session will fail.
Why do I still get an error after upgrading to the latest version?
v3.18.0 only fixed the issue of missing tools.function.parameters.type. If the error message involves $ref sibling keywords (e.g., $defs.__schema20: when using $ref, type should be defined...) or dangling required references, this is a known issue not yet fixed in the release version, and you need to wait for the MFJS schema cleaning feature to go live.
Is there a temporary workaround?
You can set up a local cleaning proxy (about 100 lines of Python script) between the cc-switch local proxy and Moonshot to recursively clean the tool schema: merge $ref sibling keywords into the reference target, prune dangling required references, and wrap root-level oneOf/anyOf as type:object. This has been verified by users on macOS and Windows.
Will Codex CLI also trigger this issue?
Codex CLI's own 17 built-in tools do not trigger this issue (their schemas have no $defs). The issue is mainly caused by dynamic tools like automation_update injected by Codex App (Desktop), whose schemas are generated by Zod 4 or Rust schemars and contain a large number of $defs and $ref sibling keywords.
Will domestic providers like Volcano Engine/Bailian encounter similar issues?
In early versions, providers like Volcano AgentPlan would forcibly override apiFormat to openai_chat due to preset hardcoding and local routing map switches, making it impossible to use the native Responses API. v3.16.4 has decoupled this issue, making the upstream format selector independently visible. However, if the provider also uses strict schema validation, similar 400 issues like Moonshot may exist.
Section titled “Related problems”
kimi k2 reports 404 - CC SwitchA 404 from the connection test does not mean Kimi is unavailable. Set ANTHROPIC_BASE_URL to https://api.kimi.com/coding/ and verify by running Claude Code.4 issues mergedAuth conflictLog out of the official Claude login, clear conflicting ANTHROPIC_* variables, set hasCompletedOnboarding to true in ~/.claude.json, and restart the terminal.6 issues mergedRange of input length should be [1, 1048576]Upgrade CC Switch to v3.19.0 for the fix where images were forwarded as base64 text and inflated tokens, or avoid view_image under the proxy.3 issues merged

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.