choosing your setup

which setup fits my work?

my interest in Codex centers on keeping multiple projects, tasks, and contexts moving through one authoritative thread. that thread routes clearer prompts and instructions to the tasks doing the work. the coordination example explains the division.

that gives this page a practical lens: choose the setup that makes the work easy to locate, steer, and inspect. the following starting points depend on the job and review surface.

your work	a useful starting point
one repository change with a concrete test	CLI or editor, repository instructions, and the test command
several projects with separate implementation tasks	desktop task view and explicit ownership
an independent change beside unfinished local work	a dedicated worktree with its own setup
work you need to steer away from your desk	Remote connected to the host that has the environment
work suited to a separate hosted environment	Codex cloud with documented setup and verification

these options can be combined. a phone can steer a task whose worktree lives on another computer. the choice of screen and the choice of execution host answer different questions. the remote guide and cloud guide explain those environments.

when do more agents help?

start with a task you know how to judge. when it contains independent questions, give them to subagents with clear ownership and a useful result to return. an API investigation and a UI investigation can often progress together. an implementation waiting on an undecided API contract should wait for that decision.

for a trial, ask two agents to inspect different risks in the same patch. compare their findings against your own review. then try a split implementation with separate files or worktrees. check the integrated behavior before increasing the amount of parallel work.

the benefit is the time saved reaching a correct result. extra summaries, duplicate investigations, and conflicting patches count against that benefit.

when should i add an extension?

the capabilities i’m interested in include creating and messaging tasks, reading their histories, checking current activity, and archiving completed work. i’m also interested in changing the setup: instructions, configuration, environment, and potentially the harness code.

for a recurring procedure, begin with a skill. connect a service when the procedure needs current external state. use a hook for a check tied to a specific event. the extensions chapter explains how these pieces fit together.

OpenAI publishes the CLI, SDK, and app server as open source. modifying that source also means maintaining and running the changed implementation. choose that route when a concrete limitation warrants the maintenance, and keep a way to compare your change with the upstream behavior.

how do i compare setups?

choose a task that resembles your actual work. record how long it takes to reach a reviewable result, what you needed to correct, which checks passed, and how much steering it required. compare one change at a time: surface, model, reasoning effort, or delegation pattern.

this gives a paid plan or more elaborate setup a practical test. use the limits shown in your own account, because available models and allowances can change. a setup is worth keeping when the improvement survives review and recurs across the work you actually do.

keep the result easy to inspect

before carrying a setup into a larger project, make sure you can answer four questions: where is the work running, which task owns it, what can that task reach, and what demonstrates that it finished? those answers make the next change easier to supervise, whether you use one agent or several.