Claude Code Harness: A Go-Adjudicated Delivery Loop for Agentic Coding

The drift problem Harness targets

Agent coding drifts. Plans live in chat and disappear. Tests become optional under deadline. Review happens after the code is already merged. Release evidence gets reconstructed from memory. The README states this as the core problem. Harness replaces 'ask the agent to code' with a repeatable path: write the spec, implement only the approved slice, verify, review independently, package evidence. It does not make the model smarter. It fixes the procedure and the boundary around the model, so it keeps working when the model changes. That last claim is the project's central bet: the harness is model-agnostic in procedure, even though it ships as a Claude Code plugin first. The target user is an engineer who wants disciplined delivery from an agent, not a sandbox for experiments.

The five verb skills and their gates

The loop is built on five verb skills: plan, work, review, sync, release. Each stage leaves material for the next and has its own gate. /harness-plan turns intent into spec.md and Plans.md, covering scope, acceptance criteria, dependencies, unknowns, and stop conditions. The human approves or corrects that contract. /harness-work implements one approved task, with TDD required when the task says so. /harness-work all runs the whole approved plan, applying the same TDD gate task by task. /harness-review reviews the result separately from implementation; major findings block completion. PR-ready is not release-ready, a pointed distinction. /harness-sync compares the plan against what is actually implemented and reports drift. /harness-release packages only verified evidence into CHANGELOG, tag, and release, with a preflight gate. Data the agent has not seen stays 'unknown' instead of being quietly invented. That is a concrete mechanism: the sync step exists to catch the gap between intention and code.

The Go engine as a runtime floor

The safety layer is what separates Harness from a prompt template. Every tool call is adjudicated by a Go engine before it runs, not reviewed after the fact, because a file diff cannot see a network send or a deletion. There are two layers of different strength. The runtime floor covers five categories: billing, network egress, secret reads, production deploys, and destruction outside the task worktree. These are denied outright with no override by config, env var, or permission mode. The floor sits on an isolated code path with no disable switch, so an autonomous run cannot talk itself past it. Guardrails R01 through R15 cover direct pushes to main, writes to protected paths, forced pushes, and history rewrites, each with a defined verdict and some configurable per project. The design choice here is that the floor is absolute, while guardrails are tuneable. That split is a real architectural decision, not a marketing layer.

Confirmations move to plan time

Instead of interrupting a run, Harness collects the risky operations a plan will need and asks once, up front. Approvals carry an expiry, a task scope, and a use limit, so one approval never becomes a permanent hole. This is a deliberate trade-off: you trade a mid-run prompt for a pre-run approval session. The benefit is that an autonomous run can proceed without pausing, but the cost is that you must foresee which risky operations the plan will need. If you miss one, the run may stall or fail at the gate. Every stop is recorded. Rule id, category, and verdict land in a JSONL log. Command text is never written; only a hash and a length, and for secret-read and billing not even that. That logging design is notable: it gives you a count of what blocked you without exposing sensitive command text, a privacy-preserving audit trail.

Sessions that can see each other

Open three agents on one repo and they normally work blind to each other. The README cites CooperBench numbers: two agents editing the same file succeed about half as often as one agent alone, and 63% of failures trace to a false belief about what the other changed. Harness keeps a roster and a message path between local sessions. The roster resolves from git --git-common-dir, so it sees sessions in other worktrees. bin/harness session list shows every live session with team and agent identifiers. Sending is via bin/harness inbox send with --team, --from, --to, --subject, and a body, or via the session-send skill. Messages arrive at the receiving session's turn boundary, wrapped as data with an explicit non-instruction envelope. A peer's message is a report to verify, never an order to follow. That is a crucial design point: the envelope prevents one agent from commanding another.

The live-message verification gate

Sending is unfiltered by default. Setting [livemsg] verification = 'on' adds a gate that checks a message's factual claims. The gate verifies that mentioned files exist, mentioned commits resolve, and a 'clean worktree' claim matches git status. If a claim fails, the gate returns the reason to the sender instead of delivering a false message. While verification is off, the send path does not call the gate at all. That last detail matters: the gate is not a passive filter, it is an active check that only runs when configured. This is a limitation in default mode, because a false claim can propagate between sessions unless you opt in. The README says this is local-only and does not depend on harness-mem. If harness-mem is installed alongside, its roster entries are preserved untouched, which suggests a modular design where the message path works standalone.

Install routes and tool tiers

Install is via the Claude Code plugin marketplace: /plugin marketplace add Chachamaru127/claude-code-harness, then /plugin install claude-code-harness@claude-code-harness-marketplace, then /harness-setup. For Codex CLI, there is a script: scripts/setup-codex.sh --user, with a note to rerun after Harness updates and restart Codex. Cursor has scripts/setup-cursor.sh. The README is explicit that four install routes are not four identical guarantees. A setup script means a tool has an entry path, not a shared product promise. Claude Code is 'supported', Codex CLI is 'supported', Cursor is 'supported', and Grok is presumably similar, though the truncated README does not give the full tier list. The key takeaway is that the harness's behavior may differ by tool, and you should check the per-tool README, like codex/README.md, for specifics. The script rerun requirement for Codex is a maintenance cost: you must remember to rerun after updates.

Limitations and the wrong-tool case

Harness is not a sandbox for exploratory coding. It is a delivery pipeline with gates, which means it adds overhead to every change. If your team treats agent output as a draft to edit, the approval and review gates will feel bureaucratic. The README's own claim that 'written is not working' implies a culture of verification, which not every team has. The runtime floor is absolute, but that also means you cannot override it for a legitimate one-off task, like a script that needs to write outside the worktree. The guardrails are configurable, but the floor is not. That is a genuine limitation: if your workflow requires an agent to touch a production deploy or read a secret as part of a normal task, Harness will block it outright. The live-message verification gate is off by default, so cross-session false claims can slip through unless you enable it. The README does not document failure modes for the Go engine itself, so you should test the gates in your environment before relying on them.

An alternative: a plain prompt template with manual review

The obvious alternative is a custom prompt template that instructs the agent to plan, then implement, then review, without any external enforcement. Tools like Claude Code's built-in hooks or a simple shell script can approximate the loop. The difference in approach is where the authority sits. A prompt template relies on the model's compliance; Harness places authority in a Go engine that runs before every tool call, independent of the model's inclination. The template cannot see a network send or a deletion after the fact, whereas the engine can deny it before it happens. The template also has no runtime floor: a model can ignore a prompt instruction under pressure, but the engine has no disable switch. The trade-off is that the template is lighter and easier to modify, while Harness is heavier but provides a hard boundary. For a team that trusts the model to follow instructions most of the time, a template may suffice. For a team that needs a guarantee, the engine is the differentiator.

Editorial conclusion

Adopt Claude Code Harness if you run Claude Code, Codex CLI, Cursor, or Grok on repos where uncontrolled agent actions are a real risk and you can enforce a strict plan-approval workflow. Skip it if your team treats agent output as a suggestion rather than a contract, or if you cannot tolerate the overhead of spec approval and independent review gates. Before adopting, verify the Go engine actually blocks the five runtime-floor categories in your environment, test the live-message verification gate with a false claim, and confirm that the CLI binaries rebuild from source as the CI gates claim. The project's value rests on its procedural boundary, not on model intelligence, so check that boundary holds in your repo before trusting it.

Official sources

1. Official README
2. Project repository
3. Release notes