kimi-bridge 0.4.0

Control a local Kimi Code agent from Feishu, QQ, or Telegram

kimi-bridge

Control a local Kimi Code agent from an instant-messaging conversation.

kimi-bridge supervises Kimi Code's local server, keeps chat-to-session bindings across restarts, streams editable replies, and brings approvals, questions, steering, files, thinking output, and session controls into your chat client.

Support

Surface	Status
Feishu direct messages	Supported
WeChat bot	Not currently supported
Telegram private chats	Experimental
QQ C2C (private chats)	Supported
Linux, Python ≥3.11	Supported
macOS and Windows	Experimental
Voice messages	Not currently supported

Only one adapter runs in each bridge process. Feishu uses the official lark-oapi WebSocket client. Telegram and QQ use small handwritten httpx/websockets transports without a platform SDK dependency.

Features

• Durable Kimi session creation, listing, switching, renaming, inspection, compaction, and undo.
• Edit-in-place answer streaming, router-side chunking, and optional separate thinking output.
• Interactive approvals and questions with timeout handling and stale-action protection.
• Busy-turn prompt steering, cancellation, permission modes, model/effort/plan controls, goals, tasks, skills, and read-only MCP inspection.
• Inbound images and files plus workspace-contained outbound /send.
• Private-chat allowlists, loopback-only Kimi server supervision, and a secret-safe non-starting doctor command.

Quick start

Install and authenticate official Kimi Code, then install uv and kimi-bridge:

uv tool install 'kimi-bridge'

Create ~/.kimi-bridge/config.toml for one adapter, protect it with chmod 600, and validate the installation without starting the server or connecting to chat:

kimi-bridge doctor

Then run:

kimi-bridge

Start with the installation runbook, especially when asking a coding agent to configure the bridge. The configuration reference contains complete Feishu, QQ, and Telegram examples.

Commands

Commands cover:

• sessions: /new, /sessions, /switch, /status, /title, /usage, /compact, /undo;
• control: /mode, /model, /effort, /plan, /goal, /stop;
• tasks and tools: /tasks, /skills, /mcp;
• output: /send, /render-thinking.

Use /help in chat or read the command reference for exact grammar, busy-session behavior, and platform media semantics. Send /<command> ? for detailed in-chat usage, including sub-forms such as /tasks show ?.

Architecture and security

Feishu, QQ, or experimental Telegram
              │
              ▼
       semantic chat router
              │
              ▼
  supervised local `kimi web`

The Kimi client owns all REST, WebSocket, version, and process-lifecycle details. The router owns platform-neutral session and interaction behavior. Each adapter owns its native transport and UI payloads. See Architecture for the full boundary.

The managed Kimi server binds to loopback and uses its generated bearer token. Chat access is restricted by the selected adapter's allowlist, but kimi-bridge is designed for one trusted operator, not mutually untrusted tenants. A permitted Kimi agent can read, write, and execute within the authority of the host account, so protect both the host and chat credentials.

Tested Kimi Code versions are recorded in a packaged compatibility manifest. An unlisted official version emits a loud warning and is attempted against the live contract; legacy Python kimi-cli, an unrecognized product, or an executable/server version mismatch fails. Run kimi-bridge doctor after every Kimi or bridge upgrade.

Documentation

• Install and operate
• Configure
• Commands and interactions
• Architecture and compatibility
• Upstream Kimi Code
• Report an issue

Development

uv sync --dev
uv run pytest -q
uv run ruff check .

Unit tests use fake Kimi, Feishu, Telegram, QQ, WebSocket, state, and process boundaries; hosted checks use no credentials or inference.

License

MIT © 2026 Mtrya