cd /news/ai-agents/coding-agents-stop-mid-task-our-coor… · home › topics › ai-agents › article
[ARTICLE · art-162580] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

Coding agents stop mid-task. Our coordination store had 3,896 stale conflicts

The Foremerge project released version 0.6.0 of its coding-agent coordination store, fixing a flaw where abandoned agent intents were treated as live and generated stale conflicts — one internal repository accumulated 3,896 open conflicts, 98% of them with no active agent on either side. The release adds a stopped-work rule that moves intents whose agents have been quiet for two hours into a marked related_work section, and removes automatic ledger schema migration on open in favor of an explicit, backup-first `foremerge ledger migrate` command.

by read4 min views2 publishedNov 2, 2026

Foremerge records what each coding agent plans to change before it edits anything, and raises a finding when two plans cannot both be true. That only works if the record is current. Version 0.6.0 fixes the way it was not.

An agent session ends without closing its intent far more often than you would guess. A context window fills up. A laptop lid closes. A scheduled run reaches the end of its slot. The intent the agent published stays open, its claims expire, and nobody closes it.

Foremerge treated that abandoned work as live. Every later intent on the same files was compared against it, and each comparison that found something was recorded. One of our own repositories, where scheduled agents and interactive sessions share a single coordination store, reached 3,896 open conflicts, 98% of them with no live agent on either side. A new intent on a busy file opened with about 40 recorded against it, and the ones worth reading were buried in the ones that were not.

This is a problem you only get from running several agents at once over a long period. One agent, one session, and the record stays tidy by accident.

work adopt already applied: it sits in INTENT, CLAIMED, IN_PROGRESS or PROVISIONAL, it holds no live claim, and its agent has made no Foremerge call for two hours.related_work, last, marked with owner_stopped_since, and needs no assessment. Another agent can see it there and adopt it. A what-if check_conflicts applies the same rule and names what it left out under stopped_work. discard_work description now tell an agent to close its intent before it stops. Work that reached Git without going through acceptance, because no named check is registered or a maintainer committed a batch by hand, can be closed with foremerge work discard --landed REF. HIGH findings gate acceptance, and an agent that was only quiet must not lose that protection. So the gate is unchanged. A stopped intent whose declared plan genuinely contradicts yours still asserts, and you still have to deal with it before your ChangeSet is accepted. The rule only removes the advisory noise underneath that line.

Before, a new intent on a crowded file came back with a long list of recorded conflicts, most of them against intents whose agents had been gone for days, and nothing in the list told you which was which. Now the same intent comes back with the live findings only. The stopped work is still there at the end of related_work, each entry carrying owner_stopped_since with the time its agent went quiet, so you can see what was set aside and pick it up if it is worth finishing.

Conflicts already on record are not touched by the upgrade. To clear a backlog like ours, close the stopped intents.

Foremerge used to migrate a ledger's schema as a side effect of opening it, and every command opens the ledger, including the ones that only read. A status run by a newer binary from the wrong directory migrated a real repository's shared coordination store and locked every older client out of it.

Foremerge no longer migrates on open. A command that meets an older ledger refuses it with MIGRATION_REQUIRED and leaves the file exactly as it was. foremerge ledger migrate does the migration and nothing else does: it refuses to run while another process has the ledger open, copies the ledger with its WAL contents into a timestamped backup directory, checks the copy's integrity, migrates, and prints how to roll back. Without --yes it only reports what it would do.

The schema itself has not changed since 0.4.0, so upgrading from any 0.4.x or 0.5.x build needs no migration and both versions read the same store. Only a ledger last opened by 0.3.x needs the step. This is why 0.6.0 is a minor version rather than a patch.

curl -fsSL https://foremerge.com/install.sh | sh

That installs a checksum-verified release binary on macOS and Linux. On npm, which also covers Windows x64:

npm install -g foremerge

The full list of changes is in the 0.6.0 release notes.

If you are building coordination for agents, the failure mode to design for is not the agent that disagrees with another agent. It is the agent that never comes back. Human collaborators close their tickets, eventually, because somebody asks them to. An agent whose process exited has no such pressure, and a store that assumes otherwise will slowly fill with work that nobody is doing and nobody will ever withdraw.

── more in #ai-agents 4 stories · sorted by recency
── more on @foremerge 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/coding-agents-stop-m…] indexed:0 read:4min 2026-11-02 · —