Feature Request: Remote Control - Continue local sessions from any device

What feature would you like to see?

Add a Remote Control feature that allows users to continue a local Kimi Code CLI session from their phone, tablet, or any browser. This enables seamless workflow continuity when users need to step away from their desk while keeping their full local environment accessible.

Additional information

Motivation

Currently, Kimi Code CLI sessions are tied to the terminal where they were started. If a user needs to leave their desk while in the middle of a task, they cannot easily continue that session from another device. This feature would:

• Enable users to work from anywhere without losing session context
• Allow seamless switching between devices (terminal ↔ browser ↔ mobile)
• Survive interruptions like laptop sleep or network drops with automatic reconnection

Proposed Functionality

Core Features

1. Remote session hosting: Start a local session that can accept remote connections
2. Multi-device sync: Conversation stays in sync across all connected devices
3. Full environment access: Remote users can access the local filesystem, MCP servers, tools, and project configuration
4. Automatic reconnection: Session reconnects automatically when the machine comes back online after network drops

User Interface

# Start a new remote-controllable session
kimi remote-control

# Or from within an existing session
/remote-control

When activated:

• Display a session URL for browser access
• Show a QR code (toggle with spacebar) for quick mobile access
• Show connection status and tool activity in the terminal

Connection Options

1. Browser: Open the session URL in any browser to access via web interface
2. Mobile: Scan the QR code with the Kimi mobile app (if available)
3. Session list: Find the session by name in the web/app session list with online status indicator

Configuration

# Enable Remote Control for all sessions by default
/config  # Set "Enable Remote Control for all sessions" to true

Command Flags

• --verbose: Show detailed connection and session logs
• --sandbox / --no-sandbox: Enable/disable sandboxing for filesystem and network isolation

Security Considerations

• Outbound-only connections: Local Kimi Code CLI should make outbound HTTPS requests only, never opening inbound ports
• API registration: Session registers with the Kimi API and polls for work
• Message routing: Server routes messages between web/mobile client and local session over streaming connection
• TLS encryption: All traffic travels through the Kimi API over TLS
• Short-lived credentials: Use multiple short-lived credentials, each scoped to a single purpose and expiring independently

Technical Requirements

Server-side

• API endpoint for session registration and management
• WebSocket or streaming connection support for real-time message routing
• Session state synchronization across devices

Client-side

• Polling mechanism for remote commands
• Local HTTP/WebSocket server (outbound-only via API polling)
• Session persistence and reconnection logic

Limitations (to consider)

• One remote session per Kimi Code CLI instance
• Terminal must stay open (Remote Control runs as local process)
• Extended network outage (>10 minutes) may cause session timeout

Alternatives Considered

Approach	Pros	Cons
SSH tunneling	No server dependency	Complex setup, security concerns
Cloud-hosted sessions	Works without local machine	Loses local environment access
API polling (proposed)	Secure, no inbound ports	Requires server infrastructure

Related Features

• Web interface: Kimi Code on the web could run in cloud infrastructure vs. Remote Control which executes on the user's machine
• Session persistence: Related to the ability to save and resume sessions

Additional Context

Reference implementation: Claude Code Remote Control

The issue names no files or tests. Start by locating the CLI command handling for kimi remote-control and the /remote-control session entry point, then map the existing session persistence and connection behavior. Done would require an agreed scope and working remote access, synchronization, reconnection, and security behavior across the listed client options.