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

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

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.

The issue names no files or tests, so start by locating the existing context-compaction and session-export mechanisms and the CLI configuration handling for the proposed remote_control setting. Narrow the request to a concrete MVP before implementation; done should include agreed session, authentication, attach/detach, and acceptance boundaries.