Running several coding agents at once is now normal, and the failure that hurts is not the merge conflict your tooling shows you. It is the one it cannot: two agents editing one design in different files, in different worktrees, with no overlapping lines, merging cleanly, and leaving a codebase where half the call sites route through an abstraction the other half assumed still existed. Foremerge is a coordination layer built specifically for that blind spot: agents keep isolated git worktrees, but they share one local ledger of declared intent, and the tool flags incompatible plans while both are still planning. This review answers the practical question — can a coordination layer actually catch an intent conflict before the merge? — with a bounded reproduction of the project’s own documented scenario on the released 0.5.1 binary, plus the project’s documented limits.
The merge that is clean and still wrong
The canonical example is the one the maintainer uses, from a real incident: Agent A replaces PaymentService with StripePaymentService; Agent B adds PayPal support by extending PaymentService. Different worktrees, different files, almost no identical lines. Git merges both branches cleanly — and the second change now depends on an extension point the first one deleted. Foremerge’s repository documents this as the failure the tool exists to prevent, and the project grew out of an internal tool at GPTree before being open-sourced on 21 August 2026 (see github.com/naw103/foremerge).
The reason this is not a niche worry is measurable. A 2026 dataset study of agent-authored pull requests, AgenticFlict, collected 142K+ agentic PRs from 59K+ repositories, merge-simulated 107K+ of them, and found 29K+ PRs with merge conflicts — a conflict rate of 27.67% — extracting 336K+ conflict regions. That count is conflicts Git could see. A second study of concurrent agent activity, AI Agent Pull Requests on GitHub, used 33,596 PRs across 2,807 repositories and replayed 747 real three-way merges, finding textual conflict in 41.7% of cross-agent pairs versus 19.8% of intra-agent pairs, with 84.4% of conflicted files being source code rather than dependency manifests. Both papers quantify textual collisions; the subset Foremerge targets is the one that never becomes textual at all.
What this review verified, and how
To avoid restating marketing claims, this review ran the project’s own documented quickstart end to end on 2026-10-16 with the released binary: curl -fsSL https://foremerge.com/install.sh | sh (the installer resolved GitHub releases/latest and verified the published SHA-256 of the x86_64 Linux archive), reporting foremerge 0.5.1, binary SHA-256 1301cf96…6b55ef, against git version 2.43.0. In a fresh git repository inside the run’s scratch directory, two linked worktrees were created with the documented wrapper, two agents were registered from inside their own worktrees, and each published one intent declaring an operation on an explicit semantic scope.
| Case exercised (foremerge 0.5.1) | Observed result |
|---|---|
intent publish --scope symbol:PaymentService=replace (worktree A) | ok: true, zero findings — nothing to compare against yet |
intent publish --scope symbol:PaymentService=extend (worktree B) | one finding: destructive_vs_additive, FM-C001, HIGH, score 0.97, asserted: true, detected_before_code: true |
foremerge status from worktree A | the same HIGH finding, naming both intents — the store is shared across worktrees |
Control pair on disjoint scopes (symbol:PaymentService vs file:docs/billing.md) | zero findings |
Second additive op on the same scope (=modify) | FM-C001 HIGH (replace vs modify) plus FM-C003 shared_contract MEDIUM |
Prose says “delete … ThumbnailCache” but declared op is =extend | zero findings — the declared operation governed |
work claim on the shared scope, then a second work claim | both succeeded, advisory_only: true; second returned FM-C005 overlapping_claim MEDIUM, score 0.88, “This warning is advisory; Foremerge does not hard-lock work.” |
conflicts check --intent "Remove PaymentService…" --scope symbol:PaymentService=remove | three ephemeral (eph_) findings, including FM-C002 divergent_rewrite HIGH, with no state change |
Two things in that table are worth more than the rest. First, the detection fired before any code existed — the agents had only declared intent, and the run’s own output records detected_before_code: true. Second, the finding was readable from the other agent’s worktree: the two worktrees genuinely shared the ledger while keeping their files separate, which is the mechanism behind the project’s line that worktrees isolate files but not plans (README).
The reproduction was run locally by the author on the review box; the commands above are given so that any reader can rerun the same scenario, and no dataset or hosted artifact is published alongside this article. It is one scenario in one synthetic repository, not a benchmark.
What the reproduction does not establish
Honesty about method matters more here than anywhere else in this review, because the tempting claim is the false one. This run used CLI-level state, not real agents: no model calls, no code written, no branch merged. It shows which specific intent pairs were and were not flagged in one scenario; it did not measure a false-positive or false-negative rate, because no labelled corpus of conflict and no-conflict pairs was executed. What the reproduction verifies is that the detection mechanism behaves as documented on declared intent — not that the detector is accurate.
The one accuracy figure commonly quoted for this project is not from this review. The documentation states that an earlier prose-inference version “caught one of ten real conflicts and raised a false HIGH on nine of nine compatible pairs” on tests/paraphrase_probe.rs — the maintainer’s own measurement of a superseded pre-0.4.0 code path, quoted verbatim from docs/conflict-detection.md. It was not reproduced here, and it does not describe 0.5.1 behaviour.
The project’s own limitations page is unusually frank and should be read before adoption (docs/limitations.md). Detection only knows what agents declare: work nobody announced is invisible, and a missing finding is “none known yet”, not “none exists”. Scope hierarchy is not modelled, and the declared-operation vocabulary is closed at seven — add, extend, modify, replace, remove, rename and migrate (docs/protocol.md) — none of which is a read, so nothing in the ledger registers two agents reading the same scope as a collision. Dependency and contract drift are only caught when the caller-side agent volunteers the contract, and prose fallback is English-only. There are no push notifications either, so the earlier agent learns about a conflict on its next status check — a gap the maintainer lists on the roadmap in the Show HN thread (news.ycombinator.com/item?id=49789356).
How detection works: five named rules, twelve scope kinds, seven operations
The detector is deliberately not a model. The documented design states plainly that it “does not call an LLM, compute embeddings, parse a full AST, or claim to prove that two changes are compatible” — it compares declared operations on declared semantic scopes. The vocabulary is small and enumerable: twelve scope kinds (symbol api schema config infra test migration env file component contract domain) per docs/protocol.md, and seven declared operations — add, extend, modify as additive, replace, remove, rename, migrate as destructive — feeding five numbered rules: FM-C001 destructive versus additive, FM-C002 divergent rewrite, FM-C003 shared contract, FM-C004 duplicate work, FM-C005 overlapping claim.
The severity model is the interesting part. FM-C001 and FM-C002 reach HIGH only when both sides are asserted on the same canonical scope; when only one side asserts, the finding drops to MEDIUM. Inferred signals are structurally capped below HIGH, which is a direct consequence of the paraphrase-probe result: a guess presented at HIGH severity stops being trusted. The FM-C005 overlapping-claim score of 0.88 is the value the project’s own documentation specifies for that rule, and this review’s run produced exactly that number, with asserted: true recorded in the evidence payload of the HIGH findings.
Advisory by design, gated at acceptance
Foremerge does not lock files or block agents; the README is explicit that warnings are advisory “because a single crashed agent would then stall the whole fleet” (README), and the maintainer’s framing is that a lock assumes the declarer finishes what they started when agents abandon work constantly (maintainer Q&A).
The reproduction supports that at the CLI level: publishing a conflicting intent and taking a second claim on the same scope both succeeded, with advisory_only: true and a warning rather than a refusal, and no command was blocked or returned a non-zero exit code.
The hard stop lives at acceptance instead. A ChangeSet publishes a clean candidate, Foremerge itself executes a registered check against that exact worktree fingerprint, and an agent reporting “tests pass” is recorded as provenance rather than proof (README).
Checks are registered by name by a human, so agents send a lookup key rather than a shell command. That design choice reads differently once you look at the 0.5.0 release notes: the HTTP validation endpoint used to execute an argument vector taken from the request body, a CodeQL-flagged rust/command-line-injection path where any bearer-token holder, or any local process running under --no-auth, could make the daemon run an arbitrary program. Version 0.5.0 replaced that body with {"check": "<name>"} resolved from the repository’s trusted registry (v0.5.0 release notes). The residual risk is documented alongside the rationale: an agent can still write the code that a legitimate check executes (maintainer Q&A).
If a repository has nothing meaningful to verify, foremerge checks policy advisory records work as UNVERIFIED with a reason rather than pretending a check ran — which is what foremerge doctor reported in this review’s run before any check was registered (acceptance_ready: false, policy strict).
Maturity: pre-1.0, and it says so
The README’s status line reads “Foremerge 0.5.1 is a pre-1.0, local-first MVP.” The numbers behind that are small and point-in-time as of 2026-10-16: GitHub metadata shows 540 stars, 25 forks, 4 open issues, 2 watchers, created 2026-08-21, last push 2026-10-14; crates.io reports 0.5.1 as the max version with 134 all-time downloads across seven published versions between 2026-08-25 and 2026-10-03. The Show HN launch reached 45 points (hn.algolia.com/api/v1/items/49789356). Download counts understate the recommended install path — the curl installer and npm package do not register as cargo downloads — but none of these counters is an adoption measure, and stars measure attention rather than use. The maintainer’s own framing on the Rust users forum is the fairest summary: “pre-1.0, heuristic detection that can warn on compatible work, local first, benchmark harness exists but no published results yet” (users.rust-lang.org).
That last clause is the one to weigh. There are no published paired-run benchmarks, so any claim about how much rework the tool prevents is currently unsupported — including by this review.
Where it fits, and where it does not
Adopt it as a shared ledger and audit trail before trusting it as a gate. It is a reasonable fit when several agents or several developers work in parallel on one repository, when a semantic collision would be expensive, and when you can accept that value here is partly the record of who declared what. It is a poor fit if you expect enforcement: the MVP does not lock, does not replicate SQLite across machines, does not gate Git, and does not merge or push anything. The project’s own framing is “Git gates, Foremerge informs”, with surfacing acceptance state to the Git host as status checks as the roadmap path rather than intercepting writes locally.
Two documented claims worth keeping in view. The maintainer says worktrees fix files but not plans, and that scopes are not file paths because paths miss API, schema, configuration and cross-language collisions (parallel-coding-agents-without-the-carnage). And the tool refuses the three most-requested features — hard locks, a merge queue, editor-buffer sync — on the grounds that each would claim authority it cannot honestly enforce (31 questions).
The strongest counter-argument comes from the launch thread itself: one team deliberately gives each agent an independent, area-owned remit and negotiates across areas through an orchestration layer, on the theory that agents aligned on identical goals are worse at challenging bad requirements. If that argument holds for your workflow, a coordination layer makes misalignment visible at the cost of nudging everyone toward one plan — worth knowing before you install it. The wider context is that parallel agent use is no longer exotic: as of May–July 2026 the JetBrains Developer Ecosystem Survey reports 90% of professional developers using AI coding agents at work at least weekly and 68% daily (JetBrains), while GitKraken’s 2026 survey of 554 developers finds that 96.4% of teams have adopted AI coding tools and that only 20% of organizations measure productivity in any specific way, with 39% having no way to measure AI’s impact at all (GitKraken).
The short version
If you run more than one coding agent on one repository, Foremerge is the first tool reviewed here whose entire premise is the conflict Git structurally cannot see — and the mechanism works as documented at the CLI level: a HIGH destructive_vs_additive finding appeared the moment a second agent declared an additive change on a scope the first had declared destructive, before any code existed, and it was visible from a different worktree. It is also pre-1.0, has no published accuracy or rework benchmarks, only knows what agents bother to declare, and never blocks anything. Run it for the shared ledger and the audit trail; treat its silence as “nothing declared collides yet”, and keep your own gates where they are.