Keep parallel Codex tasks from colliding

1. Choose tasks that can make progress independently

Parallel work is useful when each task has a clear result and can be verified without waiting for another task to change the same files. For example, an isolated documentation update can run alongside a component fix. Two tasks redesigning the same component are much more likely to conflict.

Start with two tasks. Tell each one its objective, allowed files, shared interfaces, and completion check. More tasks add integration work; they do not automatically make a tightly coupled feature faster.

2. Separate the branch from the directory

Git worktrees allow multiple working directories attached to one repository. Each worktree has its own checked-out files and index. Creating a branch by itself does not create an isolated directory, and archiving a conversation does not integrate its code.

The desktop app documents a worktree workflow for parallel tasks. In the CLI, first open the correct working directory; Git can create the worktree before you start Codex there. Inspect existing worktrees so you do not accidentally target someone else's in-progress checkout.

git worktree list
git status --short --branch

Reference: Git: git worktree · OpenAI: Worktrees

3. Give each writer a known starting point

The following example creates a new branch and sibling directory from the current commit. Use it only from the intended repository, with an unused branch name and destination. Existing uncommitted changes are not copied into the new checkout.

After creating the worktree, inspect its branch and files, follow the repository's dependency setup, then start Codex there. Local configuration, ignored files, and development servers may need separate setup. Assign distinct local service ports if both checkouts run a server.

git worktree add -b guide-example ../guide-example
cd ../guide-example
git status --short --branch
codex

Reference: Git: git worktree

4. Review, integrate, then clean up

Review and verify each change in its own worktree. Then bring the chosen changes into the target branch one at a time using your repository's normal merge or review process. Run checks against the combined result: two independent passing changes can still conflict when combined.

Before removing a worktree, prove its intended changes are preserved in the target and inspect any uncommitted files. Do not force-delete it just to clear a branch-in-use error. A completed conversation, a clean directory, and a merged change are different facts.

• Know which task owns each working directory and branch.
• Keep independent task prompts and validation scoped to their assigned files.
• Review the combined result before releasing it.
• Remove only a worktree whose remaining state has a deliberate disposition.

Reference: Git: git worktree

Try it in Codex

Plan the isolation before creating it

Assess whether the current work would benefit from two independent tasks. Inspect the repository, Git status, branches, and existing worktrees read-only.

Propose clear objectives, file ownership, a shared base, and a completion check for each task. Explain any overlapping files or dependencies. Identify the intended integration branch and how the combined result would be tested.

Do not spawn agents, create tasks or worktrees, change branches, commit, merge, push, or delete anything. If the work is tightly coupled, recommend doing it sequentially.

Check your result

• Each task has its own working directory and an unambiguous branch.
• No task assumes it inherited another checkout's uncommitted changes.
• The combined result passes the checks relevant to both changes.
• Cleanup preserves all work that has not been deliberately discarded.

Sources and scope

Official references support the product behavior described above. The task prompts and practical checks are our community guidance.

• Git: git worktreeWorktree creation, separate working directories, branch constraints, and removal behavior.
• OpenAI: WorktreesThe desktop app's worktree workflow.

Something changed in your version? Send a correction with the guide URL, platform, and version. Leave out credentials and private project content.