codex_app__automation_update parameters schema rejected by Kimi/Moonshot (HTTP 400, $ref sibling of type) — same failure class as #39848

Summary

Codex Desktop fails on every request before the model responds when using Kimi For Coding (k3) as the provider through CC Switch local routing. Moonshot's strict JSON Schema validator rejects the bundled codex_app__automation_update tool schema with HTTP 400.

Environment

• Product: Codex Desktop (bundled inside ChatGPT.app), macOS
• Codex app build: 26.820.60940; Codex CLI: 0.131.0
• Provider: Kimi For Coding, https://api.kimi.com/coding/v1, model k3
• Path: Codex → CC Switch local proxy (127.0.0.1:15721, Responses → Chat Completions) → Moonshot

Error

CC Switch local proxy failed while handling Codex endpoint /responses.
Provider: Kimi For Coding; model: k3; upstream_status: HTTP 400;
cause: tools.function.parameters is not a valid moonshot flavored json schema,
details: <At path '$defs.__schema20': when using $ref, type should be defined in the referenced schema instead of the parent schema>

Root cause

The codex_app__automation_update tool (from the codex_app MCP namespace, always eager-loaded) is emitted with a parameters schema that violates Moonshot's validator in two ways:

1. top-level $defs + oneOf with no type: "object", and
2. $ref used as a sibling of type — the validator requires type to be defined inside the referenced schema, not at the referencing node (the error points at $defs.__schema20).

This is the same failure class already tracked in #30132 (Azure), #36441 (DeepSeek via CC Switch), #37786 (DeepSeek), #39848 — now reproduced on Moonshot/Kimi. OpenAI's own Responses backend tolerates the schema, so official models are unaffected; only strict OpenAI-compatible providers break.

Local workaround (validated)

Because the tool is always eager-loaded and cannot be disabled from settings, I run a small local normalization proxy between Codex and CC Switch that rewrites the tools schema before forwarding:

• injects top-level type: "object" when missing,
• moves type out of $ref siblings into the referenced schema (following the chain),
• rewrites relative $refs to #/$defs/.

After normalization Moonshot accepts the request (HTTP 200). Same approach as cc-switch#5447 and the suggested fix in #37786.

Request

Please normalize the emitted automation_update schema — top-level type: "object" and no $ref/type siblings — so strict OpenAI-compatible providers (Moonshot/Kimi, DeepSeek, Azure) stop rejecting every request. This is now the 5th report of this failure class; a fix would unblock all of them.

Start at the emitted codex_app__automation_update schema and the Codex /responses path described in the report, then trace where MCP tool schemas are normalized before provider requests. Verify the result against strict OpenAI-compatible providers or the reported Moonshot case; done means a top-level object type is present and no $ref has a sibling type.