Hand a coding task to the Codex CLI and get a jobId back immediately — Codex runs in the background while you keep working. Two reasons to reach for it. One: the task is self-contained and slow (refactors, migrations, test writing, bulk edits across files), so running it in the background buys concurrency. Two: the task is self-contained and output-heavy (generating a lot of code, tests, or boilerplate), so letting Codex produce those tokens conserves your own usage — this reason holds even when the task is fast, because you and Codex bill separately. Codex edits files on disk directly in cwd, so treat the working tree as modified once the job finishes. Keep working while it runs; check codex_status when you need to and collect the answer with codex_result — don't re-check in a tight loop, since each check is a model turn. Still the wrong tool for a quick question you need answered right now, and for trivial triage or classification (relevance filtering, labelling, risky-or-not) send those to a local model instead — this returns a job id, not an answer, so anything cheaper to resolve another way should be. Model and reasoning effort are chosen automatically from the task text unless you set them; the choice and its reasoning come back in the response, and setting either one explicitly overrides it. Call codex_models to see what is available.

The execute half of plan→execute: you do the design thinking in this conversation, write a concrete step-by-step plan, and hand it here for Codex to carry out in the background — getting a jobId back immediately, exactly like codex_start. Codex is told the plan was authored by another model and to follow it faithfully rather than redesign: if a step is wrong or impossible it stops and reports in blockers instead of improvising, so you can revise and resume with codex_reply. Reach for this when the hard part was deciding what to do and the rest is faithful typing across files — it keeps the reasoning on your side and the output tokens on Codex's. Because the design is already done, the execution usually needs less reasoning effort than the planning did, so consider pinning a lower reasoningEffort unless individual steps are themselves subtle. The plan must be self-contained: Codex cannot see this conversation, so state every step, file, and acceptance check in the plan text itself. Keep working while it runs; check codex_status when you need to and collect the result with codex_result, which checks what Codex did against git — don't re-check in a tight loop, since each check is a model turn.

Report whether a job is still running and what it has done so far (commands run, files edited, latest messages). Cheap to call. Does not block — if the job is still running, it says so rather than waiting.

Collect a finished job's handoff: Codex's structured report (what it did, what it verified, what it left undone, how confident it is) alongside actualChanges — the file changes according to git, independent of what Codex claims. Trust actualChanges over the report when they disagree, and re-read any changed file before reasoning about it. If the job is still running this returns progress instead; it never blocks.

Send a follow-up into a finished job's Codex thread — corrections, review comments, 'you missed X', 'now do Y as well'. Codex retains everything from the original job, so this is far better than starting a fresh job that would begin cold. Returns a new jobId you collect exactly like codex_start — keep working while it runs rather than re-checking in a loop. The follow-up reuses the original job's working directory and sandbox.

Show the models this Codex install offers and the reasoning efforts each one accepts, read from Codex's own model index. Use it when you want to pin model or reasoningEffort on codex_start and need to know what is legal — the accepted efforts differ per model, and a value the model does not take fails the job rather than the call. Also reports how the index was obtained, so a stale or missing one is visible rather than silent.

Stop a running job and its child processes. Any file edits Codex already made stay on disk — cancelling does not roll anything back.

List known jobs, newest first, with their current state. Use this to find a jobId you lost track of, or to check whether anything is still running.