How to manage multiple Codex tasks
On this page
Give each task one outcome, one bounded area of change, and an explicit check. Run independent changes separately, then review the combined result before calling the feature complete.
A list of active Codex conversations does not tell you which feature is ready to ship. One run may be waiting for approval, another may have produced a diff, and a third may depend on changes that have not merged. Managing multiple Codex tasks means keeping the intended outcome, execution progress, and review decision connected.
This workflow uses an example settings feature. You can use the same method with a plain task list; Agentboard adds a shared board and execution history around your local Codex runs.
1. Split work by independent outcomes
Start with the change users should experience. Then identify the parts that can be reviewed independently. “Build settings” is too broad for a useful queue. “Validate the display name” and “Render a saved confirmation” have clearer boundaries.
| Task | Owned area | Dependency |
|---|---|---|
| Define display-name validation | Validation function and its tests | Agree on accepted input first |
| Add the settings form | Form component and component tests | Stable validation interface |
| Document account settings | User-facing documentation | Verified final behavior |
If two tasks need to redesign the same interface, decide that interface first. Separate files do not automatically mean independent work: a database migration and the code consuming it can still depend on each other. Put the dependency directly in the task description so it survives a handoff.
2. Make the brief reviewable before starting a run
A useful brief tells the agent what to change and gives the reviewer a way to reject an incomplete result. Include allowed scope, exclusions, acceptance criteria, and the checks available in the repository.
Goal: Validate the display name before saving account settings.
Scope: The existing validation module and its tests.
Behavior: Reject an empty or whitespace-only name; keep valid names unchanged.
Dependencies: Use the agreed validation interface. Do not redesign the form.
Done when: Tests cover empty, whitespace-only, and valid input.
Verification: Run the relevant existing test command from repository configuration.
Handoff: Summarize changed files, test results, and anything not verified.
If a requirement conflicts with existing behavior, explain it before expanding scope.Replace the example behavior with your actual product requirements. Do not paste guessed commands into every task. Have the agent read the repository configuration, and record which command actually ran. A green result from an unrelated test is not evidence that the task is complete.
3. Keep parallel edits in separate working directories
Two agents editing one checkout can mix changes before you have a chance to review them. Git worktrees provide separate working directories for branches of the same repository. OpenAI documents them as a way to run independent Codex work in parallel; see the official worktree guide.
In Agentboard, execution instructions ask Codex to create its own worktree and branch when isolation is needed. The application does not itself provision that worktree. Verify the agent’s chosen directory and branch before assuming the runs are isolated.
Isolation also has limits. Separate directories can still share a database, a service port, or an external account. Give concurrent development servers different ports, avoid competing writes to shared test data, and serialize changes that depend on the same migration or deployment. Keep the agent’s existing approval and sandbox controls in place.
4. Track the task and its runs separately
Use the board to answer “where is the work?” and execution history to answer “what happened during this attempt?” A task can need several follow-up turns. Keep those refinements connected to the same intended outcome rather than creating a new task for every instruction.
- Todo: the brief and its completion checks are ready.
- In Progress: implementation or a requested correction is underway.
- In Review: a reviewer has a concrete diff and verification results to inspect.
- Completed: the agreed completion criteria have been met.
In Agentboard, open the task’s Executions tab to inspect individual runs, status, turn count, available token usage, and plan progress. Respond to approvals on the machine running Codex. A finished execution is not, by itself, a reviewed change.
If you connect GitHub, set the project’s remote repository and associate the pull request with the task. A linked non-draft pull request can move a task to In Review; merging can move it to Completed. That automation reflects the PR lifecycle. The team still needs a meaningful review and merge policy.
5. Review one feature across several tasks
For the settings example, finish the validation contract first. The form task can then consume that stable contract while the documentation task drafts the explanation. Ask the documentation task to confirm the final UI before finishing.
When the form run ends, review the diff and exercise the actual invalid-name flow. If it saves whitespace, send a focused follow-up to that execution: describe the failing input, expected behavior, and check to repeat. Keep the task in progress until there is a corrected result to review.
After the component changes merge, verify the assembled feature again. Individually correct changes can still disagree at their boundary. If a later task used an older interface, update that task’s branch and rerun the relevant checks. The final decision should reference the combined behavior, not the number of successful agent runs.
Try the workflow in Agentboard
Start with one bounded task using the quickstart, then add a second independent task. Follow the task and execution guide to connect the board, execution history, and pull requests.
Check download availability and setup. Agentboard uses your local Codex installation and account. See plans and trial conditions before starting a workspace subscription.