Agent support

RimZ has a built-in adapter for thirteen coding agents. Each adapter reads the agent's own hooks, transcripts, and local files, and turns them into the sidebar card, rimz asks, spend figures, and launch argv. The agent CLI runs stock, you answer it in its own UI, and the provider's web, desktop, and mobile apps keep working. This page answers, per agent: what the card shows, which files and flags RimZ touches, and where the gaps are. How the adapter boundary works is the agent model.

Each agent sits in a support tier. The tier is how much the author runs it day to day; every agent in every tier is wired against its documented surface and covered by tests. An experimental agent can still carry a wide surface, as the compatibility matrix shows.

RimZ tracks each agent's latest release. Where a feature needs a minimum agent version, this page names it next to the feature.

Check coverage on your machine

rimz coverage prints the capability grid with the limit behind every cell, and rimz coverage --wiring adds the wiring matrix and the lifecycle hook grid. Every adapter declares its own coverage, and a test holds the declarations to the matrices on this page. The command's output, flags, and JSON shape are in check adapter coverage.

The terminal grids differ from this page in two ways. Cells print ✓ where this page shows ● or ✓, ! where it shows ◐, and ✗ for ✗. Rows follow the adapter registry (claude, codex, amp, copilot, kimi, pi, opencode, antigravity, cursor, droid, kiro, qwen, grok) instead of tier order, and loaded process plugins follow the built-ins.

What the marks mean

A mark says what you see on the card and when you see it. Two tests settle every cell: whether the whole capability arrives (complete), and whether it arrives while the agent works rather than after the turn ends (live).

How RimZ gets a figure does not change its mark. A value read from a wrapped statusline and one read from a transcript tail both count as full when the card shows the same complete, live result; a native hook that carries half the story counts as partial. The mechanism is the wiring matrix.

The six capabilities

Each capability is one thing a card or command shows you. State is the base the rest depend on: attention routing, card ranking, and message delivery all read it.

A few cells need more than the table says:

• State stays full for agents that publish no session-end event. Their card clears on the next sidebar refresh after the pane is gone, the same tick every card refreshes on.
• A History partial splits reading from accounting. rimz agents logs and rimz agents history still replay the session, while the provider dashboard shows the agent's session count with tokens and dollars blank.
• Answering is separate from Ask. Every agent takes its answer in its own UI, and rimz answer adds an out-of-band path for Claude, Codex, and Pi (what each agent accepts).
• Claude Code children also carry a running token count and an elapsed clock. The child row shows both for any agent that reports them.

Claude Code and Codex history also times responses for the Models tok/s figure in rimz stats and rimz agents attribution. Stats scopes timing to its selected window; attribution scopes it to the report's agents. Other adapters retain their history coverage but supply no response timing.

The compatibility matrix

One row per agent, in tier order. Run rimz coverage for the limit behind every ◐ and ✗.

_{● full · ◐ partial · ✗ unsupported}

A ✗ is a declared absence with a stated reason in rimz coverage, so a missing surface is a known gap and not a bug.

Notes on the alpha and experimental set

These are the gaps you will notice, per agent, beyond what the matrix and rimz coverage state. The files rimz hooks install writes for each agent, and what uninstall restores, are in what install writes. Each agent's mapping doc has the full rationale.

Antigravity

• Permission prompts and questions stay in Antigravity's UI, because RimZ installs no permission hook. An open prompt raises Waiting and routes you to the pane.
• Context and tokens are live from the wrapped statusline. The dollar figure prices the current turn only, so it does not count toward room spend or budget caps.
• History replays every past session and adds no dollars to rimz stats.
• Children come from the parent's invoke_subagent transcript records, which the CLI writes late, so a fan-out often appears as the parent's turn ends. A worktree, branch, or share child stays a root card while its validated siblings nest.
• Every error stop is terminal: a supervised run does not survive a provider limit, and auto-continue never arms.
• Yolo does not approve implementation plans (since 1.3.2). Only the user's artifactReviewPolicy setting lifts plan review; RimZ does not change it.

