Foremerge stops parallel coding agents from breaking each other's architecture
Running multiple coding agents on a single repo using parallel worktrees usually leads to a nightmare at the PR stage. Git is great at catching line-level conflicts, but it's blind to "intent conflicts"—like one agent replacing a class while another is trying to extend it. By the time a human reviewer notices the architectural mismatch, hours of compute and time have been wasted.
Foremerge solves this by adding a coordination layer on top of git. It doesn't touch your git history or use merge drivers; instead, agents must publish their intent and scope before they start editing. If two agents target the same symbol with conflicting operations, the system flags it before a single line of code is even written.
How the intent system handles conflicts
The tool uses a deterministic matching system rather than a "judge" LLM to decide if there's a clash. It relies on declared operations. For example, if you have two agents running, you'd see something like this:
foremerge intent publish --agent "$A" \
--summary "Replace PaymentService with StripePaymentService" \
--scope symbol:PaymentService=replace
foremerge intent publish --agent "$B" \
--summary "Add PayPal support to PaymentService" \
--scope symbol:PaymentService=extend
In this scenario, the second agent's publish command would trigger a "HIGH destructive_vs_additive" finding. These aren't hard locks that cause deadlocks, but advisory leases. The shared state is kept in a simple SQLite file within the git common directory.
Integration and performance benchmarks
The project is a Rust binary that includes a CLI and an MCP server with 18 different tools. You can wire it into Cursor, Codex, and Claude Code by running foremerge setup all. Since the protocol isn't tied to a specific provider, a Claude agent and a Codex agent can actually coordinate through the same store.
Regarding scale, the team tested this with up to 98 parallel agents on one repo and hit zero conflicts (they aimed for 100, but two agents crashed due to resource limits). In a real-world replay of 76 intents from a previous build, it correctly flagged the one actual conflict present. One limitation discovered was a "blind spot" where one agent claimed a scope by class name and another used an internal method; that's currently being patched for the next release.
Getting it running
The installation is fast and doesn't require complex configuration. You can get it set up in about 30 seconds using one of these methods:
curl -fsSL https://foremerge.com/install.sh | sh
or
cargo install --locked foremerge
After the binary is installed, you just need to run foremerge init && foremerge setup all inside your repository.
The project is released under the Apache-2.0 license. It also implements a named check system that verifies the git state of a change; an agent cannot simply claim "tests pass" to get through the gate—the check must be executed independently to satisfy the acceptance criteria.
https://github.com/naw103/foremerge
I'm curious if this actually handles dependency hell. I've seen 403 errors when multiple agents try updating the same lockfile.