Feature: one-command secure remote access with QR pairing

What feature would you like to see?

I would like a supported, one-command way to leave Kimi Code running on my Mac and securely use it from my phone, including when the Mac and phone are on different networks.

A possible user experience would be:

$ kimi remote

Remote session ready.
Scan this QR code with your phone:
<QR code>

Manage or stop it with:
  kimi remote status
  kimi remote stop

The phone would open Kimi Web (or a future installable/PWA client), while execution, repositories, tools, and local credentials remain on the Mac.

Expected behavior

• Start or reuse the local Kimi server.
• Establish remote reachability without router port forwarding or a publicly exposed unauthenticated listener.
• Display a QR code backed by a short-lived, preferably one-time pairing credential.
• Use an authenticated and encrypted connection.
• Support credential expiration, device/session revocation, status, and shutdown.
• Keep sensitive capabilities such as remote terminals and server shutdown disabled by default unless explicitly enabled.
• Reconnect cleanly when the phone changes between Wi-Fi and cellular networks.

The exact CLI shape is open for discussion; kimi remote, kimi --remote, or another command would all satisfy the underlying need.

Current behavior and gap

Kimi Code already has a responsive web client, bearer-token authentication, and kimi web --host / kimi server run --host for binding to a LAN or VPN interface. That works when the user separately provides network reachability.

What is missing is the Codex-like one-command experience:

• no built-in outbound tunnel or relay for different networks;
• no device-pairing flow;
• no QR-code handoff;
• no single command for starting, inspecting, revoking, and stopping remote access.

A QR code containing a LAN URL alone would not solve the different-network case, so this request includes the secure transport/pairing layer rather than only QR rendering.

Related issues

• #900 and #908 cover LAN/VPN binding through --host.
• #1416 requests PWA/mobile installation and presentation.
• #1484 covers mobile notification settings.

Those are useful foundations or complementary improvements, but they do not provide cross-network transport and QR/device pairing.

Questions for maintainers

Before implementation, it would be helpful to align on the intended architecture:

1. Is a supported remote-access workflow within the Kimi Code roadmap?
2. Would Moonshot consider operating a relay, or should the implementation use a pluggable/self-hosted tunnel?
3. Would an acceptable first version manage pairing/QR UX around a user-provided VPN or tunnel URL, with transport integration added separately?
4. Should pairing create a distinct, scoped device credential rather than exposing the server's long-lived bearer token?

I would be interested in contributing after the desired scope and security model are agreed upon.

Additional information

This request is not for cloud execution or migrating the session to the phone. The Mac remains the execution host; the phone is a secure remote client.

I searched existing open and closed issues and pull requests for remote access, mobile access, QR pairing, tunnels, relays, NAT traversal, Tailscale, PWA, and kimi web before opening this request. I found the related items above, but no issue covering this complete workflow.

Start by reviewing the existing kimi web --host and kimi server run --host workflows, bearer-token authentication, and the responsive web client. The related issues #900, #908, and #1416 provide context. This issue is complete only after maintainers agree on the transport, pairing, credential, revocation, and CLI scope.