same here
[Bug]: Cannot sign into Kimi#24302
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
- Add Kimi as a provider (new install)
- Proceed to the sign in step
- 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
| 1 |
Screenshots, recordings, or supporting files
No response
Workaround
Tried logging into CLI manually (worked), did not change the outcome.
same
same
I'm also reproducing this one!
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:
| 1 | kimi_cli.acp.server:authenticate:385 |
| 2 | Authentication not complete for method: login (no valid token found) |
| 3 | |
| 4 | kimi_cli/acp/server.py:390, in authenticate |
| 5 | acp.exceptions.RequestError: Authentication required |
| 6 | |
| 7 | During handling of the above exception: |
| 8 | acp/connection.py:219, in _run_request |
| 9 | acp/task/sender.py:33, in send |
| 10 | json/__init__.py:242, in dumps |
| 11 | TypeError: Object of type AuthMethod is not JSON serializable |
| 12 | when serializing list item 0 |
| 13 | when serializing dict item authMethods |
| 14 | when serializing dict item data |
| 15 | when 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.
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.
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.