feat(kimi): support multiple web-auth accounts with custom labels - #2937
feat(kimi): support multiple web-auth accounts with custom labels#2937jky1314 wants to merge 3 commits into
Conversation
Register tokenAccountSupport for Kimi so multiple kimi-auth cookie accounts can be added and stacked in the menu bar, mirroring the Claude/MiniMax multi-account flow. Each account can carry a custom alias via ProviderTokenAccount.label. - KimiProviderDescriptor: declare tokenAccountSupport with kimi-auth cookie header - KimiProviderImplementation: tokenAccountsVisibility + applyTokenAccountCookieSource (keeps the multi-account editor visible pre-account, forces web/manual cookie source) - KimiSettingsReader: expose KIMI_AUTH_TOKEN constant No token cost computation is added; Kimi shows subscription balance only.
|
🦞👀 Pull request received. I will update this pull request when review starts. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b22119331
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if settings.kimiUsageDataSource == .api { | ||
| settings.kimiUsageDataSource = .web |
There was a problem hiding this comment.
When Kimi is left at its default .auto source, adding or selecting an account does not change the source here. UsageStore.makeFetchContext uses that base source directly, so an existing API key or Kimi CLI credential causes the earlier API/CLI strategy to succeed for every account; the cards then show the shared API/CLI quota rather than each saved cookie's web quota. The descriptor's new selectedAccountSourceModeResolver only affects CLI commands, not app refreshes, so this method must also switch .auto to .web while token accounts are active.
Useful? React with 👍 / 👎.
Token accounts are cookie-based. When usage source is Auto, the fetch plan may resolve to API/CLI (shared quota) instead of each saved cookie's web quota. Switch any non-web source to .web while token accounts are active, matching the descriptor's web pipeline.
|
Addressed: |
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
|
Codex review: needs real behavior proof before merge. Reviewed August 14, 2026, 4:02 PM ET / 20:02 UTC. ClawSweeper reviewWhat this changesThe PR adds labeled Kimi web-cookie accounts, displays each account separately, and derives web-quota refresh routing while those accounts are active. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 4 items remain The prior source-persistence blocker is fixed in the latest branch commit, but this new Kimi authentication/storage feature still needs maintainer sign-off and real multi-account runtime proof before merge. Priority: P2 Review scores
Verification
How this fits togetherCodexBar’s provider layer turns stored provider credentials and source preferences into refresh contexts, then renders usage cards in the menu bar. This change adds Kimi to the shared token-account path so each saved Kimi cookie can fetch an account-specific web quota. flowchart LR
A[Saved Kimi accounts] --> B[Settings snapshot]
C[Configured Kimi source] --> D[Source routing]
B --> D
D --> E[Kimi web quota fetch]
E --> F[Account usage cards]
F --> G[Menu bar display]
Decision needed
Why: VISION.md requires sign-off for new features and behavior affecting provider authentication or data storage; tests alone cannot make that product and privacy decision. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: If approved, land the shared-pattern Kimi account integration with redacted evidence that two real cookies produce distinct labeled usage cards and that removing the final account restores the configured usage route. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction: this PR proposes a new capability. Its supplied evidence covers source-routing tests, but not a real two-account Kimi run. Is this the best way to solve the issue? Unclear: the implementation follows the established token-account architecture and fixes the earlier routing concern, but maintainer approval and live proof are still required for this authentication feature. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 726604057412. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
…urce Address Codex review P1: adding/removing a Kimi token account no longer overwrites the persisted usage source. - sourceMode returns .web while any saved Kimi token account exists (derived at fetch time), and falls back to the user's configured source once the final account is removed. - applyTokenAccountCookieSource now only forces the cookie source to manual (required for per-account cookie headers); it no longer persists kimiUsageDataSource. - New KimiTokenAccountSourceRoutingTests cover add/remove routing for auto/api/web sources and verify the persisted source is untouched. 88 Kimi tests + new routing tests pass.
|
@clawsweeper re-review — P1 addressed: web routing is now derived from active token accounts at fetch time (), never persisted; removing the final account restores the user's configured source. Regression tests added (add/remove for auto/api/web). Real behavior proof added to PR body. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
merge-risk: 🚨 auth-provider
1 participant
Summary
Enables Kimi's token-account system so users can add multiple web-auth (kimi-auth cookie) accounts and stack them in the menu bar, mirroring the existing Claude/MiniMax multi-account flow. Each account can carry a custom alias via
ProviderTokenAccount.label. Monthly plan total (subscriptionBalance) is displayed; no token-cost computation is added for Kimi.Changes
KimiProviderDescriptor: declaretokenAccountSupportwithkimi-authcookie headerKimiProviderImplementation:sourceModederives.webat fetch time while any saved token account exists — never persists an override, so removing the final account automatically falls back to the user's configured sourceapplyTokenAccountCookieSourceonly forces the cookie source to manual (per-account cookie headers); the usage source is left untouchedtokenAccountsVisibilitykeeps the multi-account editor visible before any account existsKimiSettingsReader: exposeKIMI_AUTH_TOKENenvironment constantReal behavior proof
Source-routing regression tests (fresh run):
Covers: no accounts → configured source; account added →
.webderived, persisted source untouched; final account removed → configured source restored.Full suite: 88 Kimi tests + routing tests pass (122 tests total, 0 failures); release build + adhoc signing verified.
Notes
kimi-authcookie value (JWT, ~1 year validity from the browser)