[Feature Request] Remote Control / Multi-Device Session Handoff

[lucianalima777]

Summary

Add the ability to start a Kimi CLI session on one device and seamlessly continue or remotely control it from another device (laptop, web, or mobile). This would be a major workflow improvement for users who work across multiple environments.

Motivation

Currently, Kimi sessions are tied to the local terminal process. If I close the terminal or switch machines, the session context is lost unless I manually export/import it, which breaks the conversational flow.

Common pain points:

1. Stepping away while the agent is working — can't approve critical tool calls or steer direction from another machine.
2. Switching devices mid-session — e.g., start a task on desktop, continue on laptop elsewhere.
3. Monitoring background work without keeping a terminal window pinned to one machine.

Proposed Feature

Two possible implementation levels:

Level 1: Session Persistence + Remote Attach (MVP)

• Sessions optionally run as a background daemon/service on the host machine.
• Users can "detach" from a session (close terminal) without killing it.
• Users can "attach" to an existing session from another terminal via authentication.
• Authentication via existing Kimi account OAuth or local token.

Level 2: Multi-Device Push Notifications

• When a running remote session needs user input (approval, plan mode decision, etc.), send a push notification to connected devices.
• Allow approving/rejecting tool calls from a lightweight mobile or web interface without needing a full CLI.
• Session state syncs in real-time across all connected clients.

Use Cases

Scenario	Current Pain	With Remote Control
Long-running data pipeline	Must keep terminal open	Detach, check later from anywhere
Plan mode on large refactor	Need to be present for every approval	Get notified on phone, approve on the go
Cross-device work day	Export/import context manually	Seamless handoff between devices
CI/CD agent integration	No way to monitor/intervene remotely	Attach to running CI session when needed

Technical Considerations

• Security: All remote communication should be end-to-end encrypted. Session tokens should be short-lived and revocable.
• State Sync: The existing context compaction and session export mechanisms could be leveraged for lightweight state serialization.
• CLI vs. Web: Even a minimal web dashboard for approvals (without full CLI replication) would unlock 80% of the value.
• Privacy: Users should be able to disable remote control entirely via config (kimi config set remote_control false).

Prior Art

Claude Code implements this as "remote control" — sessions are bridge-backed, allowing multi-device attach and mobile push notifications. The UX sets a strong baseline for what developers expect from an agent CLI in 2026.

Conclusion

Remote control would transform Kimi CLI from a "terminal-only" tool into a truly ambient AI partner that persists across a developer's entire toolchain. Given Kimi's strengths in subagents, MCP, and long context, adding multi-device session management would close a major UX gap vs. competitors.

Happy to elaborate on specific workflows or beta-test early implementations.

[ktwu01]

Concrete design sketch that maps onto kimi-cli's existing infrastructure rather than starting from scratch. The good news: you already have most of the pieces. The bad news: the wire-up is non-trivial.

What's already in the tree

Piece	Location	Already does
Web UI server	src/kimi_cli/web/app.py, src/kimi_cli/web/runner/process.py	FastAPI server with SSE streaming, session-token auth, CORS / origin enforcement, optional LAN-only / sensitive-API restrictions. Bound to 127.0.0.1 by default, 0.0.0.0 only with --network.
ACP server	src/kimi_cli/acp/server.py (468 lines)	Agent Client Protocol over stdio for IDE integration. Has session import/export, MCP tool routing, etc.
Background tasks + supervisor pattern	src/kimi_cli/background/manager.py (725 lines), worker.py, agent_runner.py	Persistent task store, agent runner, subagent spawning. Sessions can be queried, killed, resumed.
Wire serialization	src/kimi_cli/wire/	wire.jsonl is the canonical session event log — the same format used for session export/import.

