Claude, Codex, Kimi, OpenCode, Grok & Muse — What Differs
vord hosts six coding agents as first-class citizens — claude, codex, kimi (Kimi Code CLI), OpenCode, Grok, and Muse (Muse Code from Meta) — with the same cockpit, status dots, and grid. Most features reach the same result either way, but the CLIs do not expose their internals in the same way, so a handful of things differ in mechanism or are genuinely agent-specific. This page collects every one of those places, so nothing surprises you.
Grok (1.0.4): native sidebar + Grok, hooks in ~/.grok/hooks/, project MCP in .grok/config.toml, resume via grok --resume. Permission modes share Claude’s names (default / acceptEdits / plan / auto / dontAsk / bypassPermissions) and cycle with Shift+Tab. A message sent while Grok is working is steered into the running turn at the next safe gap ([ui].follow_up_behavior = "steer") — not held until the turn ends. Auth is ~/.grok/auth.json from grok login. Models live-probed: grok-4.6 (default) and grok-4.5.
Muse: native sidebar + Muse, or type muse in a shell tile. Install Muse Code from Meta (muse, typically ~/.local/bin/muse) and sign in once with muse login (Meta account, browser code) or META_API_KEY. vord detects Muse automatically; there is exactly one Muse account. Status 🟢/🟡/⚪️ comes from Muse’s hooks. The first start in a new folder shows Muse’s own trust question as a 🟡 box; child sessions that vord starts trust the folder for that run only. Permission levels are Read-only, Ask me, Auto-review, and Unrestricted — change them in the TUI with /permissions. Muse has no plan mode; Read-only is the closest counterpart. A message sent while Muse is working is queued and appears after the turn. Resume is muse resume <session> — the exact learned conversation, with history in the focus/chat view and on the iPhone. User MCP is written to ~/.config/muse/settings.json (stdio and streamable HTTP; SSE is not copied). Project MCP is the shared .mcp.json. vord mirrors the lead rules file to ~/.config/muse/AGENTS.md. Models and thinking levels (minimal through max, depending on the model) are loaded live from Muse; names such as muse-spark-1.3-contributor are examples, not a promise. Token use comes from Muse’s session records. A subscription quota is shown only when Muse reports one — otherwise it stays unknown. Muse sessions on the iPhone need a current app version; older apps show them neutrally.
All four are first-class, but not identical
Section titled “All four are first-class, but not identical”Starting a session, watching the status dot, answering a waiting box, the git inspector, browser preview, notes, show_to_user, and child-session trees work for all six agents. The differences below are specific: some are just a different route to the same result, a few are structural gaps rooted in how each CLI exposes its state — claude ships a hook system vord plugs into directly; codex’s is newer and needs a one-time trust step; kimi’s hooks are global-only, so vord manages a marked block in kimi’s own config.toml; OpenCode reports live events through its own server. Every difference is called out here and on the feature’s own page, never hidden.
Detection & hooks: codex needs a one-time trust step, kimi needs none
Section titled “Detection & hooks: codex needs a one-time trust step, kimi needs none”Status detection for all three agents is strongest through hooks (UserPromptSubmit, PreToolUse, PostToolUse, Stop, and more) — a session started without vord’s hook path falls back to an output heuristic that reads the visible terminal text instead.
For codex specifically, there’s an extra wrinkle: codex hooks only fire after you’ve confirmed “Trust all and continue” once in that project’s terminal. Until then, status detection runs on a less precise, trust-free notify channel, and the protection against a codex tile flashing “finished” mid-turn doesn’t fully apply.
vord surfaces this directly: a codex tile shows a dismissible amber banner suggesting you trust the project once. Dismissing it is remembered per project — it doesn’t fix the underlying gap, since only you (in the real terminal) can grant that trust.
For kimi there’s no equivalent hurdle. kimi has no per-project hook config, so vord keeps a managed hook block in kimi’s global ~/.kimi-code/config.toml (installed the first time you start a kimi session, removed again when vord quits — with a backup and a validation pass on every write, and everything outside vord’s marked block left byte-identical). The block calls vord’s own hook script, which reports the same loopback events claude and codex report — and it never blocks an action. Because it’s global rather than trust-gated, kimi hooks fire from the very first session, and vord’s output-based detector knows kimi’s own shapes too (the moon-phase spinner, its permission box ▶ Run this command?, its plan box ▶ Ready to build with this plan?, and its question box), so even a kimi you typed into a plain shell is recognized.
Naming: native Codex name vs. first-message fallback (or kimi’s session state)
Section titled “Naming: native Codex name vs. first-message fallback (or kimi’s session state)”Claude sets its session title via the terminal; vord takes it over directly. Codex creates a short content-based name itself after the first task and stores it in its session index. vord shows this name and follows later renames. Until Codex has created the name, a preview of the first prompt can appear. Kimi provides no usable terminal title; vord reads its title from the stored session state, usually the first prompt. A name set manually in vord takes precedence for all agents (double-click the title or right-click → Rename…).
Permission modes: Shift+Tab ring is claude-only
Section titled “Permission modes: Shift+Tab ring is claude-only”claude tracks six permission modes (Default, Accept Edits, Plan, Bypass Permissions, Auto, Don’t Ask) and cycles between them with Shift+Tab in the terminal. codex has no such ring — its approval state comes from the rollout’s turn_context (approval_policy × sandbox_policy.type, mapped to Read-only / Default / Full Access), and the only way to change it is codex’s own /permissions slash command.
kimi has its own modes (its status line shows a plan or auto prefix when one is active), but vord doesn’t derive or display a kimi permission mode — there’s no kimi mode pill on the Mac and no kimi support in the phone mode key.
OpenCode uses four explicit access presets: Read only, Ask (the default), Edits allowed, and Auto. It has no unified thinking-depth field, so vord shows no OpenCode thinking-depth control; choosing a provider-supplied model is the relevant choice.
Muse uses four permission levels of its own: Read-only, Ask me, Auto-review, and Unrestricted. There is no Shift+Tab ring and no plan mode; Read-only is the closest counterpart. Change the level in Muse’s TUI with /permissions. On the phone, the mode button sends /permissions the same way. vord starts Unrestricted without approvals and without Muse’s sandbox, so Muse does not ask before new network destinations; in Ask me and Auto-review it does, and the tile turns 🟡 while that question is open.
That difference carries through to the phone companions (Pro), but only for changing the mode: the mode button can directly cycle and confirm a claude mode, while for codex it can only send /permissions + Enter and hand you back whatever picker codex shows — no direct-select from an unknown state. Reading the mode works for both: vord derives the codex mode from the rollout’s approval × sandbox policy, so a codex session in Full Access (danger-full-access) shows the same red warning glyph on the phone that claude’s risky modes do.
See Permission Modes for the full mode reference.
Plan mode & auto-approval: claude only
Section titled “Plan mode & auto-approval: claude only”claude has a dedicated Plan mode with its own confirmation box (ExitPlanMode) — and vord’s auto-pilot can auto-approve just that box type, nothing else, as a security-scoped rule. codex has no equivalent plan-mode concept: it doesn’t produce an ExitPlanMode state, so the plan auto-approval rule simply never triggers for codex sessions. This isn’t a bug to fix — codex’s CLI doesn’t generate the state vord would need to react to.
kimi does have a plan flow — it renders a ▶ Ready to build with this plan? box, and vord recognizes it and flips the tile to 🟡 like any other waiting box. But the auto-approval rule stays claude-only: there’s no auto-approve path wired for kimi boxes, so a kimi plan always waits for your answer.
Sending input while the agent is working: kimi steers with Ctrl+S
Section titled “Sending input while the agent is working: kimi steers with Ctrl+S”While a turn is running, claude and codex accept a submitted message and work it in after the current step. kimi’s TUI is different: Enter does not submit right away during a running turn — a pasted message is queued until the turn ends, and typed text isn’t submitted at all (it just becomes a newline in the input box). kimi’s own way to inject a message into the running turn is Ctrl+S — its footer literally says “ctrl-s to steer immediately”.
vord handles this for you, so you never have to think about the key:
- Typing into a working kimi tile and pressing Enter sends kimi’s steer key under the hood — your message reaches the agent immediately instead of waiting out its turn. When kimi is idle, Enter is plain Enter again.
- Everything vord delivers on its own — mesh messages, a parent agent’s
send_to_agent, text from your phone, automatic continuation after a usage limit (except Kimi) — uses the same state-aware logic: Enter when kimi is idle, an immediate steer when it’s working, always with the full message content (vord types the text rather than pasting it in that case, because kimi folds long pastes into a[paste #N …]placeholder that its steer path would forward literally). - The two keys are not interchangeable, so vord always errs toward Enter. Measurements against kimi 0.29.2 show the steer key does nothing at all in a session with no running turn — the text just sits in the input box. Enter is the safe one: it submits whenever no turn is running, and merely queues the message until the turn ends when one is. So if the tile flips between working and idle at the moment a message goes out, an Enter costs at most a little delay, never the message.
- vord decides from the turn itself, not from the tile colour — and a turn that dies on the provider’s side (a rate limit, an auth error) counts as ended, even though kimi’s own session record never notes that it stopped. Without that, one failed turn would leave the session steering into the void for good.
Muse queues a follow-up sent during a running turn and works it in afterwards. There is no steer-into-the-turn path like kimi’s Ctrl+S or Grok’s follow-up behavior.
Answer boxes (permission, plan, question) are unaffected — Enter still confirms the selected option there, for all three agents.
Usage limits: provider facts over guesses
Section titled “Usage limits: provider facts over guesses”vord detects a visible “usage limit reached” message in the terminal and shows a dedicated ⏳ status with a reset countdown, plus optional auto-continue. This runs for all three terminal agents: every entry path (the 1-click start, resume, and typing claude, codex, or kimi into a shell) feeds terminal output through the same monitor, and the parser recognizes each agent’s own limit wording. vord also reads the limit from each agent’s own records — Claude’s conversation log, Codex’s rollout file, and Kimi’s wire log — so a limit is recognized even when it never shows on screen.
The one honest difference is the reset time, not coverage: claude usually prints it, codex does in its current “try again at …” wording, and kimi never does. When the message names no time, vord takes the reset from the account’s quota data if it shows a used-up window (for Kimi’s 5-hour window: that window’s reset). Without such data the reset is unknown — shown as “reset unknown”, never as an estimated clock. For supported agents, Auto-Continue can wait for the reset or a configured fallback delay; Kimi shows its limit and is continued manually.
Muse usage limits are detected from the session (on screen and through Muse’s own hooks). Token consumption is read from Muse’s session records. Muse reports its subscription quota (the 5-hour window and the week) only after a request, so vord measures it with a tiny request of its own: at most every 30 minutes and only while a Muse session is running. Until the first measurement the quota stays unknown; vord never treats a missing Muse quota as free.
See Usage Limits & Auto-Continue for how the feature works.
Child sessions: the same vord tree for all six agents
Section titled “Child sessions: the same vord tree for all six agents”The child-session/team/workflow tree (AgentHierarchyView) and the “✦ done/total” badge render for all six agents — including nested children, where one child spawns its own. The badge counts real agents on all sides (it excludes raw tool calls). What differs is the plumbing underneath, not the result:
- claude reports its subagents inline in the one main transcript.
- codex writes a separate rollout file per subagent, which vord discovers and tails live, chaining them recursively by parent. One structural consequence: codex subagent discovery is time-windowed from when the session started, so a subagent that somehow predates the scan window wouldn’t be found retroactively — in practice subagents are always spawned after the session is already running, so you won’t hit this.
- kimi records its agent hierarchy directly in its session state (
state.json): every agent carries a type (main/sub) and its parent’s ID, so vord reads the tree — nesting included — straight from kimi’s own bookkeeping, with each subagent’s tool activity coming from its per-agent wire log. - Grok writes each
spawn_subagenttosubagents/<id>/meta.json(type, description, status, model). vord reads that folder for the same tree and counter. - OpenCode child sessions use the same visible parent/child relationship and reporting flow as the other agents.
- Muse children that vord starts trust the folder for that run only. A Muse session you start yourself in a new folder still shows Muse’s own trust question as a 🟡 box.
See Subagents & Hierarchy for how the tree itself works.
show_to_user works for all six
Section titled “show_to_user works for all six”The show_to_user MCP tool — the agent pushing an image or a web page straight to your screen (and to your phone) — reaches full parity. vord bundles its own vord-mcp server into every session, including OpenCode and Muse. Same tool, same Mac preview panel, same phone live view, same “Shown to you” archive, any agent.
See Showing Things to You for what the feature does.
Phone companions: mostly the same, with mechanism differences
Section titled “Phone companions: mostly the same, with mechanism differences”The phone companions (Pro) work for codex, kimi, OpenCode, Grok, and Muse sessions — view the terminal, send input, use control keys, receive notifications, answer questions, browse show_to_user media. You can also start a new session from the phone; each option only appears when the Mac announces that capability. Muse sessions appear only with a current app version; an older companion shows them neutrally. OpenCode’s models are dynamic, it exposes the four access presets Read only, Ask, Edits allowed, and Auto, and it has no thinking-depth control. Muse’s models and thinking levels come from Muse live; its mode button sends /permissions. A few answer mechanisms reach the same result through a different codex-native path, and one is genuinely claude-only:
- Direct mode change (claude only). The mode button can cycle and confirm a claude mode in place; for codex it can only fire
/permissionsand hand you codex’s own picker — there’s no direct-select ring for codex, and no kimi mode support at all. (Reading the mode, including the Full Access red warning, works for codex — see the permission-modes section above.) - Multi-question stepper (works, no Submit tab). claude’s multi-part
AskUserQuestiongets a “Question X of N” tab bar with a Submit tab at the end. vord synthesizes the same tab bar for codex from its “Question 2/3” header, so the stepper is there — but codex submits each question with Enter and auto-advances rather than offering a separate Submit tab. - Free-text answer in a question box (works, different field). claude delivers typed text through its numbered “Type something…” option. codex has no such option, so vord routes free text into codex’s own notes field instead (opened with Tab, per
request_user_input). Both land as a real answer to the active question — the field it opens just differs.
None of this blocks remote control of a codex session — sending a prompt, tapping control keys, single-question answer cards, and show_to_user all work the same for claude and codex. Only the direct mode change is claude-exclusive; the rest just take a codex-shaped route to the same place.
See Controlling Sessions from Your iPhone or Controlling Sessions from Android for the full companion feature set.
Instruction files: CLAUDE.md vs. AGENTS.md — one lead file for all six
Section titled “Instruction files: CLAUDE.md vs. AGENTS.md — one lead file for all six”The CLIs read their startup instructions from different files. claude reads CLAUDE.md; codex, kimi, OpenCode, and Grok all read AGENTS.md — at project level they even read the same <project>/AGENTS.md, so there’s only one file to maintain there per project, not four. Globally, each of those five has its own file. Muse does not read ~/.claude/CLAUDE.md on its own: vord mirrors the lead rules file to ~/.config/muse/AGENTS.md.
| Agent | Global instruction file |
|---|---|
| claude | ~/.claude/CLAUDE.md |
| codex | ~/.codex/AGENTS.md |
| kimi | ~/.kimi-code/AGENTS.md (or $KIMI_CODE_HOME/AGENTS.md) |
| OpenCode | ~/.config/opencode/AGENTS.md (or $XDG_CONFIG_HOME/opencode/AGENTS.md) |
| Grok | ~/.grok/AGENTS.md (or $GROK_HOME/AGENTS.md) |
| Muse | ~/.config/muse/AGENTS.md (mirrored from the lead file) |
vord’s Rules files settings pane edits all of these and offers two ways out of maintaining several sets of instructions by hand — both off by default, since not everyone uses all six agents:
- Merge for the agent. Your files stay untouched. At the start of a session vord hands each agent the rules from every other agent’s file as hidden context — at project level that’s the one shared
AGENTS.md; globally each tool’s own file is read separately. Sections that already appear word-for-word in the agent’s own file are left out. Every agent ends up knowing the others’ rules, and nothing is ever overwritten. One switch under All projects turns this on for every project at once. - Keep files identical, per project — the classic copy sync: one save writes both files of that project together. If they’ve drifted apart you have to pick a winner and the other file is overwritten.
- Align, globally or per project — pick one lead file (
CLAUDE.mdorAGENTS.md). Missing followers are created only after you confirm. Different existing files are overwritten only after you confirm a conflict, with a backup. Later follower drift stops as a conflict instead of being written back. A symlink that resolves to the lead file, or to another file with the same bytes, counts as in sync and is left in place. Different bytes stay a conflict for that assistant only, naming the link target. A symlink is never written. App start, session start, and Align now do not bypass that. See Align (lead file). Kimi, OpenCode, Grok, and Muse are in this group like Codex. All projects does not offer Align.
One codex-specific limit worth knowing about here too: codex only reads up to 32 KiB of a project-level AGENTS.md by default and silently cuts off the rest. The settings pane warns you once a file crosses that size; claude has no equivalent cap on CLAUDE.md.
Summary table
Section titled “Summary table”| Feature | claude | codex | kimi |
|---|---|---|---|
| Status detection (hooks) | Full hook coverage | Works, but needs a one-time “Trust all and continue” before hooks fire fully | Full — vord’s managed block in kimi’s global config.toml, no trust step |
| Session auto-naming | From OSC terminal title | Content-based title created by Codex; until then the existing Codex name or base title | From kimi’s session state (title / first prompt) |
| Permission mode ring (Shift+Tab) | Yes, 6 modes | No — only codex’s own /permissions picker |
No tracking in vord — kimi shows its own plan/auto prefix |
| Phone mode warning color | Yes, for risky modes | Yes — Full Access (danger-full-access) shows the red warning |
No kimi mode display |
| Phone direct mode change | Yes — cycle & confirm in place | No — only fires /permissions and returns codex’s picker |
No |
| Plan mode + auto-approval | Yes (ExitPlanMode) |
No plan-mode concept at all | Plan box recognized (🟡), but auto-approval stays claude-only |
| Message to a working session | Queued by the agent, worked in | Queued by the agent, worked in | Immediate — kimi gets Ctrl+S; hosted Grok sets follow_up_behavior=steer so Enter injects into the running turn |
| Usage-limit detection (⏳) + auto-continue | Yes | Yes — without a stated time the reset comes from quota data or stays unknown (next attempt after a fallback delay, default 5 h) | Limit shown; continue manually |
| Subagent/team tree | Full, inline | Full, via per-rollout tailing (nested depth ≥ 2 included; badge counts real agents, not tool calls) | Full, from kimi’s own session-state hierarchy (nesting included) |
show_to_user (image/URL push) |
Yes | Yes | Yes |
| Phone multi-question stepper | Yes, with a Submit tab | Yes, synthesized — but per-question Enter, no Submit tab | New — generic answer-card path |
| Phone free-text answer in a question box | Yes, via the “Type something” option | Yes, via codex’s notes field (Tab to open) | New — generic answer-card path |
| Phone single-question answer cards, control keys, compose | Yes | Yes | Yes — box-answer choreography is new; approvals at the Mac are solid |
| Phone portrait conversation view | Yes — from claude’s .jsonl transcript |
Yes — from the codex rollout | Yes — from kimi’s agents/main/wire.jsonl; thinking left out on purpose, swarm workers stay in the hierarchy |
| Startup instruction file | CLAUDE.md |
AGENTS.md — capped at 32 KiB per project doc by default |
Project AGENTS.md (shared with codex); global ~/.kimi-code/AGENTS.md |
| Getting the other agents’ rules | Merge; project copy sync; global lead-file auto-align | Merge; project copy sync; global lead-file auto-align | Merge; project copy sync; global lead-file auto-align |
OpenCode at a glance
Section titled “OpenCode at a glance”OpenCode sessions use the same cockpit, phone start gate, MCP tools, and visible child-session tree. Their models are supplied dynamically by the signed-in OpenCode installation, not a fixed vord catalog. Read only, Ask, Edits allowed, and Auto are its four access presets. There is no OpenCode thinking depth. Provider-reported limits are shown, with a reset time only when the provider sends one; automatic continuation requires that reliable time or an explicit retry allowance.
Muse at a glance
Section titled “Muse at a glance”Muse sessions use the same cockpit, status dots, MCP tools, and visible child-session tree. Install Muse Code, sign in once, and start with + Muse or by typing muse. Permission levels are Read-only, Ask me, Auto-review, and Unrestricted; there is no plan mode. Follow-ups during a turn are queued. Models and thinking levels come from Muse live. Quota is shown only when Muse reports it. The iPhone companion needs a current app version.
None of this is a reason to avoid codex or kimi in vord — the core cockpit experience (grid, status, terminal, git, browser, notes) is the same either way, and most agent features reach parity. The genuine claude-only edges are narrow: the hook-trust head start codex needs, plan-mode auto-approval, and direct mode changes from the phone. kimi’s current gaps are the missing usage-limit detection and the newness of its phone answer path. Everything else is either identical or a per-agent-shaped route to the same result.