Launchers and the uniform flags

orboto claude, orboto codex, orboto gemini, orboto kimi, orboto agy and orboto ollama are launchers: orboto starts the harness, stays its parent and gives it the guarantees orboto can offer - supervision, a project scope, a live terminal, the wake channel, the completion guard. This page lists the flags every launcher understands, and what each launcher does and does not provide.

The uniform flags

Added in v0.213.0 Every launcher takes the same three requests and translates them into the form its harness understands, so a harness never answers unknown option '--yolo'.

orboto claude --yolo
orboto codex --skip --continue
orboto gemini --resume 3f9a1c2e
orboto kimi --yolo --continue
orboto agy --resume <conversation-id>

• --yolo and --skip are one request. They behave identically. orboto claude also keeps --skip-permissions.
• Read anywhere before a bare --. The launcher reads its flags wherever they stand up to the first --. A -- right after orboto's own flags is orboto's separator and is dropped; a -- that follows harness arguments is the harness's own end-of-options marker and reaches it with everything after it. Added in v0.225.0 This rule is the same for every launcher.
• A harness without a form refuses. orboto ollama --yolo stops at the start with exit code 2 and names the launcher and the reason; it does not drop the flag silently.
• --continue and --resume <id> exclude each other. --resume takes the next word as the id. A bare --resume with nothing after it is the harness's own picker, and passes through unchanged.
• A full-access flag you typed natively is not doubled. orboto codex --yolo -- --dangerously-bypass-approvals-and-sandbox starts Codex with the flag once.
• A supervised restart keeps the translated flag. When orboto restarts a session after an update or an account switch, the full-access flag stays in the restart.

Two harness details: Gemini CLI's own bare --yolo is deprecated, which is why orboto passes --approval-mode yolo; and Kimi's own --yolo still asks before risky actions, which is why --yolo maps to --auto, the mode that never asks.

Flags you want on every start of orboto claude can be stored once as standing arguments.

Launcher flags every launcher takes

Added in v0.225.0 orboto claude, orboto codex, orboto gemini, orboto kimi, orboto agy and orboto ollama read the same launcher flags, anywhere before a bare --. They never reach the harness, and orboto <launcher> --help lists them.

Your CLI updates itself before the session starts

Added in v0.225.0 Every launcher compares your CLI with your orboto instance before the harness starts. If the CLI is older, the start says so in one line, installs the newest release (checked against its published checksum) and starts itself again on the new binary with exactly the arguments you typed:

orboto kimi: CLI 0.224.0 is older than the instance 0.225.0 - run `orboto self-update` and restart this session
orboto kimi: the CLI was updated to 0.225.0 - restarting this command with the new binary
orboto kimi: this start runs the CLI 0.225.0 the self-update installed

The restarted start never updates a second time. If the update fails, the start warns and your session starts anyway on the installed CLI. When the CLI cannot be replaced, for example because it was installed by another user or a package manager, orboto says so before downloading anything; update it the way you installed it. --no-self-update or ORBOTO_NO_SELF_UPDATE=1 keep the installed CLI, and the session then runs with the older CLI's behaviour until you update.

The same check runs when orboto messages --follow, orboto codex-runner, orboto agent-runner and orboto pi-runner start work; each takes --no-self-update, and their status and stop commands never update. On a server where the service user cannot replace the binary, set ORBOTO_NO_SELF_UPDATE=1 in the service environment.

What each launcher provides

Every launcher declares each guarantee as provided or missing, with the reason. A launcher with gaps names them in one line on stderr when it starts, and orboto <launcher> --help prints each gap with its reason after the usage:

orboto codex: this launcher does not provide scope, transcript, mcp config, sign in probe, wake, completion guard, status line, update guard (`orboto codex --help` names why)

orboto claude provides every guarantee and prints no such line. Added in v0.223.0 orboto kimi and orboto agy provide most of them; orboto codex and orboto gemini share a smaller set:

Added in v0.230.0 A second launcher in a busy checkout gets a row of its own. A launcher whose checkout token another launcher on the machine already runs under takes the lowest free suffix (-s2, -s3), so the two sessions never share a row, and they run side by side as long as their scopes share no project and no ticket. A new start that continues the same conversation of the same harness gets the token of a session that just ended back inside 10 minutes; orboto codex and orboto gemini report no session of their own, so their restarts start fresh. The rules are on Session origin and state. Mail reaches a session started with orboto claude, orboto kimi or orboto agy without a Monitor beside it, see Agent inbox and wake-up delivery.

Runner sessions differ from these terminals. A session a runner owns - orboto agent-runner, orboto codex-runner and orboto live-session run - switches login profiles at the usage limit when it runs Claude Code or Codex and starts with --account and --on-limit ask|stop|switch:<names>: it reacts to the limit the harness reports, it has no start default and no switch before the limit, and a runner of any other harness ignores both flags. Added in v0.230.0 Such a session takes the policy change from Admin -> Agents -> Live and orboto live switching as well, and publishes its policy there. agent-runner, codex-runner and live-session run --daemon accept API-key profiles only, because an unattended session cannot sign in. How to change a policy is on Login profiles.

How Kimi Code and Antigravity CLI get their mail and what orboto writes into their settings is on Kimi Code with orboto and Antigravity CLI.

In plain terms, for Codex and Gemini CLI:

• There is no project gate. orboto codex starts in any directory and asks for no project, where orboto claude refuses a directory that is not wired. orboto kimi and orboto agy do not refuse either, but declare the project the folder belongs to.
• There is no scope declaration. The launcher declares no role and no project and registers no orboto agent session, and no mail reaches the running session. The harness can still use orboto through the CLI or MCP (Codex CLI), and the agent inbox describes the wake paths for harnesses without a channel (Agent inbox). When gemini is not installed and agy is, orboto gemini starts agy with everything orboto agy provides.
• The live session is a terminal only. With an orboto login and a terminal, the launcher shows the terminal in Admin -> Agents -> Live, which is how an operator watches and types into it. There is no transcript; --no-live and ORBOTO_LIVE_SESSION=off keep it out.
• No completion guard and no status line. Nothing checks the session's work at the end of a turn.
• orboto <launcher> update works, without the dependency and changelog check orboto claude update runs first. See Update Claude Code, Codex and the other harnesses.

pi has no launcher. Its runners (orboto pi-runner and the lane runners) own headless turns instead of an interactive terminal; see Run an agent fleet.

The adapter contract

Behind the launchers is one adapter per harness and one registry, so every launcher answers to the same contract. An adapter declares the guarantees above, starts the harness (supervised or not), translates the uniform flags, builds the argument list a restart resumes with, and, when it owns them, the MCP configuration entry named orboto, the sign-in probe, the completion hook, the status line and the transcript source. The registry refuses an adapter that leaves a guarantee undeclared or declares a gap without a reason, and every registered adapter passes one shared conformance suite that starts a fake harness and checks the flags, the restart, the scope, the live terminal, the login profile and the gap lines.

For you, the contract means three things: the flags above behave the same on every launcher, a missing guarantee is always named rather than silently skipped, and a new harness joins by passing the same checks.

A control session starts any of these launchers in another checkout with orboto agent start.

See also Login profiles, Claude Code with orboto and Publish an agent session live.