orbotodocs
Agents & AI

Kimi Code with orboto

Start Kimi Code with orboto kimi: the session declares its scope, gets the orboto MCP server, receives its agent mail and runs the completion check at the end of every turn.

Added in v0.223.0 orboto kimi starts Kimi Code (the kimi command, version 2) the way orboto claude starts Claude Code. orboto stays the parent process, the session registers with a scope, the orboto MCP server is wired in, new agent mail reaches the agent, and every turn ends with the completion check.

What you need

  • Kimi Code 2 installed, so that kimi --version answers in a terminal.
  • The orboto CLI, logged in (orboto login, or a key profile for an agent account, see Login profiles). Without a login Kimi Code still starts, but the session registers nothing and no mail reaches it.
  • Recommended: a separate agent identity for Kimi, so the session works as its own bot and not as you. Create an agent key for it in the admin UI, log it in as a profile and bind the profile to the harness once:
orboto login --profile kimi --api-key
orboto profile bind kimi kimi

From then on every orboto call inside an orboto kimi session runs as that identity, without a profile flag. Add --strict-identity to the start to refuse a start under another harness's identity.

Start

orboto kimi                                     # works on the project this folder belongs to
orboto kimi --yolo --continue                   # never ask, continue the last session in this folder
orboto kimi --role lead --scope-projects ACME   # declare the scope yourself
orboto kimi --no-scope                          # declare no scope
orboto kimi --resume <session-id> -- -m <model> # one session; everything after -- goes to kimi

Without scope flags the session declares the role worker on the project of the folder you start in. The start prints one line saying which scope it declared and where it found the project. --yolo maps to Kimi's --auto mode, --continue and --resume <id> to Kimi's own continue and session options; the full table is on Launchers and the uniform flags.

What orboto writes into Kimi Code's settings

On every start, before Kimi Code runs, orboto kimi writes its entries into Kimi Code's user settings folder (~/.kimi-code, or the folder a login profile points to) and prints one line whenever it changes a file:

FileWhat orboto addsWhat stays untouched
mcp.jsonthe orboto MCP server, which runs the orboto CLI under your loginevery other server
config.tomlone block between # >>> orboto hooks and # <<< orboto hooks with the orboto hooksevery other line
tui.tomlAdded in v0.226.2 the orboto status line command orboto harness-statusline kimi; if you already have a status line command of your own, orboto runs it for you so your line staysevery other line, including your items

The hooks only act inside a session that orboto kimi started; in any other Kimi Code session they do nothing. A config.toml that already defines its hooks inline (hooks = [...]), or an orboto block whose end line was deleted, is refused with a message that names the file, and orboto writes nothing. orboto doctor shows the state of both files.

Added in v0.230.8 The orboto server offers no tools of its own: the agent works through the orboto CLI in the shell. It still answers Kimi Code's lists of tools, prompts and resources, all three empty, so Kimi Code 2.3 and later keep the server. Before 0.230.8 Kimi Code dropped it with MCP server "orboto" failed: MCP error -32601: Method not found. The server starts at your instance's version, so the instance has to run 0.230.8 or later. To check, run /mcp in the session: orboto is listed as connected.

How agent mail reaches the session

Kimi Code has no way for a server to push into a waiting session, so orboto uses three paths:

  1. Every orboto tool call carries a note when unread agent mail is waiting.
  2. Your next prompt and the end of every turn. New mail is added to the context of your next prompt. When a turn is about to end and new mail has arrived, the turn continues so the agent handles it first. Each message is handed over once.
  3. A waiting session. When the session sits at its prompt, nobody has typed for a minute, the screen has been quiet for five seconds and a message is waiting that should wake it (addressed to this session, a request, an urgent message), orboto types one line at the prompt, for example orboto: 1 new message(s) for this session (1 request) - read them with orboto messages and handle them. The line names counts and kinds only, never the message text. Nothing is typed before Kimi Code has reported its first state after a start or restart, so a trust or login question is never answered on your behalf.

Added in v0.230.0 The supervisor reads the inbox every 15 seconds, and that read is what keeps the session reachable: orboto who lists an orboto kimi session as reachable by inbox stream, so role mail finds it. You run no Monitor and no orboto messages --follow beside it; the supervisor already does the waking. Started with --no-supervise, there is no supervisor and nothing wakes the session.

The completion check

When a turn ends, orboto checks whether the session still owns work it is allowed and able to do. If so, the turn continues with the reason. A deliberate pause, a legitimate wait or three holds without progress let the turn end. If orboto cannot be reached, Kimi Code ends the turn as usual.

Restart and resume

An account switch, orboto kimi switch or orboto kimi update --restart resumes exactly the session that was running, including one you started with /new, declares the scope again and keeps the live terminal.

Added in v0.230.0 A second orboto kimi in the same checkout gets a session token of its own (the checkout's token with the suffix -s2) instead of sharing the first session's row, and runs beside it when its scope shares no project or ticket with it. When a session has just ended, its token stays taken for 10 minutes. Only a start that continues the same Kimi Code session, orboto kimi --resume <session id> or --continue, takes the row back with its scope and leases. orboto records the Kimi Code session id once the orboto session has declared its scope, at the start or later with orboto session-start in the session's shell. Any other start gets a row of its own. See One session per account, checkout and scope.

The conversation in Admin → Agents → Live

Added in v0.226.2 Admin → Agents → Live shows an orboto kimi session as a conversation: your prompts, Kimi's answers, one line per group of tool calls ("read 2 files, ran 5 shell commands") that you can expand, and a line per finished turn with duration, model and effort. orboto reads it from Kimi Code's own session record and masks secrets as in every live session. After a restart the view continues with the resumed session. The footer shows how full the context window is, as reported by the orboto status line. If orboto does not recognise the record, the view says so once and the Terminal tab carries the session.

Removing what orboto wrote

Added in v0.226.2 orboto kimi unwire removes the orboto MCP entry, the hook block and the status line command from Kimi Code's settings and puts back a status line command of yours exactly as it was. It names every file it changed; a status line it did not write is left alone. A session that orboto kimi still supervises writes its wiring again on its next start or restart.

What Kimi Code does not get

GuaranteeStatus
Usage windows in orbotoKimi Code reports none to a status line, so they stay in Kimi Code (/usage).
Permission questions in the Live viewKimi Code's session record does not carry them; answer them in the terminal or the Terminal tab.
Update guard (dependency and changelog check before orboto kimi update)orboto kimi update works without it.

orboto kimi --help lists each of these with its reason.

See also Launchers and the uniform flags, Agent inbox and wake-up delivery and Login profiles.

On this page