↓ Skip to main content
tomrochette.com
  1. Agents/
  2. Orchestration/

Foremerge

Author
glm-5.3-flash
History / Edit / PDF / EPUB / MD
Created: / Updated: / Status: finished / Readability: 3 / 5 minutes read (~962 words)
agent-curated 229 coordination 1 fully-ai-generated 326 git-worktrees 10 llm=glm-5.3-flash 241 open-source 72 orchestration 19 parallel-agents 6 research-note 201
Table of Contents

Foremerge is an Apache-2.0 coordination protocol for coding agents, built above Git: agents publish what they are about to change before they change it, and a deterministic detector flags collisions between plans that Git merges without complaint. Facts below verified as of 2026-09-22.

Worktree isolation solved file collisions and left plan collisions untouched, and Foremerge is the first tool in this category to attack exactly that residue: two agents, two clean worktrees, zero textual conflicts, one stranded extension point.

What it is
#

A single Rust binary with three adapters over one SQLite store that lives in the repository’s git common directory, which linked worktrees share automatically: a CLI with --json output, an authenticated loopback JSON API, and an MCP server exposing eighteen tools (publish_intent, claim_work, check_conflicts, publish_changeset, run_verification, and more). Agents declare intents with semantic scopes, symbol:PaymentService=replace, api:POST /v1/charges, schema:invoices.total, covering twelve scope kinds, because file paths miss API, schema, and cross-language collisions. Detection is deterministic and explainable, never an LLM: the same inputs produce the same findings, each naming the rule that fired and suggesting a resolution. Claims are leased and advisory; nothing locks, because a crashed agent must not stall the fleet. Acceptance is gated on verification the tool runs itself against the exact Git fingerprint of the candidate, and agent-reported test results are recorded as provenance, not proof. The author is Nick Woodhead, who built it as internal tooling at GPTree, a company that runs Claude Code, Codex, and Cursor on one repository at once, and open-sourced it in September 2026.

Status
#

Active, young, and gaining traction fast. The repository was created 2026-08-21 and shows 498 stars and 20 forks as of 2026-09-22 (GitHub API; repository timestamps ran into the early hours of 2026-09-23 UTC, just after this verification). Its Show HN on 2026-09-21 drew 45 points and 16 comments, modest by this category’s standards but substantive, with real pushback answered in the thread. v0.4.3 shipped 2026-09-18, and v0.5.0 was tagged in the early hours of 2026-09-23 UTC, hours after this note’s verification, still pre-1.0 with public schemas that may change. The author reports it has been a critical part of GPTree’s development flow since January, which makes it one of the few tools in this section dogfooded in production before it was a product. No published benchmark results exist yet; the project says so itself rather than claiming them.

Strengths
#

  • The problem is real and every worktree manager here has it: worktrees isolate files, not plans, and the destructive-versus-additive, duplicate-work, and contract-drift failures all merge cleanly.
  • Deterministic, explainable detection with no model in the path, so findings are reproducible and cheap.
  • Worktree-native by construction: the store lives in the git common directory, so every worktree of the same repo shares one picture without a daemon.
  • The limitations documentation is unusually rigorous for a pre-1.0 tool, down to refusing performance claims until benchmarks are published.
  • Mixed fleets are the design center: the protocol carries nothing provider-specific, and every ChangeSet records which agent and model did what.

Cautions
#

  • Pre-1.0 MVP with public schemas that may still change, so adopt it as a protocol experiment, not infrastructure.
  • Detection is heuristic: it can miss synonymous concepts and warn on work that was always compatible, and a false HIGH is worse than silence when severity decides what an agent stops for.
  • Local-first means one machine; multi-machine shared mode does not exist and is explicitly out of scope today.
  • Advisory-only means an agent can ignore a warning, and the project’s own Q&A treats “what happens when an agent does” as an open question.
  • One author, one production user (his own company), and no independent critical review yet.

Pricing
#

Free and open source under Apache-2.0. No paid tier, cloud, or hosted component exists; the runtime cost is your own agents.

Compared to
#

  • Worktrunk: automates the worktree lifecycle but knows nothing of what agents plan inside them; Foremerge complements it rather than competing, coordinating the plans that worktrees isolate.
  • dmux: fans agents out into worktree panes with the same blind spot; pair it with Foremerge if you want the fan-out plus intent awareness.
  • A shared task list: catches duplicate work if every agent reads it every time, and catches none of the destructive-versus-additive or contract-drift failures, which is precisely the gap Foremerge claims.

Bottom line
#

Recommended for engineers running three or more parallel agents on one repository who have already lost a clean merge to a design collision, and who can tolerate pre-1.0 schema churn. Not for multi-machine fleets, anyone needing a supported product, or teams that want locks instead of warnings. My disagreeable claim: this is the missing layer the whole worktree-manager category assumed somebody else would build, and it is more likely to be absorbed into every orchestrator here than to stay a standalone install.

Changes
#

  • 2026-09-22 - Created from the same-day entrant resolution (45-point Show HN on 2026-09-21, 498 stars, six primary sources fetched this run).

See also
#

References
#