Can two coding agents work on the same repository at once?

Yes, and most people run them in separate git worktrees so the checkouts do not collide. Each session records its own transcript; nothing shares context between them by default.

Why does my agent memory treat each worktree as a different project?

Because project identity is usually keyed on the working directory, and a worktree has a different path from the main checkout. Resolving worktrees back to the repository keeps one project instead of several.

How do I see what a parallel session already tried?

Search the shared history rather than the running session: an indexed transcript is readable while the other session is still going, so what it established is available without a live channel between them.

Several agents on one repository

same repository, separate worktrees, no idea about each other

Two agents on one repository is now ordinary: one grinding through a refactor in a worktree, another fixing something small on main, a third reviewing. They do not know about each other. Each writes its own transcript, each starts empty, and the second one cheerfully re-derives what the first worked out an hour ago.

The worktree trap

Parallel work usually means git worktree, and that quietly breaks project identity for anything keyed on the working directory. ~/src/api and ~/src/api-worktrees/fix-pool are the same repository and different paths, so a memory scoped by path sees two projects, and neither can see the other's history. Claude Code's own auto-memory has the same behaviour — anthropics/claude-code#81833.

The fix is to ask git rather than the path. deja resolves a directory's worktree roots and treats every one of them as the same project, so a session recorded in fix-pool is recalled while you work in api, and two unrelated repositories that happen to share a directory name stay apart because the full path still matches first.

What one session can see of another

Nothing, live — and that is the right default. But "live" is rarely what is needed: the useful thing is what the other session established, and that is already written to its transcript as it goes. Indexed, it is searchable while that session is still running:

deja "pool size"            # what the other session concluded, in your session
deja blame internal/pool.go # what has been decided about this file today
deja last --project api     # what has been running here, newest first

With recall wired in, a fresh session opens already knowing the project's recent decisions, whichever agent made them. That covers most of what people build an inter-agent channel for.

When you do want to hand work over

Moving a live piece of work is a different job from searching, and it does not need a protocol between the two tools: deja handoff --to codex packages what a session established — the problem, the conclusions, where it stopped — as text the next agent starts from. Switching agents covers that case in full.

What stays hard

Two agents editing the same files at the same time is a coordination problem, and no memory layer fixes it — worktrees and small scopes do. Ordering is not guaranteed either: an index sees a session when its transcript is written, so a conclusion reached seconds ago may not be searchable yet. And a session that never wrote its reasoning down cannot be read by anyone, human or agent.

Switching between agents · Finding the session you need · Which harness supports what