feat: pair Kimi Code CLI with the Kimi mobile app for cross-device session access

What feature would you like to see?

Add a first-class flow to pair a running Kimi Code CLI session with the Kimi mobile app, so the user can monitor and steer an in-progress agent loop from their phone — the way Claude Code does today via the Claude iOS/Android app and a QR/short-code pairing handshake, or the way the Codex CLI ties a local session to the Codex app through the user's account.

Concretely, from the TUI the user should be able to:

1. Run something like /pair (or hit a keybinding).
2. See a short pairing code / QR rendered in the TUI footer, alongside the existing model / cwd / task badges (apps/kimi-code/src/tui/components/chrome/footer.ts).
3. Open the Kimi mobile app, scan or paste the code, and the local CLI becomes reachable in the app under that user's account.
4. From the phone: see a list of running sessions, view the live transcript and tool calls, send follow-up prompts, and get notified when a foreground task needs approval or finishes.

This is not a request to build the mobile app itself — just the pairing protocol, the auth/account linkage, and the surface on the CLI side that lets an external client attach to a running session.

Why this matters

• Today, a foreground Agent subagent that takes a long time forces the user to either watch the one-line latestActivity summary in the transcript (apps/kimi-code/src/tui/components/messages/agent-group.ts), repeatedly press Ctrl+B to detach, or leave the laptop. There is no way to glance at it from a phone.
• The kap-server (packages/kap-server) already exposes the full session surface over REST + WebSocket (/api/v1, /api/v1/ws), so the wiring to make a remote client attach to a live session mostly exists — what's missing is the auth + pairing layer and a documented public surface.
• The mobile-responsive web UI shipped with apps/kimi-code/dist-web already does safe-area handling, on-screen-keyboard composer fixes, mobile settings sheets, etc. (CHANGELOG entries #1459, #1212, #1428). It is a PWA, not a native app; the Kimi mobile app would be a separate consumer of the same kap-server surface.

Existing infrastructure this can build on

• packages/oauth — Kimi OAuth + managed auth utilities; the pairing flow can mint device credentials the same way login does.
• packages/kap-server/AGENTS.md:8 — currently bound to loopback with --debug-endpoints and bearer auth. A pairing flow would add an authenticated, non-loopback bind mode gated by the paired-device credential.
• plugins/official/kimi-datasource/bin/kimi-datasource.mjs:386-389 — already mints and persists a per-install device_id under $KIMI_CODE_HOME/device_id. Pairing would be the natural upgrade of that anonymous identifier into an account-linked device record.
• docs/en/guides/ides.md:67 already acknowledges third-party orchestrators (Paseo) that attach to Kimi Code over ACP. Pairing would formalize the same idea for the official Kimi mobile app.

Sketch of the proposed protocol (high level)

1. CLI calls POST /api/v1/pair/start on the local kap-server (loopback, no auth needed — it is the device proving possession of the machine).
2. Server returns a short pairing code + a polling URL on the Kimi API.
3. Mobile app POSTs the code to the Kimi API, which marks it as claimed and returns a long-lived device token bound to the user.
4. CLI polls GET /api/v1/pair/status; once claimed, it upgrades its anonymous device_id to the account-linked device record, stores the token in the OS keychain (matching gh auth status / keyring behaviour in agent-instructions), and rebinds kap-server to the paired credential.
5. Mobile app then sees a "Kimi Code on " entry in its session list and connects via the existing WebSocket transport.

What this issue is not asking for

• A native iOS/Android app from scratch (that lives elsewhere).
• Replacing the local TUI or the web UI.
• Forcing the change — pairing must be opt-in; kimi invoked without any pair request must keep working exactly as today, with the same loopback bind and no extra surface area.

Additional information

• Related upstream issue search terms: "mobile app", "remote session", "pair device", "phone companion" — I searched the repo before opening this and did not find a prior feature request for this.
• This is a feature proposal, not a PR. Per the repo's AGENTS.md, "do not open a feature PR until maintainers have had a chance to respond here." I am happy to start a draft PR once there is consensus on the protocol shape.

Start by reading packages/kap-server/AGENTS.md, the /api/v1 and /api/v1/ws surfaces, and the existing device_id handling in plugins/official/kimi-datasource/bin/kimi-datasource.mjs. Review the TUI footer and agent-group references to understand the CLI surface; this proposal is done only after maintainers agree on the pairing protocol, auth model, non-loopback behavior, and documented public surface.