kimi-code (managed OAuth) rejected with 403 access_terminated while kimi-cli works — X-Msh-Platform: kimi_code_cli not on server allowlist

Summary

With the same Kimi Code (Coding plan) OAuth account, the new kimi (kimi-code, v0.14.0, Node) consistently fails on every prompt, while the legacy kimi-cli (v1.47.0, Python) works against the same kimi-for-coding model. This is reproducible right now (2026-06-10), not the transient 2026-06-04 outage from #413/#414/#416/#418.

What the user sees in kimi-code

Error: [provider.rate_limit] 429 The engine is currently overloaded, please try again later

This 429 message is misleading. The real upstream status is 403 access_terminated.

Root cause (verified)

The coding API gates kimi-for-coding access by the X-Msh-Platform request header. Tested with the same valid OAuth access token via curl:

{"error":{"message":"Kimi For Coding is currently only available for Coding Agents such as Kimi CLI, Claude Code, Roo Code, Kilo Code, etc.","type":"access_terminated_error"}}

kimi-code hardcodes const KIMI_CODE_PLATFORM = "kimi_code_cli" and sends it as X-Msh-Platform. The server allowlist appears to accept kimi_cli but not kimi_code_cli, so the official new client is rejected.

Two bugs

1. Server-side: the allowlist for kimi-for-coding does not include kimi-code's own platform id (kimi_code_cli).
2. Client-side: kimi-code surfaces the upstream 403 access_terminated as a misleading 429 "engine overloaded", which sends users down the wrong path (quota/retry).

Workaround attempted (does not work)

Adding [providers."managed:kimi-code".custom_headers] with X-Msh-Platform = "kimi_cli" has no effect, because the managed provider regenerates identity headers at request time (createKimiRequestHeaders -> hardcoded KIMI_CODE_PLATFORM), so config cannot override it.

Environment

• kimi-code 0.14.0 (Node v24, macOS x64)
• kimi-cli 1.47.0 (works, same account/model)
• Endpoint: https://api.kimi.com/coding/v1/chat/completions
• Auth: Kimi Code OAuth (Coding plan)

Start with createKimiRequestHeaders and the hardcoded KIMI_CODE_PLATFORM value described in the report, then reproduce the curl comparison against the coding endpoint. Determine how the upstream 403 access_terminated response becomes the displayed 429 error. Done requires the client-side error behavior to be accurate and the server allowlist issue to be confirmed with the API owner.