Multi-model orchestration for Claude Code. Your chosen Claude session model is the control plane and final judge; Claude workers cover native tool, privacy, and read only reasoning needs; peer engine CLIs provide external implementation, research, and review lanes billed to their own subscriptions. Today those peers are Codex and Grok through first party companion plugins hosted in this marketplace; the companion contract is engine agnostic so more lanes can fit the same shape. The Codex plugin invokes the official CLI directly and has no dependency on codex-plugin-cc. The orchestrator and Claude worker tiers still bill to your Claude plan; delegation moves eligible execution off it. The plugin audits but never sets the session model.
| Layer | Who | Job |
|---|---|---|
| Orchestrator | the user's chosen main session model; best[1m] is recommended but never set by the plugin |
sole control plane: resolve ambiguity, decompose, integrate, verify, record semantic acceptance, make the final judgment, and communicate with the user; it does not execute work packages |
| Claude workers | fusion:deep-reasoner (Fable), fusion:fast-worker (Sonnet), fusion:trivial-worker (Haiku) |
native specialists rather than external diversity: read only high stakes advice, resolved work needing Claude Code tools or the Claude privacy boundary, and exact tiny fallback packages when no eligible peer lane fits |
| Peer engines | Companion plugins implementing the shared contract. Current instances are the hosted Codex and Grok plugins in this marketplace | Codex is the primary implementation lane and default deep external reviewer. Grok is a complementary specialist and burst lane with five protected roles: burst, independence, live-web, large-context, and best-of-n. It remains implementation capable inside those roles, but idle capacity alone does not make it the ordinary default. Each lane runs whatever its own CLI is configured for; model names and scores live in the /fusion:config capability table, refreshed from each CLI's live listing. |
| Panel mechanism | /fusion:panel |
sends one blind brief to available peer engines in parallel and gives their attributed evidence to the main Claude session for final adjudication; it is not an independent role or authority |
Codex first admission follows this order: use Codex in the current workspace, then an isolated Codex worktree for an independent eligible package, then Grok under burst for an independent package inside its safety and turn boundaries, then the matching Claude fallback. Overlapping files, shared generated state, and ordering dependencies are consolidated or sequenced instead of parallelized by changing engines.
Direct /codex:* and /grok:* commands are user selected engine escape hatches. They return the selected engine's transport result directly and do not first pass through Fusion's automatic routing or main session adjudication.
Prerequisites: Claude Code 2.1.198 or later and Node.js 22 or later (tested on Claude Code 2.1.211 and Node 22; the floors are not enforced), git, macOS or Linux, and both peer CLIs installed and authenticated on PATH. Verify them with codex --version and grok --version. Claude workers and peer wrapper Agents use foreground delivery by default. The main Claude session remains the control plane and must collect or explicitly cancel any Agent that the runtime still launches asynchronously. Without one peer, Fusion still runs and routes eligible work to the remaining lanes.
If codex@openai-codex is installed, migrate before installing this marketplace's Codex plugin. In a session where the old plugin is still enabled, run /codex:status --all, use the old /codex:result <job-id> --wait or /codex:cancel <job-id> for every authoritative running job, confirm that no result you need remains uncollected, then exit that session. Disable and uninstall the old plugin while preserving its data:
claude plugin disable codex@openai-codex
claude plugin uninstall codex@openai-codex --keep-dataNever enable codex@openai-codex and codex@claude-code-fusion together because both register the same codex namespace. The preserved old state is ignored by Fusion stats and the breaker by default, so new reports cannot silently mix pre-migration activity with current data. /fusion:stats --include-legacy or FUSION_CODEX_INCLUDE_LEGACY=1 enables explicit read only compatibility analysis without copying or modifying old records. Open a new session after the replacement is installed.
claude plugin marketplace add okisdev/claude-code-fusion
claude plugin install codex@claude-code-fusion
claude plugin install grok@claude-code-fusion
claude plugin install fusion@claude-code-fusionThen, in a new session, run /fusion:setup once per machine (it writes the routing rules into ~/.claude/rules/, where every later session loads them automatically), /codex:setup once to verify Codex, and /grok:setup once to verify Grok. The tier agents ship inside the fusion plugin, so nothing else needs copying. After that, a SessionStart hook applies rules updates from later plugin upgrades automatically at the next session start, as long as the live copy still matches a version the plugin has shipped; re-run /fusion:setup only if you hand edited ~/.claude/rules/orchestration.md, which the hook and /fusion:doctor both flag as drift. From there plain language is enough: ask for "a second opinion from Grok" or "hand this to Codex" and the routing rules make the orchestrator delegate on its own.
| Command | What it does |
|---|---|
/codex:task <text>, /codex:rescue <text> |
Delegate to Codex. Runs stay foreground regardless of complexity, expected duration, or model unless the incoming request explicitly passes --background; --write allows edits, --resume <thread-id> or --resume-last continues a thread, --fresh forces a new one, --web enables live search, --write --network enables workspace network access, and --model or --effort forwards an explicit override. A direct background invocation returns a receipt without automatically collecting it |
| `/codex:review [--scope <auto | working-tree |
/codex:status [job-id], /codex:result <job-id> --wait, /codex:cancel <job-id> |
Lifecycle for explicitly detached Codex jobs. Status inspects progress, result collects the deliverable, and Fusion's optional monitor can notify completion. Fusion gives jobs detached by its own orchestration one same turn collection attempt of at most 540000ms; a timeout remains explicitly uncollected |
/codex:history [--json] |
List canonical local Codex companion jobs across workspaces, including resumable thread ids, delivery state, semantic status, and observed model and effort. Codex exec threads remain persisted locally, but Codex Desktop does not guarantee that exec sourced threads appear in its sidebar |
/codex:setup |
Codex CLI, authentication, adapter path, and compatibility health check |
/grok:task <text> |
Delegate directly to the user selected Grok lane. Consult, --write, and --best-of-n all use the strict sandbox; --write allows edits through its fixed tool policy, --web enables web search and fetch, and explicit --background returns a manual receipt for /grok:status and /grok:result. Without that flag, the Agent and companion stay foreground regardless of expected duration; a typed timeout is split or rerouted instead of being silently detached. Cross-session memory is off by default and can be enabled for an ordinary task with --memory; --resume <uuid> or --resume-last continues only a compatible companion-recorded strict task with the same mode and memory boundary; --fresh bypasses continuity and starts a new session. --model, --effort, and --max-turns forward explicit overrides. --best-of-n always starts fresh, keeps memory off, and runs a tournament on the same brief. |
/grok:review [--base <ref>] [--focus <text>] [--cwd <dir>] [--json] |
Read only adversarial review of the working tree or a branch range (untracked files reach the review as names only); the review run never edits, and acting on confirmed findings is a separate orchestrator decision after it returns |
/grok:best-of-n [--n <n>] <task> |
Implementation tournament in isolated worktrees; the winning candidate is applied. Keep n at 2; the companion rejects values outside 2 to 10 |
/grok:status [job-id], /grok:result <job-id> [--wait], /grok:cancel <job-id> |
Background job lifecycle. Each accepts --cwd <dir> and --json; a successful JSON background launch preserves its task or review envelope through result collection, while cancellation, process death, and other failures return a stable typed failure envelope |
/grok:history [--all] [--limit <n>] [--cwd <dir>] [--json] |
List canonical local Grok companion jobs and resumable session identifiers. The default scope is the current workspace and 50 newest records; --all spans recorded workspaces and --limit accepts 1 to 500. The command exposes safe metadata, not native Grok conversation contents, briefs, results, or logs |
/grok:stats [--all] |
Grok delegation history by status, mode, model, failure kind, and exact reported token totals with complete, incomplete, and unreported coverage |
/fusion:stats [--all] |
Delegation history across Claude workers and peer engines, including stable task identity, Agent identity, delivery state, transport status, semantic acceptance, actual model and effort when observable, and exact reported token coverage. Current Codex state is canonical by default; add --include-legacy only for an explicit migration comparison. --audit [--days <n>] summarizes the retained inline guard ledger |
/grok:setup |
Health check; --continuity manual keeps explicit resume as the default, while --continuity claude-session enables automatic affinity for compatible ordinary direct tasks in the same Claude session and exact resolved working directory. Fusion routed briefs do not receive automatic affinity and stay fresh unless explicitly resumed. --enable-stop-gate / --disable-stop-gate toggles the stop-time review gate |
/fusion:panel <question> |
Blind multi-model panel with attributed adjudication, for decisions where a wrong answer is expensive. Also fires from plain language ("help me decide", "compare these") |
/fusion:ultra <task> |
Fans a large task out as a fleet while preserving lane ownership: Codex keeps the primary deep implementation seat and Grok supplies protected burst, research, large context, and independent breadth. It synthesizes and verifies the combined result, fires from "go deep", "audit everything", or "be exhaustive", and returns small tasks to ordinary routing. |
/fusion:setup |
Install or update the routing rules into ~/.claude/rules/; offers the optional permission allow |
/fusion:config |
Read the local model configuration across engines, enumerate available models, and change defaults interactively |
/fusion:doctor |
Audit model pins, environment overrides, peer model defaults (Grok and Codex config keys), rules drift, and stale agent copies |
Companion text outcomes use the shared footer grammar for state, failure, job, delivery, semantic, and <engine>-session lines defined in docs/companion-contract.md, with delivery and semantic lines present when that adapter exposes those dimensions in text. The Codex runtime contract is docs/codex-contract.md, and the Grok runtime contract is docs/grok-contract.md. Each plugin names its own session line, for example Codex emits codex-session: <thread-id> and Grok emits grok-session: <uuid>.
Every peer state: done and Claude worker transportStatus: done is a transport result, not proof that the work is acceptable; the main session verifies the result before relying on it. The orchestrator records Codex acceptance through /fusion:stats --record-acceptance <job-id> <accepted|rejected> --source main-loop. Claude workers and Grok jobs collected through Fusion record acceptance through /fusion:stats --record-worker-acceptance <fusion-task-id> <accepted|rejected> --source main-loop. Terminal work without that evidence remains unverified. A collector timeout, dead job, or status error reports the Fusion task id, peer job id, literal state uncollected, and the exact /codex:result <job-id> or /grok:result <job-id> command. Optional --reason text is caller supplied and retained in private local state after limited credential shape redaction, so keep it short and free of sensitive data.
Two layers with different strength, stated plainly.
Enforced by companion runtimes (code, covered by the test suite): the Codex companion invokes codex exec --json, uses the read-only or workspace-write sandbox with approval_policy="never", disables both Codex multi-agent feature generations, fails closed if a collaboration tool call is still observed, forces web search and workspace-write network access off by default, supervises the owned process group, and permits detachment only through an explicit --background already present in the incoming request. A tool that deliberately creates a new session or daemonizes leaves that portable containment boundary. --web opts into live search, while network access requires the separate --write --network combination. Fusion monitor and ordinary stats observation paths never signal recorded PIDs or repair canonical Codex records; the explicit stats prune command remains user-authorized cleanup. The Codex adapter does not impose a companion-owned shell command allow list and does not rewrite configured MCP servers or other Codex tools; those remain part of the user's Codex configuration trust boundary. Its exact runtime and durability rules are in docs/codex-contract.md.
Grok consult, write, review, and best-of-n all pin --sandbox strict. Consult overrides inherited approval bypass with --permission-mode default and hard filters built in tools to file read, list, and search, optionally adding web search and fetch. Every mode denies native questions, delegated search and tool execution, and MCP. Upstream parses --no-subagents, but the single-turn and agent resolvers do not forward it, while the interactive TUI does apply it; the hard Agent tool deny and GROK_SUBAGENTS=0 are the effective headless controls. Write and best-of-n auto approve a fixed list containing read, grep, list, search_replace, and terminal tools; search_replace creates files, and no nonexistent write tool id is requested. Strict does not confine reads to the workspace or Grok home; its broader system_read roots are described below, and user toolchains outside those readable roots may still be unavailable. Its configuration requests child process network restriction. Linux enforces that request through seccomp, while macOS network blocking is currently a no-op and a write shell can still reach the network; --web controls only Grok's built in web tools. The companion never silently downgrades to workspace.
Before the companion sends a prompt, it requires a new ProfileApplied event from the shared sandbox-events.jsonl that contains this run's unique private TMPDIR and matches the canonical workspace, strict profile, enforced state, and requested restrict_network: true configuration; the event proves that the profile and configuration were applied, not that the platform actually blocked every network path. Upstream records have no run id or pid, so unrelated ProfileApplied and ApplyFailed events are not attributed to this run and failure events are auxiliary diagnostics only. A matching warning on the owned stderr stream, handshake timeout, missing or malformed matching evidence, shared-log rotation or disappearance, and matching field mismatches fail closed. Forced builder tracing starts only after Grok consumes stdin, so it is not a pre-prompt or pre-side-effect attestation. Fallback or unmatched warnings trigger early termination, and a nominally successful close is rejected without positive allowlist applied evidence.
The child sets all eighteen GROK_CLAUDE_*_ENABLED, GROK_CURSOR_*_ENABLED, and GROK_CODEX_*_ENABLED bridge variables to false; upstream currently consumes the six Claude and six Cursor cells plus the Codex sessions cell and reserves the other five Codex cells, and the child also pins GROK_MANAGED_MCPS_ENABLED=false because that variable has highest precedence over [managed_mcps] in ~/.grok/config.toml and remote settings. It disables subagents outside best-of-n, removes inherited Claude session and plugin variables plus _GROK_CLAUDE_MARKER_OVERRIDE, scrubs unrelated secret-bearing variables while preserving required xAI authentication, and disables automatic updates with --no-auto-update. Cross-session memory is force-disabled for every run except an ordinary task with explicit --memory; review, stop gate, and best-of-n always keep it off. When enabled, upstream may inject relevant Grok memory into the model context sent to xAI. Upstream automatic saving usually requires at least three real user prompts in the same resumed session, so one Fusion task usually only reads existing memory and does not guarantee that new memory is saved. The write tool and deny rules reduce exposure but are not complete confinement. Command-pattern denies for common direct grok, claude, and codex calls can be bypassed with absolute paths, aliases or functions, and indirect scripts; a hard boundary requires removing run_terminal_cmd or applying an OS-level executable or network policy. Run write delegations on a clean branch or an orchestrator-created disposable worktree and launch Grok with that worktree as its actual cwd. Best-of-n alone adds native Agent, always starts fresh, and keeps memory off, with its background wait bounded below the companion deadline. Prompts reach headless Grok through /dev/stdin, and stdout is parsed from a 0600 file that is unlinked immediately after open. The capability preflight checks the universal safety flags and the exact consult, write, review, no-web, ordinary-wait, and tournament surfaces before each applicable run; /grok:setup reports the complete surface. Upstream minimum-version enforcement can still force an update and remains a residual boundary. --web deliberately uses Grok's built in network tools and may transmit inspected content to xAI. Continuity defaults to manual; optional claude-session affinity applies only to compatible ordinary direct tasks. Fusion routed briefs do not receive automatic affinity and stay fresh unless explicitly resumed. The optional stop gate runs from the Stop hook, not SessionEnd, and parses its first nonempty reply line: ALLOW allows the stop, while BLOCK: <reason> blocks it. A BLOCK after a preamble and every infrastructure failure fail open. SessionEnd attempts verified process cleanup and removes unused raw transports, but it does not delete the terminal companion ledger. Grok permission matcher notes are in docs/grok-contract.md, and the shared outcome rules are in docs/companion-contract.md.
Upstream strict has broader read and write surfaces than the workspace and adapter-private run directory. Linux system_read includes /var and /tmp; macOS includes /private and the entire ~/Library, so shared temporary content and substantial user application configuration and caches may be readable. Strict always permits writes to /tmp and /var/tmp; macOS also permits /private/tmp, /private/var/tmp, and all of /private/var/folders. The entire Grok home is read-write. The sandbox permits consult read_file to reach ~/.grok/auth.json, config, and sessions, and write terminal commands can receive preserved xAI authentication variables. The companion adds best-effort Read denies for auth.json, mcp_credentials.json, config.toml, sessions, memory, logs, and debug under the Grok home through absolute paths and standard **/.grok patterns, but raw path variants, symbolic links, and shell or indirect scripts can bypass those tool-level rules. Those Read denies govern model tool calls only. They do not block upstream's internal first-turn memory search and injection when the user explicitly supplies --memory. Environment scrubbing and path-pattern denies do not isolate credentials or memory content. Model-facing MCP and meta-tool denies do not prove that native MCP servers, plugins, or hooks configured under ~/.grok did not start during agent construction or had no side effects; those bridge variables do not disable native Grok configuration. Narrower exposure requires a dedicated sandbox profile, an isolated Grok home, an authentication broker, or upstream path-level authorization.
Fusion's worker lifecycle hook enforces the compact fusion-brief: v1 envelope, rejects unauthorized explicit background dispatch, owns stable task and Agent identities, observes bounded usage and progress, and blocks Stop until an unexpectedly asynchronous worker is collected or cancelled. The hook cannot prevent Claude Code itself from choosing an asynchronous internal launch when run_in_background is omitted, so it treats that launch as owned unfinished work rather than as a completed delivery. Semantic acceptance still requires main session verification.
Requested by prompts (the orchestrator follows the installed instructions; not runtime enforced): the routing policy, the panel's blindness, read only review runs never applying fixes, separate orchestrator decisions about confirmed findings after review returns, and quality driven lane selection. The circuit breaker is runtime backed by canonical job and worker evidence. Immediate infrastructure failures stop routing to the affected lane, while timeout, stall, and process failures require repetition before opening the breaker. Ordinary read only permission mismatch does not globally break an engine. Each engine can define its own unavailable prefix; the one present today is grok unavailable:. /fusion:panel substitutes fusion:deep-reasoner for a missing track rather than aborting.
Roles bind to alias tiers, not to specific models, so a same tier release (Sonnet 5 under sonnet, a future Opus) needs zero configuration, and best[1m] floats the orchestrator to future Fable releases or degrades it to the latest Opus when Fable is unavailable. The one deliberate exception is fusion:trivial-worker, pinned to the full ID claude-haiku-4-5 for machines where ANTHROPIC_DEFAULT_HAIKU_MODEL remaps the haiku alias; bump it by hand when a newer cheap tier ships. It is a fallback for trivial work when no eligible peer lane remains, or when Claude-only tools or privacy are required, not the default for single file tasks. Peer engine defaults live in each CLI's config (~/.grok/config.toml, ~/.codex/config.toml); /fusion:config reads and changes them interactively. Alias semantics are Claude Code behavior as observed on 2.1.x, and nothing here sets your main model for you: pick it yourself, for example /model best. /fusion:doctor audits all of this.
The plugin's effectiveness claims are benchmarked, not asserted. The claims and the full protocol live in bench/METHODOLOGY.md: C1 quota displacement (routing bills fewer tokens to the Claude subscription than a vanilla session at equal task success, split into a Claude tiers only arm, a peer offload arm, and an advisor profile arm where the main session runs on Sonnet and consults stronger tiers on demand), C2 wall clock compression on plan shaped tasks versus a protocol enforced sequential baseline, and C3 typed failure surfacing, scoped to the shared companion outcome contract the test suite already covers. The harness ships in bench/: a runner that isolates each condition in its own Claude configuration directory and keeps verifiers outside the model visible worktree, a strict JSONL record schema, a summary script that refuses to compare snapshots from different task manifests, a redaction step for published transcripts, and a manifest tool that content hashes every task before any results exist.
No results are published yet. The task suite currently holds one of the planned 8 to 12 tasks, so no snapshot would meet the methodology's own publication gate; the first dated reference snapshot ships once the pool is complete, with raw per run data committed alongside the summary table. Until then the status is plain: the procedure is public and runnable, the numbers do not exist. Readers can run the harness themselves with node bench/run.mjs --task <id> --condition <A|B1|B2|B3> --repetition <n> --results <dir> --claude-config <dir> after building condition profiles per bench/conditions/README.md.
The Codex plugin keeps job records, prompts, logs, event ledgers, and stored results under ~/.claude/plugins/data/codex-claude-code-fusion/; prompts and logs can contain task text, diffs, command output, and diagnostics. Managed terminal history defaults to 256 records and 512 MiB, while running jobs, resume safety records, and uncollected background results are protected even when they temporarily exceed that quota. Unknown, corrupt, future-schema, and crash-orphaned content is left untouched rather than counted as safely managed history. Private raw-command staging is removed at SessionEnd for the matching session or after one hour during a later transport allocation. A preserved ~/.claude/plugins/data/codex-openai-codex/ root is read only compatibility history that current reporting ignores unless explicitly enabled; the new plugin cannot collect its deliverables.
The Grok plugin keeps its companion ledger, private job records, briefs, and logs under ~/.claude/plugins/data/grok-claude-code-fusion/; briefs can contain prompts and diffs, logs can contain Grok stderr, and new records retain the CLI reported usage and model_usage objects. /grok:history reads a safe metadata projection from this ledger. The companion does not promise automatic garbage collection for terminal records, briefs, or logs, so clearing this history requires manually deleting that data directory after no running job, uncollected result, or resume evidence is needed. Native Grok conversations are separate under ~/.grok/sessions; upstream retains them for 30 days by default. ~/.grok/config.toml accepts a positive integer at [storage] cleanup_ttl_days; 0 falls back to the default 30 days. Cross-session memory is separate again under ~/.grok/memory and can be read or written by upstream only when memory is enabled. Deleting the companion ledger does not delete native sessions or memory, and deleting native sessions does not clear companion history. A model_usage row contains input, output, cache-read, and model-call counts plus optional cost, so reporting never invents reasoning or total token channels. usage_is_incomplete means the usage ledger may have missed open subagents, usage application, or a drain timeout; present tokens are observed lower bounds and both job-total token and cost coverage are incomplete. Exact positive cost pairs use integer ticks at 10000000000 ticks per USD as authoritative. Grok raw-command staging uses one-time private directories under validated system temporary storage and is consumed before parsing or pruned after one hour. Its headless stdout uses a separate 0600 file that is unlinked as soon as it is opened.
The Fusion plugin keeps model routing and reconciliation data under ~/.claude/plugins/data/fusion-claude-code-fusion/: model-routing.json, reconcile-decisions.json, short lived inline-guard/ session state, the longer lived inline-guard-audit/ JSONL ledger, workers/ lifecycle records with stable task identity and bounded usage, and observations/ sidecars for Codex model, effort, exact per turn token usage, and semantic acceptance. Fusion stats raw arguments use the same one-time temporary staging pattern. New directories use mode 0700 and data files use mode 0600 where the platform exposes POSIX modes. Delete the relevant directories to clear their history. Full uninstall: remove all three plugins via /plugin, delete ~/.claude/rules/orchestration.md, drop the optional Bash(node:*) entry from permissions.allow, delete the three current data roots, and optionally delete the preserved ~/.claude/plugins/data/codex-openai-codex/ root if its old history is no longer needed. Native Grok sessions and memory remain under ~/.grok unless removed separately. Environment overrides for Codex and Grok are documented in docs/codex-contract.md and docs/grok-contract.md. Fusion's audit ledger accepts FUSION_INLINE_GUARD_AUDIT_DIR, FUSION_INLINE_GUARD_AUDIT_RETENTION_DAYS, FUSION_INLINE_GUARD_AUDIT_MAX_BYTES, and FUSION_INLINE_GUARD_AUDIT_MAX_FILES. /fusion:stats aggregates delegation counts across Claude workers and both peers, reports exact token totals only for complete records, distinguishes incomplete from unreported usage, and never estimates missing history. Claude account totals still come from ccusage, and the vendor dashboards remain authoritative for billing.
npm test runs the suite against fake Codex and Grok binaries with no real peer CLI or network. claude plugin validate plugins/codex, claude plugin validate plugins/grok, claude plugin validate plugins/fusion, and claude plugin validate . check every plugin and the marketplace. Iterate with claude --plugin-dir ./plugins/codex --plugin-dir ./plugins/grok --plugin-dir ./plugins/fusion plus /reload-plugins; after committing and pushing, claude plugin marketplace update claude-code-fusion refreshes the installed copy.
.claude-plugin/marketplace.json: the marketplace manifest; installs as marketplaceclaude-code-fusion.plugins/codex/: the Codex integration (companion runtime,codex-rescueagent,/codex:*commands).plugins/grok/: the Grok integration (companion runtime,grok-rescueagent,/grok:*commands).plugins/fusion/: the orchestration layer: tier agents (agents/), the routing policy payload (rules/), and the/fusion:panel,/fusion:setup,/fusion:doctor,/fusion:stats,/fusion:ultra, and/fusion:configcommands.bench/: the benchmark methodology, harness, and task suite; no published results yet, see the publication gate in bench/METHODOLOGY.md.tests/: the fake Codex, Grok, and Claude driven test suite.
The shared companion outcome contract (job lifecycle, liveness, failure kinds, footer grammar, background collection, session threading, stop gate verdicts) lives in docs/companion-contract.md. The Codex instance contract (JSONL lifecycle, foreground invariant, process supervision, durable state, review, usage, and compatibility) lives in docs/codex-contract.md. The Grok CLI instance contract (headless invocation, permission inheritance, process lifecycle constants, timeouts, review validation, version pins) lives in docs/grok-contract.md. Bug reports and questions go to GitHub issues.