← Blog

How-to3 min read

Running two coding agents in one repository

Run a second Claude Code or Codex session on the same checkout and the two overwrite each other. Git worktrees let any Mirasim session start in its own.

A Mirasim session with its own file tree and editor for the workspace it runs inA Mirasim session with its own file tree and editor for the workspace it runs in

What actually goes wrong when two agents share a working tree

Running one coding agent in a repository is a solved problem, but running two at once is not. Both agents operate on the same working tree without knowing the other exists, overwriting and mixing each other's changes. Nothing crashes, which makes the failure quieter and worse: you end up with a diff that neither agent intended and no one can explain.

  1. Agent A is editing files

    Both agents operate in the same shared working tree

  2. Agent B checks out a branch

    Agent B may also stage a file that Agent A just rewrote

  3. Tests run on half-written changes

    Git raises no error while the two changes mix

  4. You get a diff neither agent intended
Clone the repo for each agent
Duplicates history and isolates branches
Run the agents one after another
Gives up the point of using two agents
Tell each: “Only these files”
No enforcement; agents can still cross

The three usual workarounds for running two agents in one repository—separate clones, taking turns, or verbal file rules—are all worse than they look.

Linked worktrees: give one repository several independent checkouts

Git has had the answer since version 2.5. Running git worktree add creates another working directory backed by the same object database and refs—a second checkout, not a second repository. Each worktree sits on its own branch with its own index and HEAD, so two agents working in separate worktrees cannot see each other's uncommitted changes, stage each other's files, or switch each other's branch.

One shared Git repositoryAll worktrees share the objects, history, remotes, and branches
  • ../feature-a
    1. Worktree checked out on branch feature-a
    2. Has its own staging index and HEAD
    3. Agent A edits files here in isolation
  • ../feature-b
    1. Worktree checked out on branch feature-b
    2. Has its own staging index and HEAD
    3. Agent B edits files here in isolation
Because the worktrees share everything that is expensive to copy, the work stays mergeable: Agent A can branch from what Agent B pushed an hour ago, and you can review both diffs against the same base.
You can set up the same isolation by hand in the terminal by creating a separate linked worktree and branch for each coding agent.
# one repository, two checkouts, two branches
git worktree add ../feature-a -b feature-a
git worktree add ../feature-b -b feature-b

# each has its own HEAD and index; the objects are shared
git worktree list

Why Mirasim builds linked worktrees into sessions

Managing worktrees by hand
In a Mirasim session
Creating a worktree
Run git worktree add manually for one branch at a time
Pick a base branch and start the session in its own worktree
Tracking branches and files
You have to remember which terminal is on which branch
Each pane shows that worktree's files, terminal, diff, and commits
How agents stay isolated
Relies on each agent obeying a rule not to touch other directories
Each pane works in its own isolated worktree directory
Merging the agents' changes
You review the diffs and merge the branches yourself
You still review the diffs and merge the branches yourself
Managing worktrees by hand works for two branches but gets tedious for six, whereas Mirasim lets you run several sessions at once, each isolated in its own worktree.

Parallel sessions in Mirasim mean several coding agents working at the same time, each on its own task. Mirasim does not act as an orchestrator that splits one task among worker agents. Nothing plans across panes or merges their code for you—you review the diffs side by side and merge them yourself.

Keep reading