Request: supported Kimi Code device OAuth registration for Codewhale

What feature would you like to see?

We maintain Codewhale, an open-source coding agent for macOS, Linux, and Windows. We would like to support an honest Kimi Code device-login option alongside our existing Kimi Code API-key path.

Before implementing this or opening a code PR, could the Kimi team clarify whether the managed Kimi Code OAuth/device flow is supported for third-party coding agents?

At MoonshotAI/kimi-code@373abb02, the first-party client uses:

• POST https://auth.kimi.com/api/oauth/device_authorization
• POST https://auth.kimi.com/api/oauth/token
• the registered client ID defined in packages/oauth/src/constants.ts
• X-Msh-Platform: kimi_code_cli and device identity headers defined in packages/oauth/src/identity.ts
• the managed API at https://api.kimi.com/coding/v1

We found the client implementation but no public third-party OAuth client or platform registration table in this repository. The current Kimi Code documentation directs third-party coding agents to use a console-created API key and says integrations must retain their real identity/User-Agent:

• https://www.kimi.com/code/docs/en/
• https://www.kimi.com/code/docs/en/third-party-tools/other-coding-agents

For that reason, Codewhale will not identify itself as kimi_cli or kimi_code_cli, copy the first-party User-Agent, or otherwise impersonate an approved Kimi client to bypass the coding-agent check.

If third-party device OAuth is supported, could Moonshot provide or approve the following registration contract?

1. A distinct public/native device-flow client ID for Codewhale, or explicit confirmation that the existing public client ID is intentionally reusable by third-party agents.
2. The approved X-Msh-Platform value for Codewhale.
3. The required User-Agent/product identity. We propose Codewhale/<version>.
4. The required X-Msh-* device fields and stable device-ID rules.
5. The supported token scopes, refresh behavior, and approved managed endpoints, including models, messages/chat, and usage.
6. Any branding, telemetry, privacy, rate-limit, abuse-prevention, security-review, or release requirements.
7. Any test environment, test account, or sanitized evidence the Kimi team would like us to provide before release.

Our planned implementation uses RFC 8628 device authorization, so it does not require a redirect URI or embed a client secret in the distributed CLI. It will include protected local credential storage, refresh and logout support, user-visible cancellation and expiry handling, and redaction of tokens from logs, crash reports, transcripts, and exports.

We can provide a test build and sanitized request/response traces using Codewhale's real product identity.

If managed OAuth is intentionally first-party-only, confirmation that API-key authentication is the supported contract for third-party coding agents would also resolve this request. In that case, we will keep Kimi OAuth disabled and direct users to the Kimi Code Console API-key flow.

Additional information

• Codewhale repository: https://github.com/Hmbown/CodeWhale
• Codewhale tracking issue: https://github.com/Hmbown/CodeWhale/issues/4417
• Kimi Code source inspected: https://github.com/MoonshotAI/kimi-code/commit/373abb02f03ef817e2e1937e1cdc4423ef0cd149
• Related server-side platform report: https://github.com/MoonshotAI/kimi-code/issues/636
• Kimi Code contribution policy: https://github.com/MoonshotAI/kimi-code/blob/main/CONTRIBUTING.md

We are asking before writing upstream code because registration and platform authorization appear to be enforced by Kimi's hosted services. We would be happy to submit a focused code or documentation PR if maintainers identify a public change that should accompany registration.

This request depends on maintainer clarification rather than a repository change. Review packages/oauth/src/constants.ts and packages/oauth/src/identity.ts at the referenced commit, then compare the Kimi Code documentation for third-party tools; done means receiving an approved registration contract or confirmation that API-key authentication is the supported path.