We build GPTree with several coding agents working the same repository at once: Claude Code, Codex, and Cursor, each in its own git worktree.
The failure that finally made us build tooling for it was small and completely silent.
One session was told to replace with a Stripe-specific implementation.
Another was told to add PayPal support to .
Different worktrees.
Different files.
Zero textual conflict.
Git merged both branches cleanly, and the second change now depended on an extension point the first had deleted.
Nothing in the toolchain had an opinion about it at any moment.
Git compares diffs.
It cannot compare plans.
Worktrees isolate files, not plans Worktrees became the standard answer to parallel agents for a good reason: two sessions editing one checkout will overwrite each other's files and poison each other's context.
Isolated checkouts fix that completely.
But three failure modes survive file isolation, because they were never about files: Destructive versus additive.
One agent removes or replaces a thing another agent is building on.
The example above.
Merges clean, breaks the design.
Duplicate work.
Two agents solve the same problem from different angles because nothing assigned ownership.
You pay twice and then pay again to reconcile.
Contract drift.
One agent changes an API, a schema, or a config contract while another codes against the old shape.
Compiles, runs, disagrees at runtime.
A shared task list helps with the second one, if every agent reads it, every time.
Nothing in that setup catches the first or third, because the collision is between intentions, and intentions live in prompts, not in any file a tool can watch.
Declare the work before doing it Foremerge is the internal tool we built for this, open-sourced this week.
It is a coordination protocol that sits above Git: agents declare what they are about to do, before they do it, in a form precise enough to check.
A declaration is an intent with one or more semantic scopes, each carrying an operation: Scopes are not file paths.
The vocabulary covers symbol, api, schema, config, migration, contract, and more, because file paths miss API, schema, configuration, and cross-language collisions entirely.
The operation (replace, extend, and so on) is declared rather than parsed out of the summary, so it does not matter how the agent phrased its plan.
When a second agent declares work on the same scope, deterministic rules compare the declarations and raise a finding while both pieces of work are still plans.
This is real output from 0.4.0, captured while writing this post: The finding names the rule that fired, explains itself, and suggests a resolution.
It does not block anyone.
Claims in Foremerge are leased and advisory: overlap produces a warning and shared context, never a lock, because two agents can often work the same region compatibly and a lock would serialize work that did not need serializing.
The other half of the protocol is evidence.
When an agent finishes, it publishes a ChangeSet, and acceptance is gated on verification that Foremerge runs itself: your named check (a build, a typecheck, a test target you registered) executed against the exact candidate fingerprint.
An agent saying "tests pass" is recorded as provenance; it does not satisfy the gate.
If the tree changed after validation, the attempt is non-authoritative and the gate says so.
Mechanically it is one Rust binary.
The CLI, a local JSON API, and an MCP server are adapters over the same SQLite store, which lives inside your repository's git common directory, which is exactly why worktrees work well with it: linked worktrees share that directory, so every agent in the repo sees the same declarations while keeping isolated files.
Local-first, no cloud, Apache-2.0.
The five-minute version The fastest path is to let your agent set it up.
Paste this into Claude Code, Codex, or Cursor from inside the repository you want to coordinate: The MCP server gives the agent the full lifecycle as too