Work

Work is where you plan with your best account and build with the right one. You describe the work, choose a folder, a planner, and a worker. The planner plans in its own Codex window. The worker builds in an isolated copy of your folder. You review and accept. Nothing merges without your review.

Start a run

1. Open Work. The composer asks What should we do? Describe the work in plain language.
2. Choose a Folder. Recent folders are listed; Choose folder… opens a picker. Choose the Git repository itself, not its parent folder.
3. Choose a Planner. This is the account whose Codex window reads your request and writes the plan. Use your best model here.
4. Choose a Worker. This is the account that builds. The first time you pair a worker with a folder, CodexUse asks you to Allow worker access: let this account read this folder and receive the plan. The choice is saved per folder.
5. Optional: open Checks and files to add Required checks, one command per line, and to review uncommitted files.
6. Click Start. The planner window opens. The worker window opens when the planner hands off.

CodexUse saves your default planner and default worker, so the next run needs only a description and a folder.

Planner and worker

The planner and the worker are both accounts from your Accounts tab, and each works in its own Codex window.

• The planner reads your request in its own window with your folder open, asks you questions if it needs to, and hands off a brief to the worker. Its window stays yours: you can read the transcript, answer questions, and keep talking to it.
• The worker receives the brief, not the planner’s transcript. It builds in an isolated Git worktree of your folder under a workspace-write sandbox, so it can edit files in its copy and cannot touch your checkout. Its live output streams to the worker card in the run.

A planner may also answer directly without handing off. The run then finishes as Planner finished without handing off, and you read its response in the planner window.

Folder and Git

A worker needs a Git repository, because the isolated copy is a Git worktree and the result is applied back as a change to your folder. If the folder is not a Git repository, the composer says so and offers the Folder menu to open that folder in an account’s Codex window without a worker. Opening a folder in an account’s window never needs Git.

Uncommitted files in your folder are not part of the worker’s copy by default. Turn on Include uncommitted files in Checks and files to send them, and use Review uncommitted files to see what that includes. If those files change after you reviewed them, CodexUse asks you to review them again before starting.

Allowed workers

• Any signed-in OpenAI account can be a worker once you allow it for the folder.
• A custom-model account can be a worker only if its verified provider route supports the coding tools a worker needs, and only after you allow third-party providers for that folder. The consent text names the provider and says that repository content is sent to it.
• A ChatGPT Web account can be a worker once CodexUse has verified its connector with a real turn. Its turns spend the Chat allowance, not the Codex allowance of any OpenAI account. See ChatGPT Web accounts.
• Choose separate planner and worker accounts. The planner’s window stays available while the worker builds in its own window.
• An account that is Needs sign-in or Needs setup cannot be chosen until you fix it.

Check commands

Required checks are commands that run in the worker’s copy before a result can be accepted, for example a test suite or a type check. Enter one command per line. Each run records the exit code and output of each check. When a check fails, the review sheet shows Some checks failed and the Accept button says Fix the failing checks first. You can send feedback to the worker or hand the job to a different worker from the same sheet.

Run and job states

Review and accept

When a job is Ready to review, open Review on the run. The review sheet lists every changed file with its diff, the output of each required check, and the worker’s summary. From there you can:

• Accept: apply the changes to your folder. The button says Applies to your folder. Nothing is pushed. The changes remain uncommitted in your working folder. Review and commit them yourself.
• Ask for changes: send feedback to the same worker, which continues in its copy.
• Different worker: hand the job to another allowed account.
• Stop the worker, or Remove the run and its worktrees.

Accept is disabled until all changes have loaded and every required check has passed. Nothing is merged without your approval, and nothing is pushed to a remote.

History

The left rail in Work is History: every local Codex run, from every account, in one list. Search it, filter by account, folder, status, or archived state. Show on any entry opens it in the Codex window of the account that owns it. If that account was removed, the entry says Account removed. History reads local Codex state only; it does not merge cloud histories or move a conversation to another account.

What Work does not do

• Work does not replace Codex’s native subagents. It adds a workflow across separate accounts and windows, with isolated worker worktrees and review before applying changes. The codex agents CLI command browses agent sessions.
• Work does not merge or push anything on its own. Accept applies the change to your local folder.
• Work does not give the worker the planner’s transcript. The worker gets the brief and the folder you allowed.
• Work does not create extra Codex quota. Each account’s requests count against that account.
• Work does not run on Intel Macs, Windows, or Linux. It needs the Apple Silicon desktop app.

Related