Platform matrix

Flow-Next is first-class on Claude Code, OpenAI Codex, Factory Droid, Cursor, xAI Grok Build, OpenCode, and Meta Muse Code. First-class means the canonical plugin files are consumed (as-is, through the generated mirror, or through an installer), skills and slash commands run, multi-agent flows are verified, and setup detects the host.

Full install commands, update paths, and org-wide deployment are on Install. This page is the one-screen comparison.

Host	Delivery	Slash form	Review backends
Claude Code	Plugin marketplace	`/flow-next:<name>`	all
Factory Droid	Plugin marketplace (auto-translates the Claude format)	`/flow-next:<name>`	all
OpenAI Codex	`install-codex.sh`, pre-built mirror	`$flow-next-<name>`	all
Cursor	Team-marketplace repo import (recommended) or `install-cursor.sh`	`/flow-next:<name>`, autocomplete lists `/flow-next-<name>`	`host` (recommended from inside Cursor) + bridges
xAI Grok Build	Reads the canonical Claude plugin as-is; detected via `GROK_AGENT=1`	`/flow-next:<name>`	`host` single-family fail-closed; cross-family via bridges
OpenCode	`install-opencode.sh` scatters into `~/.config/opencode/`	`/flow-next-<name>` (flat)	`host` (agent-pinned) + codex
Muse Code	`install-muse.sh` builds and approves a Muse bundle; start Muse with `--disable-sandbox`	`/flow-next:<name>`	CLI backends (`codex` / `copilot` / `cursor` / `claude`); `host` single-family fail-closed

Unattended runs use flow —auto and land on every host.

What differs in practice

Where flowctl comes from. Every host resolves it from the plugin install, never from a copy in your repo. Claude Code and Droid use their plugin-root env vars; Muse Code substitutes ${CLAUDE_PLUGIN_ROOT} in skill text; Cursor, Grok, and OpenCode derive the plugin root from the skill file’s own path; Codex uses ${CODEX_HOME:-$HOME/.codex}/scripts/. Every skill runs the plugin’s scripts/flowctl by that resolved path. A bare flowctl is not on PATH on any host, Claude Code included, since 7.1.0 removed the plugin’s top-level bin/; outside a skill, run it by path (Install: optional CLI access).
Which instruction file setup writes. Lifecycle docs default to CLAUDE.md, model routing to AGENTS.md, and hosts that read both get both. Muse Code reads only the first of the two, AGENTS.md first, so setup writes there; a repo set up under Claude Code needs Both at the docs question or one setup run in Muse.
Subagent model pins. An agent definition’s model: field is honored on Claude Code, Droid, and Grok; ignored on Cursor (subagents inherit the session model); best-effort on Codex. The full reach table is in Model routing.
Search and web tools. Scouts search with whatever read-only tools their host gives them. Native Claude Code on macOS and Linux has no Grep or Glob tool since 2.1.117 and searches through Bash; Windows and npm installs keep both. Codex subagents have only a shell, in a read-only sandbox without network, so github-scout falls back to Codex’s web search there and says private repositories were not searched. The claude review backend names its three tools explicitly and is unaffected.
Blocking questions. Claude Code and Droid use the native structured ask; the Codex mirror rewrites those into plain numbered prompts; Cursor asks natively.
Stack linking is GitHub-only. A dependent spec’s PR is opened against its parent’s branch on every host (a chain); linking it into a GitHub stack, and land’s stack merge, run only when the remote is GitHub. Elsewhere the PR stands as a plain chain layer and a child still based on a merged parent needs a manual rebase onto the intended base before its own landing (land).
Two Codex homes. A machine with more than one CODEX_HOME needs the installer run per home. See Install.

Running unattended per host

The default recipe is the same on every host: one /flow-next:flow --auto invocation per ready item. It hops from the item’s current stage to a PR and stops, and the next invocation takes the next item. --tick runs exactly one hop and stops, which is the shape for a host loop primitive that schedules short sessions. The /flow-next:pilot command was removed in 6.1.0; a loop recipe that still names it should call flow --auto --tick. Every shape ends with one PILOT_VERDICT line, and the ship loop takes one named pull request (/loop 15m /flow-next:land <PR> on Claude Code). Recipes with stop conditions are on Driving a loop.

Host	Long-horizon (default)	One hop per interval
Claude Code	`/flow-next:flow --auto`	`/loop 30m /flow-next:flow --auto --tick` (`/loop` v2.1.72+, loops expire after 7 days) or `/goal keep running /flow-next:flow --auto --tick until it prints PILOT_VERDICT=NO_WORK, or stop after 20 turns` (`/goal` v2.1.139+, transcript-blind validators)
OpenAI Codex	`$flow-next-flow --auto` in a session	`/goal` is opt-in (`[features] goals = true`, CLI >= 0.128.0) with a plain-text objective that names `flow --auto --tick` and the `PILOT_VERDICT` grammar
Factory Droid, Cursor, xAI Grok Build, Muse Code	`/flow-next:flow --auto`, run again for the next item	`/flow-next:flow --auto --tick` under whatever cadence primitive the host offers
OpenCode	`/flow-next-flow --auto` (flat form), run again for the next item	`/flow-next-flow --auto --tick` under whatever cadence primitive the host offers

What does not differ

The pipeline, the gates, the receipts, and the spec format are identical everywhere. A repo set up on one host works unchanged on another, because everything Flow-Next writes lives in .flow/ and the intelligence is whichever host agent is running. That is the whole point of the skills-own-judgment split.