DEV Community

Cover image for Supervise the agents that build your OpenSpec changes
Alexander Ivanov
Alexander Ivanov

Posted on Originally published at openspec-ui.dev

Supervise the agents that build your OpenSpec changes

First published on openspec-ui.dev.

OpenSpec gives an agent something to build from: a proposal, a design, a list
of tasks, and the spec deltas the change will leave behind. What it does not
give you is a way to see the agent while it works.

Several tools draw OpenSpec changes as boards and lists, and they do it well.
Read on 2026-09-20 in their own words, none of the three I compared starts an
agent. OpenSpec Workbench does: it runs an agent CLI on a change, says what
the run is doing while it does it, and lets a person stop it. This is a short
tour of how, and of what it will not promise.

A run started from a change's card, stopping at a checkpoint, and a stop asked for with a reason

A change becomes a card

The Pipeline draws every active change in the order the changes declare, with
what a live run last said and what can start alongside what. A card is where
you act: it starts a run, answers a checkpoint, and asks a run to stop, with a
reason. The same Pipeline is in the standalone web application and in the VS
Code extension, and both read the same shared core.

A run is a chain of stages: propose, review, apply, verify, archive, git. You
choose the agent for each stage, and where the chain pauses for you.

What a run says it is doing

Every run writes a status record: whose it is, where it runs, what it last
said it was doing and how long ago. The Pipeline draws it on the card, and
openspec-ui-cli status prints it for every run of the repository, whichever
host started it.

It never says a run is stuck. A silent agent and a hung one look identical,
and telling them apart is a person's judgement, so the tool leaves that call
to you and gives you the last thing the run said and its age.

Changes can run side by side. Each one can have its own git worktree, guarded
by a lease, and openspec-ui-cli ready says which ready changes can start
alongside which, and why the others cannot.

Stop it where its work is sound

A card's Stop asks for a reason. The request is signed with the machine's key.
The run reads it at its next renewal and acts only if it is verified and
fresh, and it stops where its work is sound. From a terminal:

openspec-ui-cli stop <instanceId> --reason "wrong branch"
Enter fullscreen mode Exit fullscreen mode

--after <task> lets the run finish a named task first and stops at the next
sound point after it.

Your agent, per stage

The picker drives the agent CLIs you already have: Claude CLI, GitHub Copilot
CLI, Codex CLI, Gemini CLI, DeepSeek CLI, and a local model behind an
OpenAI-compatible endpoint. The CLI-based ones also come in a variant that
speaks the Agent Client Protocol, which carries structured progress instead of
scraped text. The tool never handles an API key: each CLI keeps its own login.

Here is what has actually been run. Claude CLI and Copilot CLI have been run
against the real binaries, and so has DeepSeek CLI over ACP, on Node 22.18+ or
24.2+. Codex and Gemini never have, raw or over ACP: their adapters are
written to the vendors' documented interfaces and tested against a mocked
peer, and if either misbehaves for you, that is the likeliest reason and a
report would be useful. Two ACP caveats are worth knowing before you choose
one: the Claude adapter never asks for permission, and copilot --acp
completed file writes and shell commands here without asking either.

Checkpoints, ceilings and a record

Where a person decides is configuration, and the runner enforces it: an
autonomy level, checkpoints between stages, a review gate that only a change's
own settings can relax, and tasks marked as human-only or delegated to a named
agent. Each stage has its own spending cap in the unit its agent honours, each
chain has a ceiling, and every run lands in an audit log. The project also
states plainly which limits do not exist, in a document of their own.

The Workbench ships 17 change templates, for things like a Vite migration, a
production Dockerfile, an authentication middleware or a testing baseline, so
a new change can start from a proposal that already has the right shape.

Try it

In VS Code, install it from the Marketplace:

code --install-extension openspec-ui.openspec-ui-vscode
Enter fullscreen mode Exit fullscreen mode

Or run the standalone application from a clone of the repository:

npm install
npm run build --workspace @openspec-ui/server
npm run start --workspace @openspec-ui/server -- <workspaceRoot> 4317
Enter fullscreen mode Exit fullscreen mode

It prints a URL with a one-time token; open that exact URL. Everything runs on
your machine, against your own agent CLIs.

The repository, the packages and the extension are still called OpenSpec-UI;
the product's name is OpenSpec Workbench. The code and the issues are at
github.com/VeryComplexAndLongName/OpenSpec-UI,
and I would like to hear from anyone who tries it, above all from people who
run Codex or Gemini, which I have not been able to.

Where each claim comes from

  • The Pipeline, the stages, the status record, stop, and the other viewers compared on 2026-09-20: the repository's README, sections "How this differs from the other OpenSpec viewers", "Agentic Harness" and "CI CLI".
  • Which agents have been run against a real binary, and the ACP caveats: the README's "Agent Selection" section.
  • Checkpoints, autonomy levels and per-stage caps: HARNESS.md. What does and does not cap a run: LIMITS.md.
  • The 17 templates: packages/core/src/templates, 17 files.

Top comments (0)