wiff

# wiff

**Harness-agnostic, deterministic, resumable multi-agent workflows — written as plain JavaScript. Like `wf`, but wiff.**

[![npm](https://img.shields.io/npm/v/%40xxxoooxoxo%2Fwiff?label=npm&color=cb3837)](https://www.npmjs.com/package/@xxxoooxoxo/wiff) [![MCP Registry](https://img.shields.io/badge/MCP_Registry-io.github.xxxoooxoxo%2Fwiff-6b46c1)](https://registry.modelcontextprotocol.io/v0/servers?search=io.github.xxxoooxoxo/wiff) ![MIT License](https://img.shields.io/badge/license-MIT-blue) ![Node >= 22](https://img.shields.io/badge/node-%3E%3D22-brightgreen)

Fan a task out to a fleet of agents with a small script instead of a prayer. You write ordinary JavaScript with `agent()`, `/goal` stages, `parallel()`, and `pipeline()`; the runtime executes it in the background, journals every step, and — when a run dies halfway through — resumes it without re-paying for a single completed agent. A disposable MCP bridge talks to a persistent local daemon, so active workflows outlive the Codex, Claude Code, Cursor, or cron process that launched them while each child runs on Codex, Claude, Cursor, or Kimi.

<picture>
  <source media="(prefers-color-scheme: light)" srcset="docs/screenshots/run-light.png">
  <img alt="A live wiff run in the viewer: a three-phase accessibility audit with one inventory agent completed and three audit agents running in parallel, each with a live status line, a gantt timeline, and per-agent model/effort/sandbox/token badges." src="docs/screenshots/run-dark.png">
</picture>

```js
export const meta = {
  name: "audit",
  description: "Audit files in parallel, fix confirmed issues in isolation",
  phases: [{ title: "Audit" }, { title: "Fix" }],
};

phase("Audit");
const findings = await parallel(
  args.files.map((file) => () =>
    agent(`Audit ${file} for auth bugs`, {
      key: `audit:${file}`,          // stable key → free replay on resume
      sandbox: "read-only",
      schema: findingSchema,          // structured JSON output
    }),
  ),
);

phase("Fix");
return await parallel(
  findings.filter((f) => f.real).map((f) => () =>
    agent(`Fix: ${f.summary}`, {
      key: `fix:${f.file}`,
      agentType: "surgeon",           // persona from .codex/agents/surgeon.md
      isolation: "worktree",          // own git worktree — parallel writes can't collide
      sandbox: "workspace-write",
    }),
  ),
);
```

When one stage must keep working until a condition is genuinely satisfied, make it a native Codex
goal:

```js
phase("Verify and repair");
await agent("/goal Make the unit tests pass and verify the final run.", {
  key: "tests-green",
  sandbox: "workspace-write",
  timeoutMs: 30 * 60 * 1_000,
});
```

Wiff holds the workflow at that statement and continues the same Codex thread while its goal is
active. The next stage starts only after the worker marks the goal complete; blocked, paused, or
limited goals fail explicitly.

Put durable preferences in `~/.wiff/config.json`, with optional project overrides in
`<cwd>/.wiff/config.json`:

```json
{
  "version": 1,
  "instructions": "Verify before reporting success.",
  "defaults": {
    "model": "claude-sonnet-5",
    "fallbackModels": ["gpt-5.6-sol"]
  },
  "rules": [
    {
      "name": "fix-until-green",
      "when": { "phase": ["Fix", "Repair"] },
      "goal": "Relevant tests must pass.",
      "options": {
        "model": "gpt-5.6-sol",
        "effort": "high"
      }
    }
  ]
}
```

Defaults fill missing agent options; matching rules are explicit user policy and override generated
workflow options. Instructions are injected alongside the task, ordered fallback models may cross
backends, and applicable preference changes invalidate cached results on resume.

## Why

**There is no harness-agnostic workflow orchestration system.** Every coding harness has some
multi-agent story — Claude Code has its Workflow tool, Codex has subagents, Cursor has its own
agents — but each one is welded to its harness: its runs live and die with that app, its state is
invisible to everything else, and none of them can be driven from anywhere but their own chat
window. wiff pulls orchestration out of the harness: a persistent local daemon owns execution and
durable on-disk state while each harness gets a disposable stdio MCP bridge. **Any** MCP client —
Codex, Claude Code, Cursor, a cron job — can start, disconnect from, watch, resume, or cancel the
same runs, and the orchestration itself is a script rather than a conversation.

Ad-hoc multi-agent orchestration ("spawn some subagents for this") is also great until the run is
40 agents deep and something dies. Workflows-as-code give you:

- **Determinism** — the orchestration is a script, not vibes. No time, randomness, filesystem, or network inside workflow code; agents do the external work.
- **Outlive the parent** — closing or killing the launching MCP bridge does not interrupt a run. The detached daemon keeps executing, and another harness can reconnect with the run id.
- **Resume, not retry** — every agent call is journaled with a stable key and an input hash. A graceful daemon restart automatically resumes durable active runs. After an abrupt daemon or machine crash, explicitly resume the safely interrupted run: unchanged completed agents replay from cache instantly and for free. Agents that were interrupted **mid-turn** re-run with a digest of their previous attempt's transcript injected ("here's what you already did — continue"), and worktree agents inherit their partial checkout instead of starting over.

  <img alt="A resumed run: attempt 2, with the inventory agent and all three audit agents replayed from cache in 0ms and only the interrupted synthesis agent re-running." src="docs/screenshots/resume-dark.png">

  That screenshot is the feature: the host was killed mid-synthesis, and on resume the four finished agents came back from the journal in 0ms — only the interrupted one re-ran.
- **Fail-hard semantics** — a rejected agent fails the workflow loudly (`parallelSettled()` is the explicit opt-out). No silent `null`s masquerading as success.
- **Visible scheduling** — agents are journaled as queued before they acquire a runtime slot and
  running only when backend execution starts. Queue and execution durations stay separate, while
  owner heartbeats make a live-but-stalled workflow visible.
- **Isolation where it matters** — `isolation: "worktree"` gives each writing agent a fresh detached git worktree. Clean ones vanish; dirty ones are kept and listed on the run for you to inspect or merge.
- **Personas** — `agentType: "reviewer"` injects a markdown persona as the child's developer instructions, with frontmatter defaults for model/effort/sandbox.

## Install

**Codex** (plugin: MCP tools + the `$workflow` authoring skill):

```sh
codex plugin marketplace add https://github.com/xxxoooxoxo/wiff.git
codex plugin add wiff@wiff
```

**Claude Code** (plugin: MCP tools + skill):

```sh
claude plugin marketplace add xxxoooxoxo/wiff
claude plugin install wiff@wiff
```

**Anything else** — the server is on npm ([`@xxxoooxoxo/wiff`](https://www.npmjs.com/package/@xxxoooxoxo/wiff)) and the [official MCP Registry](https://registry.modelcontextprotocol.io/v0/servers?search=io.github.xxxoooxoxo/wiff) (`io.github.xxxoooxoxo/wiff`), so registry-aware clients can install it by name, and everything else runs it with npx:

```sh
npx -y @xxxoooxoxo/wiff        # stdio MCP server
```

Or from a local checkout:

```sh
git clone https://github.com/xxxoooxoxo/wiff.git
codex plugin marketplace add ./wiff
codex plugin add wiff@wiff
```

Then start a new Codex session and either invoke the bundled skill with `$workflow` or just ask: *"run this as a resumable workflow."*

Installing the plugin auto-approves its five workflow-controller tools so headless and desktop runs don't stop at an MCP approval prompt. Agent filesystem access is still governed per-call by `sandbox`.

## Using from other harnesses (Claude Code, Cursor, any MCP client)

The Codex *plugin* is just packaging. The engine underneath is a plain stdio MCP server, so any
MCP-speaking harness can orchestrate wiff workflows. The mental model: **both the orchestrator
and the workers are pluggable** — whoever drives, each `agent()` child runs on a backend chosen
from its model name: `gpt-*`/`o*` models run as native Codex threads via a local
`codex app-server` (`gpt-6-astra` needs Codex CLI >= 0.153.4); current `claude-fable-5-1`, `claude-fable-5`, `claude-opus-5`, `claude-sonnet-5`, and
`claude-haiku-4-5` models—or the moving `fable`/`opus`/`sonnet`/`haiku` aliases—run as headless `claude`
agents, `composer-*` and `grok-*` models (including `cursor-grok-*` slugs) run through the official Cursor SDK (`@cursor/sdk`) in-process, and
`kimi-code/*` models run as headless `kimi` processes. A workflow can mix them freely
(`provider: "codex" | "claude" | "cursor" | "kimi"` overrides the inference, `WIFF_BACKEND`
sets the fallback for unrecognized models). On the Claude, Cursor, and Kimi backends,
`workspace-write` requires `isolation: "worktree"`; Kimi's `read-only` mode is advisory because
print mode auto-approves tools and has no OS sandbox.

Requirements on the machine, regardless of harness: Node >= 22, git if you use
`isolation: "worktree"`, and the runtime of whichever backend your agents use — Codex CLI
>= 0.144.6
and/or `claude` CLI installed and authenticated, `CURSOR_API_KEY` for Cursor agents, or the
`kimi` CLI configured with the requested full model alias (for example `kimi-code/k3`).

**Claude Code** — the plugin install above is the easy path. To wire just the server manually:

```sh
claude mcp add wiff -- npx -y @xxxoooxoxo/wiff
```

Tool calls go through Claude Code's own permission system; to skip per-call prompts, allow the
five tools in `.claude/settings.json`:

```json
{ "permissions": { "allow": [
  "mcp__wiff__workflow_start", "mcp__wiff__workflow_status",
  "mcp__wiff__workflow_wait", "mcp__wiff__workflow_cancel",
  "mcp__wiff__wo