Codex Cloud: Delegate Tasks From GitHub, Slack, Linear

- The plan gate, internet-access defaults, and Slack/Linear trigger syntax below were cross-checked against official docs at the time of writing; this surface changes fast, so verify the live docs before you depend on them.

What is Codex Cloud?

Codex Cloud is one of three surfaces that share the same underlying agent - alongside the CLI you run in your terminal and the IDE extension. The core difference: every Cloud task runs inside its own isolated container, with repo access, a shell, and a test runner - none of it touches your machine. The official docs put it plainly: "Delegate work to Codex in isolated cloud environments" (learn.chatgpt.com/docs/cloud).

For the full picture of all three surfaces before you read on, see what OpenAI Codex is. One line to avoid confusion: Codex Cloud is a Codex feature, entirely different from OpenAI's own "AgentKit" (Agent Builder) - the full three-way disambiguation lives in that hub article, not repeated here.

One practical implication worth stating plainly: because each task gets its own container, a Cloud task is effectively disposable infrastructure. Nothing it installs, caches, or breaks persists once the task ends, and nothing it does can leak sideways into a different task's container. That's the trade you're making versus the CLI, where everything runs directly against your working directory and whatever state already exists there.

CLI vs Cloud vs IDE - which one to use

All three surfaces share the same agent but fit different situations. Here's the decision table so you don't have to piece it together from scattered docs:

Quick rule of thumb: if you're at the keyboard and want to see the result immediately, use the CLI or the IDE. If you want to delegate a batch of small jobs - a dependency bump, a small bug fix, tests for one module - and don't want to tie up your machine waiting, push it to Cloud and go do something else.

In practice most people who use all three don't pick one and stick with it - they switch per task. A gnarly refactor that needs constant back-and-forth stays on the CLI. A pile of small, independent chores gets fanned out to Cloud so five of them run at once instead of one after another. And the IDE extension gets used less for kicking off work and more for the moment right after: skimming a diff Codex already produced without tabbing over to a browser or a terminal.

How Codex Cloud sandboxes actually work

Every Cloud task gets its own container: Codex checks out the connected GitHub repo, runs a setup script (which still has network access to install dependencies), and only then does the actual agent phase start. During that agent phase, internet access is off by default - you choose an allowlist preset: none (fully off), common-dependencies (common package registries allowed), or all (fully open). Source: learn.chatgpt.com/docs/cloud/internet-access - worth re-verifying before you rely on the exact preset behavior, since it can change.

The reason for isolating each task this way is fairly simple: it lets OpenAI run an arbitrary number of tasks at once, from different repos, different users, different companies, without one task's dependency install or runaway process affecting another. For you, the practical benefit is that you can fire off a dozen small delegated tasks in one afternoon without worrying that one flaky `npm install` will corrupt the environment the next task depends on - each one starts clean.

Don't conflate the two "sandbox" meanings. The Cloud sandbox described here (an isolated container) is a completely different concept from the Codex CLI's local sandbox permission mode (read-only/workspace-write/danger-full-access - what a local CLI session is allowed to touch on your disk). Both use the word "sandbox," but they are two unrelated mechanisms. For the local permission levels, see local sandbox permission modes.

Connect Codex Cloud - GitHub, Slack, Linear

GitHub

Connect your GitHub account, choose which repos Codex may access, then create an environment for each repo (or repo group): declare dependencies, tools to install, environment variables, and secrets. This environment is what Codex Cloud reuses every time it runs a task against that repo - set up once, reuse many times. Source: learn.chatgpt.com/docs/cloud.

You're not limited to one environment per repo. A monorepo with a frontend and a backend service, for instance, is a reasonable case for two separate environments with different dependency sets, so a task scoped to the frontend doesn't spend setup time installing backend tooling it will never use. Getting this right up front is worth the few extra minutes - it's the difference between a task that starts working in seconds and one that spends most of its runtime just installing packages.

Slack

Requires a Plus plan or higher, a connected GitHub account, and at least one environment already set up. A workspace admin installs the Codex app for Slack, and after that anyone can delegate work by mentioning @Codex in a channel or thread - something like "@Codex fix the null pointer in org/repo" (this is an illustrative example, not a verbatim doc quote - confirm the exact syntax before publishing it as a quote). Codex reacts with a 👀 emoji, posts a link to track the task, then replies in the same thread with the result. Source: learn.chatgpt.com/docs/third-party/slack.

The part worth noticing here is that anyone in the channel can delegate work once the app is installed, not just whoever set it up - which is exactly why the admin-installs-once, anyone-triggers model matters for a team: onboarding a new teammate to "ask Codex" is a Slack mention, not a CLI install and auth flow.

Linear

Install the "Codex for Linear" app, link your account by mentioning @Codex in an issue comment. Two ways to trigger a task: assign the issue directly to Codex, or mention @Codex in a comment. You can also turn on triage automation to auto-assign newly triaged issues to Codex instead of doing it manually each time. Source: learn.chatgpt.com/docs/third-party/linear. If you only need to read Linear data locally instead of delegating work to the cloud, see Codex MCP setup.

