Skip to content

fix(mcp): expose Kimi OAuth authorization while waiting - #1133

Open
Cuinnchen wants to merge 1 commit into
spacering-net:mainfrom
Cuinnchen:fix/kimi-mcp-oauth-entry
Open

Cuinnchen wants to merge 1 commit into
spacering-net:mainfrom
Cuinnchen:fix/kimi-mcp-oauth-entry

Conversation

@Cuinnchen

Copy link
Copy Markdown

Kimi MCP OAuth waits currently have no usable authorization entry while the tool is running. Kimi 2.5.3's toolProgressToSessionUpdate only forwards status text as a title-only ACP update; its custom mcp.oauth.authorization_url event is not delivered. The status retitles the tool card, and the synthetic authenticate tool's empty {} arguments also cause the adapter to prune the waiting row.

This change binds progress to the opening Kimi mcp__<server>__authenticate call, retains that tool identity and shows its forwarded authorization status below the MCP row. The user can open the complete HTTPS URL explicitly in the system browser. It supports the Rust bridge's inprogress spelling and Kimi's original versus sanitized server labels. Kimi continues to own its native ~/.kimi-code/mcp.json, OAuth callback and reconnection; no configuration isolation or upstream custom event reception is assumed.

Safety and lifecycle

  • Parse only Kimi's exact, title-only OAuth status template within the bound authenticate call. Never search tool input/results, assistant text or webpages for links; never auto-open anything.
  • Validate HTTPS without embedded credentials or whitespace/control characters, then retain the original URL bytes, including state, PKCE and dynamic loopback callback port. No new URL/error-parameter logging.
  • Treat codeg.kimiMcpOAuth as frontend-derived state. Strip it from incoming live events and snapshots; missing opening context fails closed. Parallel calls cannot borrow each other's authorization URL.
  • Retire the URL on reconnect, terminal tool status or subsequent status changes; hide the notice when the turn ends. Opening the browser or receiving “Authorized — reconnecting” does not confirm usable authorization. The notice asks the user to verify access with a real MCP tool after reconnecting.
  • Use the existing browser/platform opener on an explicit click, with a generic failure message and retry. Keep translations aligned across all ten locales.

Validation

Node 24.22.2, pnpm 11.9.0, based on current upstream main (1bc86a301a7c46b3c88ef94402be285b2fbf38ec).

  • pnpm test --maxWorkers=4 — 769 files / 11,435 tests passed, exit 0.
  • pnpm test src/lib/kimi-mcp-oauth.test.ts src/lib/snapshot-denormalize.test.ts src/components/message/activity/activity-rows.test.tsx src/contexts/acp-connections-context.test.tsx src/lib/adapters/ai-elements-adapter.test.ts src/i18n/messages.test.ts --maxWorkers=2 — 491 tests passed.
  • pnpm exec tsc --noEmit — passed, exit 0, including test sources.
  • pnpm lint . — passed, exit 0.
  • pnpm build — passed, exit 0; production compilation, TypeScript check and static export completed.
  • git diff --cached --check — passed; staged/untracked review contains only the 20 intended source/locale/test files.

The successful full suite emits jsdom navigation/canvas not-implemented stderr in existing tests. Node 26's unrelated localStorage incompatibility was reproduced and avoided by using CI's Node 24. Next's sandbox IPC stall was avoided by running the identical production build outside the sandbox. No unrelated product workaround is included.

The event regression and missing UI entry were observed failing before the fix. Additional regressions caught and verified fixes for the Rust status spelling, snapshot/late-event provenance, and Kimi server-label normalization. Interaction coverage runs the real provider → live runtime → adapter path, renders the real MCP activity row, clicks its link, and checks exact URL dispatch, no automatic opening, reconnect removal, native opener failure/retry, and cancellation/terminal cleanup. Only the OS/window opener boundary is stubbed. Independent review found no remaining Critical/Important issue.

Boundaries

No real Notion/Kimi account OAuth, actual system-browser launch, callback, or usable tools after real reconnection was exercised. Those remain NOT_RUN; no OAuth was initiated and no credentials were inspected. The separate connected Notion MCP document task is not evidence for this patched account flow.

The entry is intentionally unavailable when a refreshed/late client missed the original authenticate identity. Kimi's >64-character hashed/truncated qualified tool names also remain unsupported and fail closed, rather than treating arbitrary MCP calls as OAuth. No Rust source, unrelated failure, dependency, lockfile, build artifact or log is changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant