Sigbound

Run multiple AI coding agents on one repository in parallel, and merge their work automatically — landing only changes that build and pass your tests.

Overview

Tools that run coding agents in parallel give each agent its own git worktree and leave you to merge the results. Merging is where the time goes: two agents edit the same file, or their separate changes combine into code that no longer compiles. One engineer reported spending 30–50% of their parallel-agent time on conflict resolution; another got a clean merge with zero conflicts and still spent six hours fixing a broken build.

Sigbound handles the merge. It splits a task into independent pieces, runs an agent on each, combines the non-conflicting work in parallel, resolves conflicts with a model (and flags anything it is unsure about rather than guessing), and gates every merge on your build and test commands. What comes back is a single branch that compiles and passes.

Every model step — planning, the agents, conflict resolution, repair — is a command you provide, so you use your own model and harness. Sigbound runs on top of plain git and works with any host. It is not a git server and does not replace your existing tools.

Cursor's Origin announced a closed, hosted version of this idea; it is not yet available. Sigbound is open, runs on your own repository, and works today.

Features

• Parallel merge — non-conflicting changes from many agents are combined at once, not one at a time.
• Conflict resolution — a model resolves overlaps; low-confidence cases are flagged for review, never guessed.
• Verified merges — nothing lands unless the combined result passes your -verify command.
• Self-repair — a merge that breaks the build is sent back to an agent to fix, then re-checked.
• File lanes — each task declares the files it may touch; an agent that strays is rejected.
• Landing policy — a sigbound.policy file committed in the repo declares the bar every landing must clear; flags can tighten it, never loosen it.
• Run parking — changes to paths you mark sensitive are verified and then held for a human sig ack, instead of landing on their own.
• Run ledger — sig log records every run: what it was asked to do, which commands ran, whether verify passed, and what SHA landed.
• Continuous mode — sig serve -watch picks up new work as it appears and runs the same gated loop without an operator.
• Bring your own model — planner, agent, resolver, and repair are each a command you supply.
• On top of git — uses worktrees and merge-tree; no server, no lock-in, any host.

Install

# Homebrew (macOS/Linux)
brew install surya-koritala/tap/sig

# installer script — fetches the right prebuilt binary and verifies its checksum
curl -fsSL https://raw.githubusercontent.com/surya-koritala/sigbound/main/install.sh | sh

# go install
go install github.com/surya-koritala/sigbound/cmd/sig@latest

# from source
git clone https://github.com/surya-koritala/sigbound && cd sigbound
go build -o sig ./cmd/sig

Prebuilt archives (with checksums) for macOS, Linux, and Windows are on the releases page.

The only runtime requirement is the git binary (>= 2.38) — run sig doctor to check. Go 1.25+ is needed only when building from source.

Platform support. Linux and macOS (amd64/arm64) are the primary, tested-in- anger targets. Windows (amd64) binaries are built, go vet-clean, and unit-tested on CI (windows-latest), but not yet battle-tested. Because sig runs your planner, agent, resolver, and verify commands through a POSIX shell (sh -c), Windows needs sh on PATH — Git for Windows, already required for the git binary, ships one. The sig serve daemon's startup crash-recovery relies on unix process semantics and is not yet validated on Windows.

Running in CI? surya-koritala/sigbound is also a GitHub Action — see GitHub Action in the docs.

Usage

Run a set of tasks from a file. examples/tasks.json describes three features on separate files; each task's file list is enforced.

./sig run \
  -repo /path/to/your/repo \
  -tasks examples/tasks.json \
  -strategy overlay \
  -agent    'claude -p --permission-mode acceptEdits "$SIGBOUND_TASK"' \
  -resolver 'git merge-file -p --union "$SIGBOUND_OURS" "$SIGBOUND_BASE" "$SIGBOUND_THEIRS"' \
  -verify   'go build ./... && go test ./...' \
  -repair   'claude -p --permission-mode acceptEdits "Fix this build failure: $SIGBOUND_FAILURE"' \
  -json

Or start from a goal and let a model plan the tasks:

./sig run \
  -repo /path/to/your/repo \
  -goal "Add CSV export, due dates, and a summary command" \
  -planner 'claude -p "$SIGBOUND_PROMPT"' -n 3 \
  -agent '...' -resolver '...' -verify 'go build ./... && go test ./...'

-agent, -resolver, -repair, and -planner are shell commands you supply; the examples use the claude CLI, but anything that edits files in the working directory works. Each command receives the relevant SIGBOUND_* environment variables.

Typing that sh -c wiring by hand is the fiddliest part of a first run, so -agent-preset/-repair-preset/-planner-preset (claude, codex, aider) and -verify-preset (go, node, python, rust, plus the govulncheck, gitleaks, and codeql security scanners) expand a short name into the known-good command above — an explicit -agent/-verify/etc. always overrides its preset. Just the -agent/-verify pair from the first example collapses to:

./sig run -repo /path/to/your/repo -tasks examples/tasks.json -agent-preset claude -verify-preset go

That drops -resolver and -repair from the first example rather than presetting them: -repair has its own -repair-preset claude|codex|aider if you want it, but there's no -resolver-preset at all — see Presets for every preset's exact expansion.

That invocation is long and doesn't change much run to run — put your standing flags in sig.conf (one key=value per line; see Config file) and just pass -config sig.conf -tasks ... from then on.

sig serve: an HTTP run API

sig serve -repos /path/a,/path/b runs the same engine behind a small local daemon: POST /runs starts a run, GET /runs/{id} polls it, GET /inbox lists everything waiting on a human, and a /ui page lets you inspect any branch a run flagged and ack or reject a parked landing. It binds loopback by default, ships no TLS or user model, and adds no new landing path — it drives the exact same -verify-gated engine sig run does. See sig serve.

sigbound.policy: a repo-owned landing bar

Commit a sigbound.policy file at the repo root and both sig run and sig serve enforce it identically: a required verify battery, lane/semantic/assert floors, and agent/budget ceilings the invoker cannot loosen (a flag may only tighten). It is read from the base commit's tree, so the bar is versioned with the code. Paths listed under ack-paths, and any change that modifies sigbound.policy itself, are verified and then PARKED instead of auto-landing: sig ack RUN_ID lands byte-for-byte the tree that passed verify (re-integrating and re-verifying first if the base moved), sig reject RUN_ID lands nothing and keeps the branches. See Landing policy and Run parking.

sig export / sig import: multi-machine runs

Splitting a batch across machines? A worker runs its agents locally and sig exports the resulting branches into one git-bundle file; a coordinator sig imports the bundle into an isolated namespace and folds it in with sig integrate, same as any local branch. See Distributed workflow (bundles).

Documentation

docs/USAGE.md is the complete reference: every sig run, sig integrate, and sigbench flag, the full set of SIGBOUND_* environment variables passed to each command, and the JSON report shape. examples/ has a runnable quickstart.

sig version reports the build; releases follow Semantic Versioning and are recorded in CHANGELOG.md.

How it works

Sigbound partitions the work so agents touch different files, runs them in parallel worktrees, then merges. Changes to disjoint files are combined in a single pass; only genuinely overlapping changes are resolved one at a time. Every merge is gated on -verify, and a failure is routed to -repair before it can land.

When the combined tree fails -verify, Sigbound hands the failure to -repair, applies the fix, and re-runs -verify. Nothing reaches your base branch until it passes.

Implementation notes

Each agent works in its own git worktree. Non-overlapping branches are merged directly in git's object database with git merge-tree and a tree-overlay fast path — no working tree and no index locks — partitioned by each branch's write-set so disjoint changes commute. Correctness is asserted trees-equal against a reference merge on every run. Sigbound shells out to the git binary and does not reimplement git.

Benchmarks

Merging N agents' branches into one repository, on a single laptop (median of 5 runs, correctness verified on every run).

Agents	Sigbound	Sequential git merge	Speedup
64	0.3 s	4.5 s	17×
128	0.5 s	8.1 s	17×
256	0.8 s	16.7 s	22×
512	1.4 s	35.1 s	25×

Sequential merging slows down as agents are added, because each merge changes the base for the rest. Parallel integration stays roughly flat, so the advantage grows with the number of agents.

The advantage grows with the number of agents.

Reproduce a table row (or the full agents×overlap sweep):

go run ./cmd/sigbench -agents 512 -files 2000 -strategy overlay,porcelain -runs 5 -warmup 2
go run ./cmd/sigbench -sweep

The fold stays linear well past this table — docs/SCALE.md carries it out to 4096 agents on two machines, with the observed scaling exponent and where the first bottleneck would be.

Comparison

	Parallel agents	Merges the work	AI conflict resolution	Gated on build + test	Self-repair	Open	Available
GitHub PRs	—	—	—	one PR at a time	—	✓	✓
Parallel runners¹	✓	—	—	—	—	✓	✓
Cursor Origin	✓	✓	✓	✓	✓	✗	waitlist
Sigbound	✓	✓	✓	✓	✓	✓	✓

¹ claude-squad, Conductor, and the worktree support built into Claude Code and Codex.

Testing

• 547 tests, including end-to-end runs against real git repositories.
• Coverage: 84% on the integration engine, 84% on the git plumbing (go test -cover ./cell/ ./internal/gitx/).
• 24 fuzz targets covering every parser of git and model output. Fuzzing found and fixed a bug in the ls-tree parser that could have produced a silently incorrect merged tree; the triggering input is kept as a regression test.

go test -race ./...

Status

Working: the engine, the sig CLI, the benchmark, multi-machine execution (sig export/sig import bundles), the repo-owned landing policy with run parking, the sig log run ledger, and sig serve — an HTTP run API with a UI for reviewing conflicts and acking parked landings — all verified on real repositories. Sigbound develops itself: changes to this repository are landed by sig, gated by the sigbound.policy committed here.

Sigbound builds on top of git and does not aim to become a git host: sig serve runs and lets you inspect work over a repo you already host, it does not host repos, review pull requests, or replace your forge.

License

Apache-2.0.

Contributing

See CONTRIBUTING.md.