A real delegated task, start to finish

Here's the one I run most often: fixing a small bug reported over Slack, without opening a terminal.

1. Trigger. In the dev channel, I type @Codex fix the crash when a user submits an empty email field on org/checkout-service (illustrative, not a verbatim command). No terminal open, no repo cloned locally - I'm just reading Slack on my phone at this point.
2. Environment selection. Codex picks the environment already configured for the checkout-service repo - I don't redeclare dependencies each time, and I don't have to remember which Node/Python version that service pins.
3. Container starts. Codex checks out the repo, runs the setup script to install dependencies, then the agent phase begins with internet access set to whatever preset I chose for that environment.
4. Runs in the background. Meanwhile I go do something else - no babysitting a terminal, no "is it still thinking" refresh loop.
5. Review the result. Codex posts a summary of what it changed, along with a diff, right in the Slack thread - I read it the same way I'd read a teammate's PR description, not as a transcript to skim.
6. Open the PR. I read the diff, and if it looks right, let Codex open the PR - I review it like a coworker's PR, not a blind merge, and if something's off I reply in the thread and it revises before I approve anything.

The win isn't raw speed (the CLI is sometimes faster for a change I could type myself in two minutes) - it's that I never leave Slack, and I can delegate several small fixes like this one in parallel without tying up my own machine or context-switching into a terminal for each one.

Which ChatGPT plan do you need?

This is the single most useful fact in this guide: Free and Go don't get Codex Cloud. Per the official docs, the Slack integration page states the requirement plainly - "a Plus, Pro, Business, Enterprise, or Edu plan" (learn.chatgpt.com/docs/third-party/slack), which matches learn.chatgpt.com/docs/pricing.

If you're on Free or Go and the cloud-delegation button doesn't do anything, that's why - not a bug. One more thing worth noting: per the pricing page, Cloud and local CLI usage share the same rolling credit window (roughly 5 hours) rather than separate budgets - re-verify this figure before planning heavy usage around it, since limits shift. Don't treat this plan gate as permanent either - ChatGPT plan features have moved before, so check again at the time you're reading this.

Practically, this also means a heavier Cloud habit - fanning out ten small tasks a day, say - draws on the same usage pool as your interactive CLI sessions. If you're already running long CLI sessions close to your plan's limit, adding a busy Cloud workflow on top is worth watching, not assuming it's free extra capacity layered on the plan you already have.

Codex Cloud vs Claude Code - cloud delegation is a real differentiator

Straight talk, no hype: Claude Code's primary surface is local/CLI - it runs on your machine, extended through subagents and hooks. Codex goes the other way, shipping first-party cloud delegation through GitHub/Slack/Linear out of the box, with nothing extra to build. That's a real difference, not marketing - if your team wants to delegate work from Slack or Linear without assembling your own pipeline, that's a genuine point in Codex Cloud's favor.

On the flip side, if your main work is long interactive sessions where you need tight step-by-step control, Claude Code still has the deeper subagent/skill/hook ecosystem. For the full comparison, see the full Claude Code vs Codex comparison - that article doesn't cover Cloud specifically yet, so treat this guide as the companion piece.

Where this matters most in practice is team adoption, not solo use. Getting a whole team to install a CLI, authenticate, and learn its flags is real friction. Getting a team to type @Codex in a Slack thread they already live in is close to zero friction - and that gap is exactly why Cloud delegation tends to spread through a team faster than a CLI tool does, independent of which agent is technically more capable.

Frequently asked questions (FAQ)

What is Codex Cloud?

Codex Cloud is one of Codex's three surfaces, running tasks inside isolated cloud containers, triggered from the web, GitHub, Slack, or Linear, then returning a diff or PR for you to review.

Do I need a paid plan for Codex Cloud?

Yes. You need Plus, Pro, Business, Enterprise, or Edu - Free and Go don't get it, per official docs at the time of writing.

Can I trigger Codex Cloud from a GitHub PR?

Yes. GitHub is one of three official trigger channels (alongside Slack and Linear) once you've connected your GitHub account and created an environment for the repo.

Does Codex Cloud have internet access?

During the setup-script step, yes (to install dependencies). During the actual agent phase, internet access is off by default, and you can open it via the none/common-dependencies/all allowlist presets.

What happens to my code after the task finishes?

Codex returns a summary with a diff, or opens a PR for you to review; the container that ran the task is an isolated environment for that run only, not your machine.

Can Slack/Linear tasks run in parallel?

Yes. Each task runs in its own container, so you can delegate several tasks at once from Slack, Linear, or GitHub without waiting for them to run sequentially.

Conclusion

The short version: CLI for hands-on interactive work, Cloud for background/parallel/team-triggered work through GitHub, Slack, or Linear - and Cloud requires Plus or higher. If you're still not clear on how the three surfaces differ, go back and read what OpenAI Codex is for the full picture before you configure anything.