Coordination above the worktree layer (riff on Scott's parallel-CC post)

[swoofer]

Long-time reader of Scott's writing, and his recent post on running multiple Claude Code sessions without worktrees got me thinking.

His framing matches what I ran into: worktrees as the primary answer but not sufficient for everything. So I built something at the layer above. It's called mcp-coordinator, an MCP server with an embedded MQTT broker. Sessions announce intent before editing, conflicts are scored across all in-flight announces, and a consultation thread opens when impact crosses a threshold. Push delivery, cross-machine, peer-to-peer (no orchestrator required).

https://github.com/swoofer/mcp-coordinator (MIT, npm install -g, works with Claude Code, Cursor, Cline, Aider).

Not pitching. Sharing because it's adjacent enough to what GitButler does that there might be overlap in your user base. Two questions for the maintainers and the community:

1. Among GitButler users running multiple AI sessions in parallel, how often does the worktree boundary feel insufficient versus enough on its own? Genuinely curious where the line is in practice.

2. Would there ever be appetite for GitButler to surface 'another session is also touching this file' signals at the UI layer? mcp-coordinator's MQTT events would be straightforward to consume from a Tauri app if you wanted to experiment, but I don't have visibility into your roadmap.

Either way, thanks for the post. It nudged me to write up the differences cleanly.

[Byron]

Thanks a lot for sharing (and also, not pitching :))!

Let's see if @schacon or @krlvi have ideas about that, I also know that but-agentlog may try to solve a similar problem.