# Platform matrix Source: https://flow-next.dev/integrations/platforms/ What each host harness runs, how it is installed, which slash form it uses, and the caveats that differ per platform. 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](https://flow-next.dev/install/). This page is the one-screen comparison. | Host | Delivery | Slash form | Review backends | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | [Claude Code](https://flow-next.dev/install/#claude-code-and-factory-droid) | Plugin marketplace | `/flow-next:` | all | | [Factory Droid](https://flow-next.dev/install/#claude-code-and-factory-droid) | Plugin marketplace (auto-translates the Claude format) | `/flow-next:` | all | | [OpenAI Codex](https://flow-next.dev/install/#openai-codex) | `install-codex.sh`, pre-built mirror | `$flow-next-` | all | | [Cursor](https://flow-next.dev/install/#cursor) | Team-marketplace repo import (recommended) or `install-cursor.sh` | `/flow-next:`, autocomplete lists `/flow-next-` | `host` (recommended from inside Cursor) + bridges | | [xAI Grok Build](https://flow-next.dev/install/#xai-grok-build) | Reads the canonical Claude plugin as-is; detected via `GROK_AGENT=1` | `/flow-next:` | `host` single-family fail-closed; cross-family via bridges | | [OpenCode](https://flow-next.dev/install/#opencode) | `install-opencode.sh` scatters into `~/.config/opencode/` | `/flow-next-` (flat) | `host` (agent-pinned) + codex | | [Muse Code](https://flow-next.dev/install/#muse-code) | `install-muse.sh` builds and approves a Muse bundle; start Muse with `--disable-sandbox` | `/flow-next:` | CLI backends (`codex` / `copilot` / `cursor` / `claude`); `host` single-family fail-closed | Unattended runs use [flow —auto and land](https://flow-next.dev/autonomy/going-autonomous/) 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](https://flow-next.dev/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](https://flow-next.dev/guides/model-routing/#reach-how-each-harness-gets-a-model). * **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](https://flow-next.dev/reference/glossary/#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](https://flow-next.dev/autonomy/land/#chains-and-stacks)). * **Two Codex homes.** A machine with more than one `CODEX_HOME` needs the installer run per home. See [Install](https://flow-next.dev/install/#more-than-one-codex-home). ## 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 ` on Claude Code). Recipes with stop conditions are on [Driving a loop](https://flow-next.dev/autonomy/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](https://flow-next.dev/understand/architecture/).