Codex CLI Worktree: Keep Parallel Tasks Separate

A Git worktree lets you check out a second branch of your repository in a separate directory, alongside your main working directory. When you run Codex CLI inside that directory, it sees only that branch, so changes in one task cannot interfere with another. Each session is isolated; the underlying repository is shared.

For teams, the harder problem is staying coordinated across those parallel sessions. fenbs keeps each task, its plan, and Where we left off visible to every team member and every connected assistant, so parallel work does not turn into a parallel set of surprises.

Why worktrees help with Codex CLI

If you run two Codex CLI sessions in the same directory at the same time, they both read and write the same files. One session's changes can conflict with the other's, and it is hard to tell which session made which edit. A worktree moves each session into its own directory on a dedicated branch, so the files are physically separate.

You can also use worktrees to let a second session continue while you review the first. While you read through the changes on one branch, another Codex CLI session works on a different problem in a different directory. Both sessions share the same .git folder, so there is no disk overhead of a full clone.

The codex subagents pattern often pairs well with worktrees: one subagent per worktree, each on its own branch, reporting results to a shared task record when done.

Create a worktree for a parallel task

From the root of your repository, create a new worktree on a new branch:

git worktree add ../my-project-fix-login fix/login-validation

This creates a directory called my-project-fix-login one level above your project, checked out on a new branch called fix/login-validation. If the branch already exists, omit the branch name and Git checks it out directly.

You can create the worktree anywhere, including inside your project directory if your .gitignore excludes it. A sibling directory at the same level is a common choice because it keeps things easy to find.

Run Codex CLI in the worktree

Open a new terminal window, navigate to the worktree directory, and run codex there:

cd ../my-project-fix-login
codex

The session runs on the fix/login-validation branch. Changes Codex CLI makes in this directory stay on that branch and do not touch your main working directory. Your other terminal window, on the main branch, is unaffected.

Each worktree needs its own installed dependencies if your project requires a build step. Run your install command in the worktree directory before starting Codex CLI.

Review the work from a worktree session

When the session ends, review the diff the same way you would for any branch:

cd ../my-project-fix-login
git diff main

You can open pull requests from a worktree branch, run tests, or merge directly. The worktree is a real checkout of the repository, so all standard Git operations work.

If the session produced something useful but incomplete, update the task record in fenbs with what was done and what remains. The next session, in the same worktree or a fresh one on the same branch, reads that note instead of repeating the investigation.

Remove a finished worktree

Once you have merged or abandoned the branch, clean up the worktree:

git worktree remove ../my-project-fix-login

If the directory has untracked files, add --force. After removing, prune the internal worktree metadata: git worktree prune. List all active worktrees at any time with git worktree list.

Keep the team picture clear

Parallel sessions make the team picture harder to read. One developer may have three worktrees active; another has two; a third is reviewing. Without a shared record, nobody knows what is ready, what is still running, or what is blocked waiting for a decision.

Map each worktree to a task in your shared record. When a session starts, move the task to In Progress. When it saves progress, the note says which branch, what was done, and what remains. That makes each parallel stream visible to the whole team without a status meeting.

After any session ends, a teammate can open the board, read the progress note on that task, and understand exactly where the branch stands: what was completed, what still needs review, and whether anything is blocked on a decision. That replaces the back-and-forth of asking each person what they are working on.

How to do this with fenbs

1. Create a free account. For a team project, use a team workspace so all members can see the board.
2. Create a task for each parallel piece of work. Add a short plan describing the goal, the branch name, and any rules that apply.
3. Connect Codex CLI to fenbs from Integrations and ask it to read the task plan at the start of each worktree session.
4. When a session ends, ask Codex CLI to save progress on that task: what it did, what it checked, and the next step.
5. Use the kanban board to track which tasks are active, which are waiting for review, and which are done. Members can comment or move tasks without opening a terminal.

The codex cli commands guide covers the full set of CLI options if you want to customize how each worktree session starts.