Broken Workflow

[andrew-sz]

What version of Kimi Code CLI is running?

0.11.0

Which open platform/subscription were you using?

Kimi Code

Which model were you using?

2.6

What platform is your computer?

MacOS

What issue are you seeing?

Regression: API key authentication silently removed from "Kimi For Coding" tier in recent CLI upgrade

CLI Version: (your version, e.g. 1.x — run kimi --version)
OS: macOS Sequoia
Previous working version: (the version before upgrade, e.g. 0.41 or earlier)

---

What I had before the upgrade

A working kimi-cli workflow using the Kimi For Coding tier with an API key generated from the Kimi Code console. Setup was:

1. kimi /setup
2. Select "Kimi For Coding"
3. Paste API key
4. Use CLI with subscription credits

This worked. It was my daily workflow.

---

What broke after the upgrade

After upgrading kimi-cli, the /setup flow for "Kimi For Coding" no longer accepts an API key. It forces OAuth/browser login instead. There is no upgrade path, no deprecation notice, and no documented migration.

• My existing API key (still valid, still showing in the Kimi Code console) is now ignored by the CLI
• The CLI setup flow offers no input field for the key when "Kimi For Coding" is selected
• I cannot authenticate my existing, paid workflow without switching to OAuth

---

The incoherent part

The Kimi Code console still lets me generate new API keys. I can create a fresh key right now. But the CLI setup flow for the same tier refuses to accept it. This is broken UX: either the keys should work, or the console should not let me create them.

---

Why this matters

• Broken workflow: I had a working, automated setup. A routine upgrade destroyed it.
• No migration path: There was no warning, no --migrate flag, no "your API key will stop working" notice in the release notes.
• OAuth is not a replacement: OAuth requires browser interaction. API keys work in headless environments, CI, containers, and shared dev machines. Forcing OAuth breaks all of these.
• Wasted credentials: Keys generated in the console that cannot be used anywhere are confusing and misleading.

---

Expected behavior

Option A (preferred): Restore API key input for the "Kimi For Coding" tier in /setup, as it existed before. OAuth can be an additional option, not a replacement.

Option B: If API keys are intentionally deprecated for this tier, then:

1. The Kimi Code console should stop generating API keys for tiers where they are unsupported
2. The CLI should print a clear deprecation/migration message when an old key is detected
3. There should be a documented upgrade path from key-based auth to OAuth

---

Current workaround

None that preserves the original workflow. I am forced to either:

• Use OAuth and lose headless/automated capability, or
• Switch to the "Moonshot AI Open Platform" provider and use the OpenAI-compatible endpoint directly, bypassing the Kimi Code CLI integration entirely

Neither is acceptable as a "fix" for a regression introduced by your own upgrade.

---

References

• Feature Request: Authenticate CLI using Kimi.com subscription (like Claude Code) without requiring API keys #757 — Feature request for OAuth (which was implemented, but apparently at the expense of existing API key support)
• setup succeed but api error for each request/ #87, Cannot connect to host api.kimi.com:443 ssl:True #53, File selection with @ doesn't respect .gitignore entries #730 — Previous authentication issues with "Kimi For Coding" tier

What steps can reproduce the bug?

Run upgrade on a MacOS computer that was using API Key.

What is the expected behavior?

No response

Additional information

No response