Conversation
Keep rotating CLI credentials read-only and point users to CLI renewal or the Kimi Code API key setting. Add synthetic expiry, web fallback, and credential replacement coverage for #4063.
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
clawsweeper
Bot
added
P3
|
Codex review: blocked before merge. Reviewed September 28, 2026, 12:55 AM ET / 04:55 UTC (Revision 3). ClawSweeper reviewWhat this changesThe PR clarifies Kimi CLI credential error messages and documentation, and adds synthetic tests for expiry, fallback, and recovery after the CLI replaces its credential. Merge readiness⛔ Blocked before merge - 3 items remain The recovery guidance is a useful, focused change that current main and v0.68.0 lack. It leaves the linked report’s request for unattended CLI credential renewal unresolved, so its closing reference needs an explicit owner decision before merge. Priority: P3 Review scores
Verification
How this fits togetherCodexBar chooses among a Kimi API key, a fresh Kimi CLI credential, and web authentication when fetching usage. If the CLI credential is stale, it can try web authentication or show a recovery error. flowchart LR
A[API key] --> D[Auto source selection]
B[CLI credential file] --> C[Freshness check]
C --> D
D --> E[Kimi usage request]
D --> F[Web fallback]
C --> G[Recovery message]
Decision needed
Why: The PR deliberately retains the stale CLI-only behavior, while the linked report asks for continuous usage after the CLI exits. Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Land the clearer recovery guidance while preserving CLI credential ownership, and keep the renewal request tracked unless the owner explicitly accepts manual renewal or an API key as its final resolution. Do we have a high-confidence way to reproduce the issue? Yes. Current source and the synthetic lifecycle cases define the stale-token cutoff and resulting error path; this read-only review did not execute them. Is this the best way to solve the issue? No for the linked renewal request: clearer wording provides a useful manual recovery path but does not keep CLI-only usage working unattended. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 579f68406855. LabelsLabel changes: No label changes. Label 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
History |
Integrate current main without rewriting the recovery fix.
clawsweeper
Bot
added
the
merge-risk: 🚨 other
This branch has not been deployed
1 participant
Kimi CLI-only sessions become stale once the access token enters CodexBar's expiry margin. The error now tells users to run
kimito renew the session or add a Kimi Code API key in Settings, and the guide explains the 14-minute cutoff for a 15-minute token.The official Kimi clients coordinate rotating refresh tokens and persist replacements. This preserves CLI-owned credentials as read-only and retains Auto mode's existing API-key priority and web fallback. Synthetic tests cover the cutoff, expired and rejected-token fallback, an unchanged credential file, and recovery after the CLI replaces its credential.
Verification on the final tree:
CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 CODEXBAR_TEST_CODEX_FILE_ISOLATION=1 CODEXBAR_TEST_SESSION_FILE_ISOLATION=1 swift test --jobs 2 --filter 'KimiSettingsReaderTests|KimiAPIFetchStrategyTests|KimiUsageResponseParsingTests|KimiUsageSnapshotConversionTests|KimiTokenResolverTests|KimiAPIErrorTests|KimiCLICredentialLifecycleTests|KimiWebFallbackTests|CredentialNotificationTests|ProviderArchitectureGatekeeperTests|ProviderSettingsDescriptorTests': 216 tests in 11 suites passed, 0 failures. Live-test and real-Keychain opt-in variables were unset.CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --package-path .build/kimi-error-proof --jobs 1 --filter KimiAPIErrorTests: isolated SwiftPM harness using the actual error source and permanent test file; pre-fix source491ae688a89afailed with 4 expected assertions, and fixed source passed 2 tests, 0 failures.CODEXBAR_CONFIG/KIMI_CODE_HOMEprobe through the signed 0.67.0 CLI reproduced the old expired-credential message. The same probe against the freshly built CLI passed the new recovery contract. Both preserved credential bytes and modification time; cookies and Keychain access were disabled, and Kimi credential environment variables were cleared.make check: 0 violations, 0 serious in 2670 files; repository checks passed.Published main was merged into this branch without rewriting the fix. Relative to main
579f68406855,git diff --shortstat 579f68406855 HEAD -- Sources WidgetExtensionis 1 file changed, 3 insertions(+), 6 deletions(-), net −3. Test changes are 3 files changed, 161 insertions(+), 22 deletions(-).Fixes #4063. Thanks @kid0114 for the detailed report.