Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

bug(desktop): MCP OAuth authorization URL is not surfaced before callback timeout

オープン
  • 何か問題がありますか？
#3,950 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
65/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
desktop

調査の方向性

Start by tracing the Desktop UI's handling of live tool updates from the MCP authentication flow, which can be invoked through /mcp-config; the report says the tool emits an authorization-URL update before waiting for the callback. Done means Desktop surfaces the URL or opens it in the browser while the callback listener is still active, so authorization can finish before timeout.

索引モデルが issue の本文から書いたものです。

説明

What version of Kimi Code is running?

Desktop app 1.0.2 (Windows x64, packaged), embedded server host_version 2.0.1.

Which model were you using?

K2.8 Preview.

What platform is your computer?

Windows 11 x64.

What issue are you seeing?

For a project-level remote HTTP MCP server that requires OAuth, Kimi Code Desktop exposes the generated mcp__<server>__authenticate tool, but invoking the login flow does not surface the fresh authorization URL to the user while the callback listener is still active.

Observed behavior:

  • mcp__cloudflare-api__authenticate starts and the UI remains at Waiting for output....
  • No browser window is opened.
  • No authorization URL is shown while the flow is live.
  • After the OAuth callback wait times out, the tool finally returns an error that includes the authorization URL.
  • Opening that URL at that point reaches the provider's authorization page, but the redirect back to 127.0.0.1:<port>/callback fails because the local callback listener has already timed out and closed.

This was reproduced twice with different callback ports.

The remote MCP server itself and the OAuth provider are working. The same OAuth flow completes successfully through the documented local MCP management API when the authorization URL is retrieved immediately and opened while the callback listener is live.

What steps can reproduce the bug?

  1. On Windows 11, configure a project-level remote HTTP MCP server in:

    <workspace>\.kimi-code\mcp.json

  2. Trust the workspace so the project MCP server is loaded.

  3. Start a fresh Kimi Code Desktop session.

  4. Confirm that the server requires OAuth and that the generated authentication tool is visible, for example:

    mcp__example-api__authenticate

  5. Invoke the MCP login flow (for example through /mcp-config).

  6. Observe that Desktop remains on:

    Waiting for output...

    without opening a browser and without showing the fresh authorization URL.

  7. Wait for the callback timeout.

  8. Observe that only after timeout does the tool output include an authorization URL.

  9. Open that returned URL and authorize promptly.

  10. Observe that the final redirect to the local callback endpoint fails because the listener has already closed.

What is the expected behavior?

As soon as the MCP OAuth flow creates the authorization URL and local callback listener, Desktop should surface the authorization URL immediately (or open it in the user's browser), while the listener is active.

The user must be able to complete authorization before the callback timeout.

The tool implementation already emits an authorization-url update before waiting for the callback, so Desktop should render that live update rather than exposing the URL only after the tool finishes with a timeout.

Verified workaround

The underlying server-side OAuth flow works through the documented MCP management API:

  1. Begin the flow:

    POST /api/v2/mcp/auth:begin?cwd=<workspace>
Content-Type: application/json

{
  "source": "global",
  "name": "example-api"
}

  2. Read the returned authorizationUrl immediately and open it in the browser while the callback listener is active.

  3. Complete the provider authorization.

  4. Wait for completion:

    POST /api/v2/mcp/auth:complete
Content-Type: application/json

{
  "flowId": "<flow-id>",
  "timeoutMs": 900000
}

  5. The completion returns code: 0, and an offline auth-status check reports:

    oauth-authorized

This confirms that OAuth, PKCE, local callback handling, and credential persistence all work when the authorization URL is surfaced in time. The failure appears specific to the Desktop UI/live tool-update path.

Additional information

I searched existing issues before filing and did not find a duplicate for this Desktop-specific symptom.

This is separate from #3949, which concerns the missing Workspace Trust prompt for project MCP configuration.

No OAuth URLs, callback state values, credentials, tokens, account identifiers, local usernames, production domains, or request IDs are included in this report.

主要言語
TypeScript
スター
7.7k
フォーク
1.3k
平均マージ
12時間 35分
マージ済み PR（30日）
311

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MoonshotAI/kimi-code のほかの issue

MoonshotAI/kimi-code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。