Can Claude Code and Codex Work on the Same Repo at the Same Time?
Opening two terminals is easy.
Keeping two agents from landing on the same file, and giving both of them the same team knowledge, is the part that decides whether parallel work is faster or just noisier.
Short answer
Yes, but only if each agent gets its own git checkout. Sharing one working copy means the second agent edits files the first is midway through changing. A worktree also sits outside the folder you bound as your workspace, so an isolated agent has to be resolved back to it or it starts with none of your team knowledge.
What this covers
- In Pathrule Studio each chat session is a tab with its own agent and its own run state, and any session can be given its own branch and its own checkout, opt-in per conversation.
- The problem people miss is context: a worktree lives outside the folder you bound as the workspace, so naively an agent working there resolves to no workspace and receives no team knowledge at all.
- Pathrule resolves an isolated checkout back to its workspace, so a parallel agent receives the same path-scoped memories, rules and skills as one in the main checkout. A parallel agent is not a context-blind one.
- Isolation alone is now common. What still varies between tools is whether the work gets landed: Studio merges the branch or opens a pull request from Source Control, with the desktop running git and gh rather than the model.
Comparison
| The question | Two terminals in one checkout | A checkout per session |
|---|---|---|
| Who owns the working copy | Both, at once | Each agent owns its own |
| What happens on a conflicting edit | Last write wins, silently | Nothing: the files are separate |
| Can you keep working meanwhile | No, your copy is being edited | Yes, your copy is untouched |
| Branch state | One branch for everyone | A branch per session |
| Getting the work back | Already there, for better or worse | Merge or a pull request, deliberately |
Starting two agents is not the problem
You can run Claude Code in one terminal and Codex in another today. Nothing stops you. The reason most teams try it once and go back to a single agent is not that it fails to start; it is what happens twenty minutes in.
Two agents in one working copy are two writers with no lock. One is refactoring an auth helper while the other is editing the file that imports it. Neither is doing anything wrong. The repository is simply not a data structure that supports two concurrent authors, and git will not save you, because nothing has been committed yet.
So the first requirement of parallel agents is boring and physical: each one needs its own copy of the files.
A checkout per session, opt-in
In Pathrule Studio, chat is not one session. It is a set of tabs, and each tab carries its own agent and its own run state, so the strip tells you which agents are working and which are waiting on you. Tabs are tracked above the workspace they belong to, so switching workspace does not end a long run and switching back finds it still going.
Any one of those sessions can be given its own branch and its own checkout of the repository. It is opt-in per conversation rather than a mode you switch the app into, so the default stays your main checkout and nothing about a single-agent session changes when you are not using it.
Arming that before you send the first message matters more than it sounds. The branch is cut and dependencies start installing while you are still typing, so the first message does not wait. After that message the choice locks, because an engine's working directory is fixed for the life of its conversation.
The part everyone gets wrong
Here is the failure that is easy to miss until you hit it. A worktree lives outside the folder you attached as your workspace. A context layer that resolves knowledge by asking which workspace this folder belongs to will answer: none. The agent in the isolated checkout then works with no memories, no rules and no skills, which is exactly the agent you were trying not to have.
Pathrule resolves an isolated checkout back to its workspace, so the parallel agent receives the same path-scoped knowledge as the one in your main copy. The rule that says coupons live on the line item reaches both. The skill that describes your release checklist reaches both.
That is the sentence worth keeping: a parallel agent is not a context-blind one. Isolation without it just distributes the ignorance.
Landing is part of the feature
Isolation has become common, and that is a good thing for everyone. What still differs between tools is what happens when the work is done. A branch sitting in a worktree is not a contribution; it is a promise.
Studio lands it from Source Control: a merge, with squash offered first alongside fast-forward and merge commit, or a pull request opened through the GitHub CLI. The desktop runs git and gh itself rather than asking the model to, a conflict stops and names the files it stopped on and leaves your main working copy untouched, and after a merge Studio offers to reclaim the disk the checkout was using.
Branch names are generated in the background from your first message, in English, shaped to whatever convention the repository already uses, with a namespace per engine so you can tell at a glance which agent produced which branch.
When to reach for it, and when not to
Parallel agents pay off when the work genuinely separates: a migration in one place and a bug fix in another, or two independent features. They cost more than they return when the tasks touch the same files, because you will spend the time you saved on a merge.
On the Tasks board that judgement is automatic rather than yours to make. With parallel runs on, groups predicted to touch different files run at the same time in separate worktrees, and groups predicted to collide are merged into one sequential lane. That is the same instinct, applied by something that has read the plan.
If you want to try it, isolation is opt-in per conversation and free to turn on. The [Chat block on the features page](/features#chat) shows where it lives, and the [isolated branches documentation](/docs/studio/isolated-branches) covers the setup command, the ignored-file copy and the landing step in detail.