Copilot

• With RimZ's hooks installed, launches refuse when effective disableAllHooks is true. Explicit ask launches also refuse a local non-manual defaultPermissionMode; the error names the settings file and fix. RimZ takes each key from the first file that sets it: .github/copilot/settings.local.json, then .github/copilot/settings.json, then your user settings.json.
• The wrapped statusline supplies the resolved model, effort, context tokens, and cumulative session tokens. The live dollar figure comes from the session's AI credits at $0.01 per credit, or is an estimate at that model when credits are absent; when the statusline is missing or replaced, RimZ falls back to OpenTelemetry metadata.
• That fallback needs a local telemetry file. An OTLP exporter configured in the environment sends the telemetry elsewhere, so RimZ warns Copilot direct-launch enrichment is unavailable because an OTLP exporter is configured; set COPILOT_OTEL_FILE_EXPORTER_PATH to retain a file source and the card keeps lifecycle alone. Point COPILOT_OTEL_FILE_EXPORTER_PATH at a file to keep both.
• History adds per-model tokens and credit-metered dollars (local estimates where credits are absent) to rimz stats and the provider dashboard. These are not an account billing ledger.
• Tool questions and elicitation dialogs raise Waiting. Tool questions clear when the tool completes; elicitation waits clear on subsequent lifecycle activity.
• Children appear with their model when they start, show their tool activity, and report their exact token total when they finish. A child's permission prompt arrives on the parent session, so the parent card waits. An approved shell command clears it when the child's command finishes; a denied or non-shell request clears at the parent's next hook.
• The account shows the plan and the monthly cr, cht, and prm windows. There are no 5-hour or weekly windows, and IDE completions, extra credits, account dollars, and remote control are unsupported.

Cursor

• Cursor's AskQuestion and plan-approval ("Ready to build?") prompts have no hooks. RimZ detects an open one from Cursor's local state, raises Waiting, and routes you to the pane; rimz asks stays empty and rimz answer is unsupported.
• A later message clears a plan wait. Dismissing the plan prompt with Esc or p leaves the card waiting until the next turn, because Cursor records no change.
• The installed CLI accepts subagentStart and subagentStop hooks but never fires them. RimZ reads children from the chats store when the parent's next hook fires, often at turn end.
• RimZ prices each generation locally. The running session total counts toward agent and room budgets; provider billing, account spend, and rimz stats dollars are unavailable.

Droid

• Permission and question prompts arrive as typed Notification hooks and reach rimz asks. The hook carries no request id or options, so you answer in the pane.
• A spec-mode exit shares the tool confirmation and reads as a permission. Releases without a notification type fall back to the transcript's active AskUser call.
• The locally priced session total reaches the card and live budgets. Provider dollars, historical spend, and quota are unavailable.
• After a compaction the card can read compacting, and messages queued for it wait, for up to 90 seconds, because Droid sends no compaction-finished hook.

Kiro

• Turns, tool calls, and session exits arrive through the global hook file rimz hooks install kiro manages, which needs Kiro CLI 2.31.0 or later.
• Kiro's local session store still supplies the card before the first prompt, pending approvals, context, and history.
• A cancelled turn releases message --wait and agents wait while a sidebar runs. Errored turns still wait out the deadline; supervised -p runs do so on both cancel and error.
• A pending tool approval or native question raises Waiting; answer it in Kiro's pane, not through rimz asks or rimz answer.
• Live details show the model, effort, and session title; context usage is a percentage only.

Kimi

• Kimi Code 2.1.1 or later is required. Installation refuses a detected older version with kimi upgrade -y; an unknown version does not block installation.
• Invalid hook entries block installation and preview without changing the config. Fix or remove the named entry: Kimi Code ignores every hook while one entry is invalid.
• TurnStarted opens main-agent background turns; user turns still open through UserPromptSubmit alone.
• Children appear at the next recorded root hook after their durable spawn record lands. Failed children settle as failed; cancelled and timed-out children show as finished. Finished children stay closed on resume.
• The main wire distinguishes child-fired turn ends from parent boundaries. A child's compaction still shows on the parent card; cancellation can leave it compacting until the next root signal.
• Parent live dollars, lifetime spend, and fleet spend include child wires; parent context tokens remain main-only.

