warn or lock: what should happen when two agents edit the same file?
i'm alim, one of the makers of agentmash. we launched today and i keep going back and forth on one design call.
in august two of our agents collided on payments code. fixing prod OAuth took 10 hours. worktrees keep agents out of each other's folders, not each other's code.
so we built a hook: before Claude Code or Codex edits a file, it asks your team's room who else is in it. if a teammate's agent changed or is changing it, yours gets a short note first: who, which file and branch, what they were doing.
the other option is a lock. my worry: a hard block gets turned off within a week, and many overlaps are fine once both sides know. so nothing is locked by default. opt-in strict mode holds the edit until the agent writes why both changes can stand, and your teammate sees it.
in 48 Claude Code test runs, agentmash flagged 18 of 18 overlaps before merge (0 of 18 without), with 0 false alarms in 6 control runs.
https://www.producthunt.com/prod...
if your agent and a teammate's were about to change the same file, would you want a note, a lock, or something else, and why?
Replies
A warning makes sense for separate branches. In a shared working directory I'd hold the second write until it has read the first change. A written justification alone doesn't show that the edits still fit together.
A note by default, lock only in opt-in strict mode, feels right for same-file collisions. But the case that actually bit me running a voice agent stack wasn't two agents touching the same file, it was two agents touching different files that both quietly assumed the same API contract. One changed a webhook payload shape, another changed how a downstream handler parsed it, neither file overlapped so nothing warned anyone, and it only surfaced at runtime. Same-file locking won't catch that. Have you thought about flagging overlap at the level of "these two diffs touch the same interface/schema" rather than just "same file", or is that out of scope for v1?
Note by default for me — a lock is something I'd route around within a week — but the note has to land before the edit and say what the other agent is trying to do, not just which file it's in. For the payments/OAuth paths from your August example I'd flip it: make those strict by default, since a 10-hour prod fix is exactly the cost a hard stop is meant to prevent.
I'd go lock even though warn sounds friendlier. I know I'd click past a warning on a busy day, and payments code is where I'd least want that to happen.