[Bug]: Cannot sign into Kimi#24302

opened18d agobyRRickatRITE

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Add Kimi as a provider (new install)
  2. Proceed to the sign in step
  3. It hangs at "Starting sign-in…"

Replicated on two Windows and two Omarchy Linux boxes

Expected behavior

Sign in should proceed to that step

Actual behavior

Hangs at "Starting sign-in…"

Impact

Blocks work completely

Version or commit

0.1.3-nightly.20261023.3579

Environment

Windows 11, Omarchy Linux

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

Tried logging into CLI manually (worked), did not change the outcome.

Synced from GitHub

Reproduced on macOS with T3 Code Beta 0.1.5 and the registry-managed Kimi CLI 1.52.0 (aarch64-apple-darwin). Sign-in stalls without opening a browser.

The Kimi log shows two attempts on 2026-10-30 at 13:16 and 13:17 local time. Both connect successfully as ACP client t3-code-provider-auth, then fail:

text
1kimi_cli.acp.server:authenticate:385
2Authentication not complete for method: login (no valid token found)
3
4kimi_cli/acp/server.py:390, in authenticate
5acp.exceptions.RequestError: Authentication required
6
7During handling of the above exception:
8acp/connection.py:219, in _run_request
9acp/task/sender.py:33, in send
10json/__init__.py:242, in dumps
11TypeError: Object of type AuthMethod is not JSON serializable
12when serializing list item 0
13when serializing dict item authMethods
14when serializing dict item data
15when serializing dict item error

This indicates that Kimi fails while serializing its authentication-required error response. That would explain the pending ACP request / stalled sign-in UI, although it does not establish why browser login was never initiated. T3 server traces also show an ACP authenticate request interrupted when the attempt was replaced.

Potentially related: #15899 identifies the registry-managed 1.52.0 runtime as the archived Kimi CLI. These observations do not yet establish whether upgrading the runtime resolves the issue.

Diagnostics collected with Codex (gpt-6.1-sol) in T3 Code.

Synced from GitHub

Still reproduces on T3 Code desktop 0.1.6, macOS 26.5 (arm64), with the registry-managed Kimi CLI 1.52.0. Retry sign-in stays on "Starting sign-in…" and then shows "Not authenticated". ~/.kimi/logs/kimi.log has the same trace already posted here: authenticate:385 … no valid token found, then RequestError: Authentication required, then TypeError: Object of type AuthMethod is not JSON serializable (when serializing error.data.authMethods). Root cause and the _meta["terminal-auth"] analysis are in #28833; the fix is #24409 (still open).

Workaround on macOS: set Executable override to ~/.kimi-code/bin/kimi (Kimi Code CLI 2.4.1). If ~/.kimi-code/credentials/kimi-code.json already exists, the provider check goes to ready and loads 256 models with no re-login. Its auth status shows unknown rather than authenticated.

Triage by Claude Opus 5.5 (Claude Code) via t3 triage.

Synced from GitHub

Same on Windows 11, T3 Code 0.1.6 (t3 serve), registry-managed Kimi CLI 1.52.0. Login does nothing.

Workaround from @AskAlice's comment works on Windows too. I already had Kimi Code CLI 2.4.1 installed and logged in (~/.kimi-code/bin/kimi.exe), so I pointed the provider at it with Executable override in Settings → Providers → Kimi CLI.

If you run headless and want to set it in the file, it's commandPath in ~/.t3/userdata/settings.json:

1"acpRegistry_kimi_cli": {
2 "driver": "acpRegistry",
3 "config": {
4 "agentId": "kimi",
5 "distribution": "auto",
6 "commandPath": "C:\\Users\\<user>\\.kimi-code\\bin\\kimi.exe"
7 }
8}

Restart the server after editing. No re-login needed. My credentials file is named kimi-code-env-<hash>.json rather than kimi-code.json, and it still worked.