kimi rc exits silently (code 0) after "server ready" — no pairing URL/QR (2 machines: Win 11 + macOS, v2.0.0, global account)

[bricenopcesar-cloud]

What version of Kimi Code is running?

2.0.0

Which open platform/subscription were you using?

Kimi Code (kimi.ai/code) — global account, plan Max

Which model were you using?

K3 (k3[1m])

What platform is your computer?

Windows 11 (x64) — also reproduced on macOS (same account, same result)

What issue are you seeing?

Summary

The Remote Control feature never reaches the pairing step on two independent machines. The local server starts correctly and prints "server ready", then the process terminates cleanly (exit code 0) ~1 second later — no pairing URL, no QR code, no error message. The failure occurs in the phase after the local HTTP server is up, presumably during registration with the remote relay. Because the exit is silent and clean, there is no diagnostic output to identify the failing step.

Steps to Reproduce

1. Log in with a global account via OAuth (kimi.ai/code), plan Max.
2. Run any of the following (all reproduce identically):
   • kimi rc --log-level debug
   • /rc from an interactive session
   • kimi web --remote-control
3. Observe output and exit code.

Environments

Env	OS	Kimi Code version	Account	Plan
A	Windows 11	0.43.1 → upgraded to 2.0.0	Global (OAuth via kimi.ai/code)	Max
B	macOS	2.0.0 (clean install)	Same global account	Max

Logs

With --log-level debug:

Server listening 127.0.0.1:58627
server ready

Then the process exits ~1s later with exit code 0. Nothing further is printed — no URL, no QR, no error, no stack trace.

Expected vs. Actual

Expected: After "server ready", the CLI prints the pairing URL/QR code for connecting the remote control session.

Actual: The process terminates silently with exit code 0.

Diagnostics Already Ruled Out

• Relay reachability: code-rc.kimi.com responds HTTP 200 from both machines.
• Auth: OAuth token is valid (managed:kimi-code); same account works for other features.
• Single instance: No prior kimi process holding the RC lock (verified on both machines).
• Local server itself: kimi web alone (without remote control) stays listening correctly — the local server is not the failure point. The process dies only when the remote-control registration phase follows "server ready".

Notes

• The exit code 0 on failure is the core problem: a silent clean exit gives no foothold for diagnosis. Even at --log-level debug, the registration step with the remote relay produces no log output.
• Suggestion: log each step of the remote registration phase (connection, handshake, auth against relay, pairing-code generation) and print an explicit error (with non-zero exit) when registration fails, instead of exiting cleanly.
• Timing is consistent (~1 s after "server ready"), suggesting the failure happens during the first relay round-trip — e.g., relay rejecting the registration for this account/type, or an unhandled error swallowed by the RC command.

Happy to provide packet captures, --log-level trace output if available, or test a debug build on either machine.

What steps can reproduce the bug?

Summary

The Remote Control feature never reaches the pairing step on two independent machines. The local server starts correctly and prints "server ready", then the process terminates cleanly (exit code 0) ~1 second later — no pairing URL, no QR code, no error message. The failure occurs in the phase after the local HTTP server is up, presumably during registration with the remote relay. Because the exit is silent and clean, there is no diagnostic output to identify the failing step.

Steps to Reproduce

1. Log in with a global account via OAuth (kimi.ai/code), plan Max.
2. Run any of the following (all reproduce identically):
   • kimi rc --log-level debug
   • /rc from an interactive session
   • kimi web --remote-control
3. Observe output and exit code.

Environments

Env	OS	Kimi Code version	Account	Plan
A	Windows 11	0.43.1 → upgraded to 2.0.0	Global (OAuth via kimi.ai/code)	Max
B	macOS	2.0.0 (clean install)	Same global account	Max

Logs

With --log-level debug:

Server listening 127.0.0.1:58627
server ready

Then the process exits ~1s later with exit code 0. Nothing further is printed — no URL, no QR, no error, no stack trace.

Expected vs. Actual

Expected: After "server ready", the CLI prints the pairing URL/QR code for connecting the remote control session.

Actual: The process terminates silently with exit code 0.

Diagnostics Already Ruled Out

• Relay reachability: code-rc.kimi.com responds HTTP 200 from both machines.
• Auth: OAuth token is valid (managed:kimi-code); same account works for other features.
• Single instance: No prior kimi process holding the RC lock (verified on both machines).
• Local server itself: kimi web alone (without remote control) stays listening correctly — the local server is not the failure point. The process dies only when the remote-control registration phase follows "server ready".

Notes

• The exit code 0 on failure is the core problem: a silent clean exit gives no foothold for diagnosis. Even at --log-level debug, the registration step with the remote relay produces no log output.
• Suggestion: log each step of the remote registration phase (connection, handshake, auth against relay, pairing-code generation) and print an explicit error (with non-zero exit) when registration fails, instead of exiting cleanly.
• Timing is consistent (~1 s after "server ready"), suggesting the failure happens during the first relay round-trip — e.g., relay rejecting the registration for this account/type, or an unhandled error swallowed by the RC command.

Happy to provide packet captures, --log-level trace output if available, or test a debug build on either machine.

What is the expected behavior?

No response

Additional information

No response

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)