Qwen

• Qwen's quota is scoped to the exact provider account (region and API key), not to the CLI. A fresh supervised or loop launch reads only that account's cached Coding Plan windows: a spent window stops the launch before any pane or run record exists, and another account's window cannot stop it.
• Interactive launches, resume, fork, wait, and auto-continue ignore the quota. See budgets: one model, five scopes.

Grok

• RimZ installs passive global hooks only; every permission decision stays in Grok's TUI.
• A running Grok session reads its hook registry as a snapshot taken at start, so rimz hooks install leaves that session calling whatever was registered before. Press r in Grok's Hooks tab, or start a new session, to pick up the installed hooks.
• Permission, plan, diff-review, and question prompts reach rimz asks through Grok's Notification hook.
• Errored and cancelled turns end through Grok's StopFailure and StopCancelled hooks, and child agents resolve from their own session hooks.
• Launch reminders reach Grok through --rules.
• Idle notifications rest the card only when their timestamp is newer than its last activity.
• Dollars land at each completed turn, native or locally priced. Mid-turn cost and account quota windows are unavailable.

Config homes and skills

Each built-in agent keeps its settings, sessions, and credentials in a config home. RimZ reads from it, installs hooks into it, and binds it into the sandbox.

Host launches link RimZ library skills into the resolved skill root, including each named Claude account home, without replacing user-owned entries.

Claude Code and Codex also run under named accounts: RimZ sets the override variable to a separate config home per account when a room launches that provider. Other agents always use their default home. See provider accounts.

Under agents.isolation = "sandbox" (Linux), RimZ binds each agent's config home from the launch environment and merges the RimZ skill library into the agent's skill root. The sandbox does not hide the rest of the host or move credentials. Project skills and Codex's $CODEX_HOME/skills stay outside the merged view. A profile skills list keeps the listed skills model-callable and makes the rest user-only; agents marked refused in the table fail the launch when a list is set. Host Claude makes unlisted skills user-only; host Codex hides them, including explicit invocation. Other host providers warn and run unrestricted. Duplicate or invalid names are parse errors under both. The profile rules are in configuration: skills, and mount order and markers in sandbox internals.

Launch flags

RimZ launches each agent with the provider's own flags. A typed profile field or rimz agents flag that an agent cannot express fails the launch before any pane opens, with an error that the agent "does not support profile field" and names the field. Raw profile args pass any other provider flag through unchanged, as do CLI arguments after --. Codex rejects --remote X or --remote=X, from either source, because managed panes run embedded with --no-daemon; remove --remote to launch. Codex requires 0.156.0 or newer for that flag on every launch, resume and fork. RimZ checks the resolved launch binary before opening a pane where possible, otherwise in the exec wrapper; an unreadable version passes without a verdict.

OpenCode requires 2.0.0 or newer and runs with --standalone on every launch and resume. Launch, setup/install, and doctor refuse an older readable version with opencode upgrade --major; an unreadable version passes without a verdict. Fork and model presets are unsupported. Plan adds no arguments; select the plan agent interactively with Shift+Tab. The plan-approval gate in the wiring matrix still works for those interactive turns.

Qwen requires 0.25.1 or newer. Launch refuses an older readable version with npm install -g @qwen-code/qwen-code@latest; an unreadable version passes without a verdict. It also refuses disabled hooks, naming the source and fix: disableAllHooks, tools.executionSandbox, --safe-mode, --bare, or truthy QWEN_CODE_SAFE_MODE or QWEN_CODE_SIMPLE. Execution-sandbox policy must be removed by its operator, or Qwen must run outside RimZ. Refresh existing Qwen hooks with rimz hooks install to adopt the seconds-based timeout before launching.

Provider-session resume

