Delegating to Codex Cloud

When you run codex in your terminal, the agent works on your machine — your files, your CPU, your shell. That's perfect for a tight back-and-forth, but it ties up your laptop and your attention for the whole run.

Codex cloud is the same agent, relocated. Instead of acting on your local checkout, it spins up a fresh cloud sandbox container, clones your repo into it at a branch or commit, and does the work there — while you carry on with something else. Think of it less like running a command and more like delegating a ticket to a remote teammate: you write a clear brief, hand it off, and check back on the result.

Two properties make this more than "the same thing, but slower to reach":

• It runs in the background. Once you submit, you're free. The task keeps going whether or not your terminal, IDE, or laptop stays open.
• It runs in parallel. Each task gets its own container, so you can have several cloud tasks churning at once — three independent bug fixes, or four attempts at the same hard problem — without them stepping on each other.

Every surface (web, mobile, IDE, GitHub, CLI) shares one ChatGPT account, so a task you start from the CLI is the same task you can monitor on the web or steer from your phone. The entry point is chatgpt.com/codex, and cloud needs a connected GitHub account so it can read the repo and open pull requests.

The word isolated is doing real work in "isolated sandbox container." Each cloud task runs in a container that is separate from your machine and separate from every other task, and that buys you three things at once:

Isolation is also a security boundary. During the agent phase, the container's internet access is off by default — a deliberate guardrail against prompt injection and credential exfiltration from untrusted content the agent might read. (Setup scripts keep internet on so dependencies can install; the agent phase is the locked-down part.) You configure environments — base image, setup scripts, secrets, and that internet policy — per environment, and the next lesson covers them in depth. For now, the takeaway is simply: delegated work runs in a clean, contained, network-restricted box, not on your laptop.

There's no single "cloud button" — Codex meets you wherever you already are. All five routes start the same kind of background task in the same kind of container; they differ only in where you are standing when you hand it off.

The IDE route is the one worth flagging now: when a local task balloons into something long-running, you don't have to abandon it. "Run in the cloud" hands the task — with its context — to a cloud environment, lets you monitor and ask follow-ups without leaving the editor, and then apply the resulting diffs locally. The local-to-cloud handoff (and back) is covered fully in the IDE lesson; here we focus on the CLI route, because it's the most scriptable.

The terminal is the most precise way to delegate, because every option is explicit. Two commands cover it.

codex cloud with no subcommand opens an interactive picker — the easiest way to browse environments and recent tasks and start one by hand:

codex cloud

codex cloud exec submits a task directly — ideal for scripts and one-liners:

codex cloud exec --env ENV_ID --attempts 3 "Summarize open bugs and propose fixes"

The pieces that matter:

Best-of-N is the cloud's superpower. Locally, you get one shot per run; in the cloud, --attempts 3 spins up three isolated containers working the same brief at once and lets you compare diffs and keep the strongest. For genuinely hard problems where the first solution is often not the best, that parallelism is exactly what you're paying the cloud for.

Because this is the same auth as the rest of the CLI, no extra login is needed — your ChatGPT sign-in or API key already authorizes cloud tasks.

Delegating is half the loop; collecting the result is the other half. Two commands close it.

codex cloud list shows your recent cloud tasks — handy for scripting, dashboards, or just remembering what you fired off:

codex cloud list --env ENV_ID --limit 10 --json

The --json output includes fields like id, url, title, status, updated_at, environment_label, summary, and is_review — enough to build your own "what's running" view.

When a task finishes, you pull its changes into your local working tree with codex apply (alias codex a), passing the task's ID:

codex apply TASK_ID      # or: codex a TASK_ID

That lands the cloud diff on your machine so you can run it, test it, and finish it locally — the cloud did the heavy lifting, and you take it over the last mile. The mental flow is a clean delegate-and-collect loop:

codex cloud exec  ──▶  task runs in cloud container
        │                       │
        ▼                       ▼
   codex cloud list  ◀──  monitor status
        │
        ▼
   codex apply TASK_ID  ──▶  diff in your working tree  ──▶  test & finish locally

Cloud tasks don't just leave a diff floating in a container — they're built to feed your normal review workflow. After a task runs, Codex creates a pull request directly in the connected GitHub repo, and you review the change in the cloud diff view before it ever touches main.

This is why the GitHub connection is a prerequisite, not a nicety: it's what lets a background task end as a reviewable PR on a branch instead of an orphaned set of edits. Your options from there:

• Review in the cloud diff view — read the file-change diff Codex produced, right where the task ran.
• Open the PR — Codex pushes a branch and opens the pull request in the connected repo; review it like any teammate's.
• Pull it down to test — git fetch and git checkout the branch (or codex apply TASK_ID) to run it locally before approving.

The result is that delegation slots into the process you already trust: a human reviews a diff and a PR before anything merges. The agent did the work in isolation; the gate is still your review. (Automated code review — where @codex reviews other people's PRs — is a separate capability covered in its own lesson; here, the PR is the output of your delegated task.)

Both surfaces run the same agent, so the choice is about the shape of the work, not its difficulty.

Stay local when the work is interactive, latency-sensitive, or control-heavy — you want to watch each turn, steer mid-flight, iterate in seconds, or you're exploring and don't yet know what "done" looks like. The tight feedback loop is the point.

Go to the cloud for heavy, fire-and-forget work — long migrations, deep cross-cutting refactors, or parallel batches where you want several independent tasks (or several attempts at one hard task) running at once while you do something else. You're trading immediacy for throughput and a clean, isolated environment.

Two practical constraints to plan around. First, local messages and cloud tasks share one rolling 5-hour usage window (plus weekly limits) — delegating to the cloud spends from the same budget as local work, so it's not "free" headroom. Second, cloud access is included with Plus, Pro, Business, Edu, and Enterprise plans; Enterprise workspaces may need admin setup first. Both the window mechanics and the plan list are volatile — confirm them live.