Is GitButler suitable for parallel multi-agent workflows? (Isolation concerns)

[wh5938316]

I'm exploring using GitButler to manage multiple AI coding agents (e.g., Claude Code) working on the same repository simultaneously. I have some concerns about the isolation model and would appreciate clarification.

My understanding of the current behavior:

• Virtual branches are logical constructs — they track which diffs belong to which branch
• However, all applied virtual branches share the same physical workspace
• This means if Agent A and Agent B are both working, their changes coexist in the same directory

My concerns:

1. File conflicts: If both agents modify the same file simultaneously, one will overwrite the other's changes before GitButler can assign the diffs
2. Runtime interference: When running/testing code, the workspace contains a mix of changes from all applied branches, which may cause unexpected behavior
3. No true isolation: Unlike git worktree, there's no physical separation between agents' work

Questions:

1. Is my understanding correct, or am I missing something about how GitButler handles this?
2. Is parallel multi-agent collaboration (with potential file overlap) a supported use case today?
3. If not currently supported, is there any plan to address this? For example:
   • Multiple workspace support?
   • Integration with git worktree?
   • Some other isolation mechanism?

I love Gitbutler and would be excited to use it for real parallel workflows. Thanks for any insights!

[Byron]

Thanks for posting!

Is my understanding correct, or am I missing something about how GitButler handles this?

Yes, it is correct.

Is parallel multi-agent collaboration (with potential file overlap) a supported use case today?

Overlapping areas can definitely lead to problems related to races and interference.

If not currently supported, is there any plan to address this?

Actually, I don't know about a timeline, but I do know that worktrees are supposed to be standard bread and butter. See this issue for more information.

Also CC @krlvi who is probably closer to the pulse of this.