[dwattttt]

Multiple agents is definitely tempting fate. Concurrent modification of the same git repo by multiple entities?

At that point you should use multiple repos so they can merge & resolve.

EDIT: of course, if a single agent uses git to modify a repo instead of jj, jj may have trouble understanding what's happened. You could compare it to using an app that uses an sqlite db, and then also editing that db by hand.

[KingMob]

Sibling comment from gcr has the right details.

This doesn't involve git use at all.

Even with multiple workspaces (like git worktrees), once you use something like jjk, both the agent and jjk in the associated VS Code are operating on the same workspace, so that doesn't isolate enough. I don't think jjk uses `--ignore-working-copy` for read-only status updates, so it's snapshotting every time it checks the repo status while the agent is editing.

On top of that, throw in whatever Claude does if you "rewind" a conversation that also "reverts" the code, and agents wrongly deciding to work on code outside their focus area.

It's possible watchman helps (I need to look into that), but I'm so rarely using jj in VS Code (all I really want is inline blame), that it was easier to remove jjk than try to debug it all.

Divergence won't hide or lose any work, but it's an annoying time-suck to straighten out.

[vipdestiny]

MCP solves the wiring problem nicely, but once you have more than one coding agent running, coordination becomes the real bottleneck.

I ran into repeated issues with agents editing the same files, losing decisions, and drifting away from the spec. I ended up building a small Rust MCP server that adds task claiming, file-level locking, and drift checks against SPEC.md.

It’s intentionally boring infrastructure… single binary, file-based state, deterministic orchestration. The AI tools stay interchangeable.

Repo if anyone’s curious: https://github.com/nxtg-ai/forge-orchestrator

[arianvanp]

The point of jj is that it supports lockless concurrent writes to the same repo out of the box. It is what makes it a lot more suitable than git for agent workflows

[gcr]

The OP is talking about the `jj workspace create` command, which creates a separate working copy backed by the same repository. It’s not a bad way to work with multiple agents, but you do have to learn what to do about workspace divergence.

Like git, you don’t lose any history.