These are the same building blocks Claude Code uses for Remote Control (see https://code.claude.com/docs/en/remote-control): a local server, an outbound-only tunnel to a relay, and a per-session credential. So the question is which transport and how much new server-side infra.

Transport options, ranked by cost-to-Moonshot

Option 1: LAN-only Web UI (≈free, ships today)

Document a workflow: kimi web --network already opens the existing FastAPI UI on the local network. With a session token + origin-enforcement env vars, it's a real "drive your local kimi from your phone" today, as long as both devices share the network.

What's needed:

• A minimal docs page: "Use kimi from another device on the same Wi-Fi"
• A kimi web --share-qr that prints a QR code with http://<lan-ip>:5494/?token=<short-lived> to scan from a phone, exactly like Claude Code's spacebar-to-show-QR pattern
• Mention KIMI_WEB_LAN_ONLY=1 and KIMI_WEB_ENFORCE_ORIGIN=1 defaults in the docs

Pros: zero new infra, no Moonshot-hosted relay, no subscription gating.
Cons: doesn't cover "I'm at a coffee shop, my desktop is at home" — same-LAN only.

This is probably the right MVP. Ship it as kimi remote-control --lan and call it a research preview.

Option 2: Bring-your-own relay (small)

Add an outbound-only WebSocket client mode: kimi connects to a relay URL (Cloudflare Tunnel, ngrok, a self-hosted relay container, or a Moonshot-hosted one) and the relay forwards messages to/from a paired phone/web client. This matches Claude Code's design exactly:

Your local Claude Code session makes outbound HTTPS requests only and never opens inbound ports on your machine. When you start Remote Control, it registers with the Anthropic API and polls for work.

For kimi-cli, the simplest first cut is BYO-relay, e.g.:

kimi remote-control --relay https://your-relay.example.com --pair-code XXXX

The relay can be a 200-line Go/Rust service that does nothing but pass JSON messages between two WebSockets keyed by pair-code. Anyone — Moonshot or a user — can host one. No new auth backend.

Pros: crosses NATs, doesn't require Moonshot-hosted infra, opt-in.
Cons: users need a relay URL; pairing UX is rougher than QR.

Option 3: Moonshot-hosted relay (largest)

Same shape as Option 2 but Moonshot operates the relay, and pairing happens via the Kimi Code OAuth identity (/login). This matches Claude Code's product surface exactly. Major upside: the UX for users is the cleanest — open phone app, see your sessions. Major downside: Moonshot owns a new piece of always-on infra with non-trivial auth, abuse, and latency requirements.

Best done after Options 1 and 2 are validated.

Concrete delta on the existing FastAPI app for Option 1

Looking at src/kimi_cli/web/app.py, the web UI already supports:

• KIMI_WEB_SESSION_TOKEN for bearer-style auth on every request
• KIMI_WEB_ALLOWED_ORIGINS + KIMI_WEB_ENFORCE_ORIGIN for CORS lockdown
• KIMI_WEB_RESTRICT_SENSITIVE_APIS to hide write-side APIs from the network
• KIMI_WEB_LAN_ONLY to refuse non-LAN bind addresses

The remaining gap for a real "Remote Control" minimum is:

1. Pairing UX: a kimi web --pair flag that prints a QR code + URL with the token already embedded, so the phone-side user doesn't have to type a token.
2. Push when input needed: when the agent enters an approval-required state, the local kimi can post a webhook (user-configured URL — Telegram bot, ntfy.sh, Pushover, etc.) so the user gets notified on their phone. No proprietary push backend needed.
3. Approval surface in the existing web UI: the web UI already shows the conversation; it likely doesn't yet have a one-tap "Approve / Reject" UX for tool calls. That's a frontend change in web/.

Items 1 and 2 are small. Item 3 is medium and visible.

What I'd ship as the first PR (if invited)

Just item 1: --pair flag + QR code. ~50 lines of Python + the qrcode library. Documents the existing capability instead of inventing a new transport. Sets the stage for Option 2 / 3 without committing to a specific relay design.

Open questions for maintainers (before any code)

1. Is "shared LAN" enough for the first version, or is "from anywhere" a hard requirement?
2. If "from anywhere": is Moonshot willing to operate a relay, or is BYO-relay acceptable for v1?
3. Should the approval-required webhook be in scope for v1, or can users wire it via existing hooks (UserPromptSubmit, PermissionRequest)?

Per CONTRIBUTING.md this is well over 100 lines of code in any direction, so happy to wait for a roadmap signal before any PR. But the smallest immediately-mergeable piece (the QR-code pairing flag for the existing kimi web) is something I can stage as a focused PR if you'd like.

[bdorlus]

+100

[Snailflyer]

The important split is handoff vs starting a fresh chat. For CLI agents, I would trust this more if the local terminal process stays the source of truth and web/mobile only attaches as a control surface.

I am building Faryo in that narrow lane: Codex/Claude/shell stays in host tmux; phone/browser handles compact output, short input, approve/interrupt, and handoff. Not a Kimi integration, just the same session-control problem from the tmux side: https://github.com/Snailflyer/faryo

[carltonawong]

One invariant I would make explicit for Level 1/2: attach is not the same as resume from a serialized chat. If the host terminal stays the source of truth, every remote attach or approval surface should carry a small handoff receipt before it can drive tools: host/session id, attached client id, current approval scope, last tool/result boundary observed by the client, pending user decision, and what must be revalidated if the client was offline.

That keeps cross-device control from accidentally turning stale context into authority.