Codex CLI: running parallel agents and managing their tasks

OpenAI's Codex CLI has a property that makes it unusually easy to orchestrate: a non-interactive exec mode. Give it a prompt, it works the task in your repository and exits — which means anything that can launch a process can manage Codex agents: a shell loop, a tmux session, a worktree orchestrator, or a task board. The interesting question isn't whether you can run several at once; it's how you keep track of what each one is doing and whether the work actually ran.

The baseline: parallel Codex in plain git worktrees

The pattern is the same one that works for Claude Code (covered in depth in How to run multiple Claude Code agents on a Mac): one worktree per task, one agent per worktree.

git worktree add ../myapp-search feature/search
git worktree add ../myapp-emails feature/emails

cd ../myapp-search && codex   # tab 1
cd ../myapp-emails && codex   # tab 2

This scales to about three terminal tabs before the bookkeeping — which branch is which task, which run finished, which stalled — eats the speedup. Past that you want tooling that tracks tasks, not tabs.

Task management options for Codex agents

Every major orchestrator runs Codex alongside Claude Code:

• Claude Squad — despite the name, it manages Codex too: one tmux session + one worktree per agent, terminal-native.
• Vibe Kanban and Kanbots — Kanban boards over worktrees; Kanbots runs Codex in exec mode per card with a pre-push guard.
• Conductor and Superset — parallel-run UIs with diff-first review; Superset organizes by branch/PR rather than by task.
• PortBay — a Kanban board where the Codex card runs inside a provisioned local environment: managed runtime, per-project database, trusted HTTPS on a .test domain.

The first four manage where the code goes (worktrees, branches, diffs). Only the last manages what the code runs against— and that distinction decides how much of Codex's output you can trust without manually re-testing it. The full argument is in What is a dev environment for AI coding agents?

The Codex task loop on a board with an environment

In PortBay, Codex is one of the four detected agents (with Claude Code, Cursor and Antigravity). The task management loop:

1. Your project is already running — PortBay provisioned the runtime, database and HTTPS when you pressed play.
2. Write the task as a card. Assign Codex, or type @codex in a card comment with a directive.
3. Move the card to Todo. PortBay dispatches Codex against the running project; a lease moves the card to In Progress and stops a second agent claiming it.
4. Codex works where it can verify: the migration runs against the real database, https://yourapp.test loads, the password-reset email shows up in the local inbox.
5. The agent comments what it changed and advances the card to Done — an audit trail per task, not a scrollback buffer per tab.

You can also run Codex headless or in its own app per card — useful when one task needs supervision and five don't.

Mixing agents on one board

Once tasks are cards, the agent becomes a per-task choice rather than a tooling commitment. A realistic split: Codex on well-specified implementation cards, Claude Code on refactors that need more judgment, Cursor when you want to watch the run in an editor. Same board, same environment, same audit trail — and when the next CLI ships, it's a new assignee, not a new workflow.

Three rules that keep parallel Codex runs productive

• Scope cards to one surface. Two Codex agents editing the same module produce merge work that erases the parallelism. Split by route, package or feature boundary.
• Define done as verified.“Tests pass” is necessary, not sufficient. If the card says “the export downloads a valid CSV over HTTPS,” the agent needs an environment where that sentence is checkable.
• Review the description, then the diff.An agent that explains what it changed on the card is reviewable in minutes. Insist on it — it's the cheapest quality gate there is.