rimz agents <kind-or-profile> --resume opens a native picker. --resume=<id> first checks exact ids recorded in this room; importing an unrecorded id requires a locator, which reads only the room account's home. See provider-session resume for conflicts and refusals.

Permission modes

A permission mode comes from the mode profile field, the --ask and --yolo flags, or a <kind>-<mode> cell such as claude-plan. RimZ appends the arguments below. none means the mode adds no arguments, so the agent keeps its own default; for Auto and Yolo, the <kind>-auto and <kind>-yolo cells do not exist (permission-mode cells).

Claude additionally receives routine-command permissions by default through one merged --settings, independent of permission mode. Each prefix below gets one Bash(<prefix> *) rule, matching the bare command and its arguments:

• rimz message, rimz agents, rimz subagents, rimz teams
• rimz asks, rimz answer, rimz wait --in
• rimz pane list, rimz pane capture, rimz loop show, rimz loop logs
• rimz lsp def, rimz lsp refs, rimz lsp hover, rimz lsp impl, rimz lsp callers, rimz lsp callees, rimz lsp symbols, rimz lsp find, rimz lsp check, rimz lsp list, rimz lsp status

There is no blanket RimZ grant. pane send, wait --run, loop add, events emit, and lsp shim, attach, or stop are not added. The settings also union the agent-visible scratch/shared directories into permissions.additionalDirectories and add an autoMode.environment entry retaining $defaults; profile entries remain. Opt out with machine-only [agents] allow-routine-rimz = false. These are Claude permission settings, not permission hooks; Claude's managed policy and explicit ask/deny rules still apply. The rimz agents and rimz subagents rules also allow launches with --yolo or a passthrough bypass flag. The rimz teams rule covers the whole scene: launching, stopping, and restarting cohorts, resuming one with --yolo, and rimz teams install, which writes team and agent definitions from the RimZ repository into ~/.rimz/ and replaces existing ones with --force. rimz answer allows answering another agent's prompt (security).

Claude's same --settings adds exact Skill(<name>) rules for every profile-listed skill, independent of that switch, and for installed rimz-* skills when the switch is on. Names are directory names, not frontmatter names, from the provider skill root or RimZ library; names containing * receive no rule. Profile rules stay first, and additions are deduplicated.

Markdown definitions can also supply allowed-tools permission rules. Claude merges them into the same permissions.allow, in both isolations and independently of the routine switch. Other kinds warn in agents validate and at launch and do not apply the list. Claude auto mode drops some broad rules; the definition reference describes that limit.

Codex receives no RimZ permission rules. Users may add their own ~/.codex/rules/rimz.rules (or $CODEX_HOME/rules/rimz.rules) using, for example, prefix_rule(pattern = ["rimz", "agents"], decision = "allow"). The upstream rule contract covers matching and precedence; RimZ does not create or modify that file.

Under agents.isolation = "sandbox" a Codex launch replaces any --sandbox choice with --sandbox danger-full-access, because the RimZ view is its sandbox; approval flags stay as listed, though an on-request policy then prompts only for commands Codex judges dangerous (sandbox internals).

Grok Plan adds no arguments because Grok's /plan is an interactive command, and a session launched with --permission-mode plan does not start in plan mode.

Model and effort

--model and --effort on rimz agents, and the model and effort profile fields, render as below. RimZ passes the value through without checking it, so effort levels are whatever the agent's CLI accepts.

Amp has no model flag; its --mode selects the agent mode, and the model value is passed there. The --max-turns cap for supervised runs is in supervised runs.

Fast mode

The fast profile and role field asks the provider for its fast mode (priority serving, at a higher price). Fast is on or off. On renders the switch below; off renders nothing, so the provider's own default stands (a saved Claude /fast, a Codex service_tier in config.toml). The launch record keeps the effective value, so restart, fork, and resume replay it like the recorded model.

A definition that sets fast: true on a kind without a switch fails at load with the fix. Claude merges fastMode into the same settings value as RimZ's other settings, since only the last --settings takes effect. Codex also turns on its fast_mode feature, since a user-level fast_mode = false otherwise drops the tier silently; a managed feature pin still wins without an error. Amp fixes fast when a thread is created. Current Amp builds leave RimZ no local token record, so no Amp turn is priced.

Launch-prompt replacement

The profile fields system-prompt-file and append-system-prompt-files (and the matching rimz agents flags) replace the agent's system prompt. RimZ joins the base file and the appended files in order into one prompt, then hands it to the agent.

Pi's replacement is not complete: Pi still appends its own APPEND_SYSTEM.md, context files, skills, and working-directory material after RimZ's text. The full prompt is visible in Pi's process arguments.

Interrupt key

rimz message --interrupt types a prompt, then presses the agent's interrupt key to stop the live turn. The message reference describes when Codex replays the prompt as a fresh turn. Only agents with a declared interrupt key support this mode.

Auto-compaction window

The auto-compact field on a profile or team role sets the agent's native auto-compaction window, as a token count from 100k through 1M inclusive: "200k", "200000", or "1m". RimZ rejects anything outside that range before launch, so "200" fails instead of meaning something different to each CLI. This is separate from RimZ smart compaction. Which agents accept a trailing instruction when you compact by hand is in rimz agents compact.

Profiles without an explicit or inherited auto-compact use the machine [harness] auto_compact default, 272k, on Claude and Codex. This covers Markdown definitions and trusted project TOML profiles; bare-kind launches are unchanged. "off" passes no native window, leaving the provider's own default. The clamps above still apply.

The wiring matrix

The wiring matrix is the mechanism under the six capabilities: nineteen integration concerns, each naming one thing an adapter reads from or drives in its agent. Use it to find why a capability reads partial, or when building an adapter.

_{✓ wired (the concern reaches a user-complete state) · ◐ partial (the adapter names the gap) · ✗ unsupported (out of reach of the agent's protocol). rimz coverage --wiring prints the gap behind every cell.}

Identical-tool loop detection needs both the tool name and its structured arguments on the hook, because a name-only match would flag legitimate repeated reads. Only Claude Code and Codex send both; every other agent has loop detection off.

The lifecycle hook surface

RimZ folds eleven lifecycle signals into every agent's state. The table names the native event each agent fires for each signal; rimz coverage --wiring prints the same grid with marks only (✓ native, ! derived, ✗ absent). A ◐ cell is derived: RimZ reconstructs the signal from other evidence.

lost means the agent's multiplexer session died under it. No agent reports that, because its hooks stop firing at the moment of death, so RimZ derives it from the rimz exec launch wrapper for every agent. Where ended is derived (Codex, Antigravity, Amp), RimZ clears the card on the next snapshot tick after the pane is gone, not at the instant the agent exits.

Codex's Interrupt hook ends the turn with an interrupted outcome. RimZ does not install Codex's SessionEnd hook, because Codex also fires it when an idle app server unloads while the pane stays open.

Per-agent mappings

Each agent's mapping doc carries its full coverage rationale, install target, resume and fork surface, and account probing, and links the upstream protocol reference. These are internals pages, written for contributors.

Agents not yet supported

An agent without an adapter runs fine in a pane, but shows as a plain process row: no card, no live state, no attention routing. A new agent gets support through one adapter over its hooks or local store (adding an agent).

Two cases stay dark even for built-in agents. Remote sessions with no local pane (a claude remote-control --spawn worktree, or a Codex thread started from the web) are tracked but not shown. An agent whose hooks you declined at the consent prompt reports nothing until you run rimz hooks install.

Third-party plugins

A process plugin connects a third-party agent through a shim that speaks RimZ's canonical event protocol. The path is under active development and not ready for outside use; what a plugin supports is declared by its bundle, not by a RimZ tier. The contract is agent plugins.

See also

• Agents: launching agents and profiles.
• Configuration: where profiles, teams, and the skill library live on disk.
• Token insight: where the live$ and spend figures surface.
• Hooks and trust: what rimz hooks install writes per agent.
• The agent model: the rollup, state machine, and adapter boundary.
• Troubleshooting: hooks not reporting.