Codex, Level Up: Cloud Tasks, Code Review, MCP Integration, Custom Instructions, IDE Integration

Today's Goals

1. Send a task to run in parallel in a Codex cloud environment, come back to review the diff, and decide whether to open a PR
2. Have Codex review code with /review and @codex review on GitHub, and explain the split between reviewing and generating
3. Wire in an MCP server with codex mcp add, and capture a reusable workflow with skills

Yesterday you worked through one job with Codex in the terminal, watching the whole time. Today's questions are: what happens when there is more work than that? What happens when you cannot watch it all? What happens when it cannot do something? The answers are cloud parallelism, code review, MCP, and skills. Once you have read this and finished the work, scroll back to the top and tick off the three goals.

Plain-Language Walkthrough

Cloud tasks: send the work out and only look at the diff when it returns

Continue the story of yesterday's contractor. For the first few days they sat next to you and you watched every change. Once you trust how they work, the natural next step is to send the job out, let them do it back at their own firm, and have the result sent over for you to review. And since it is going out anyway, sending three jobs at once is no problem — none of them occupy your desk. That is the whole idea behind Codex cloud tasks: the task runs in an isolated container on OpenAI's side, unrelated to your local machine, you can send several at once, and each one comes back as a diff to review.

There are several entry points: chatgpt.com/codex in a browser; codex cloud in the terminal to browse or start a cloud task; a "send to the cloud" action in the IDE extension; and ChatGPT on your phone. The same machinery sits behind all of them: a cloud environment bound to your GitHub repository, where every task clones your repository into a fresh container, runs the setup script you configured, and then starts working.

The biggest difference from the local CLI is not where it runs but that the approval model changes. Locally you nod in real time; in the cloud nobody is beside it, so its boundaries are drawn entirely in advance by the environment configuration: whether it can reach the public internet, which dependencies get installed, which environment variables exist. That means everything you decided yesterday "when the approval pops up" has to be thought through ahead of time and written into the environment configuration. Back to the workflow: when a task finishes you get a summary plus a diff, and you can do one of three things — accept it and open a PR in one click, ask a follow-up so it keeps working, or discard it outright. codex apply drops the diff from a cloud task straight onto your local working tree, which suits the combination of proposing in the cloud and testing locally.

Configuring the cloud environment: dependencies, variables, and whether to grant internet access

Environment configuration is the watershed for cloud tasks, because the container is not the machine you spent yesterday setting up. There are only four categories of setting:

1. Base image and dependencies: pick the runtime version (Node, Python, and so on) and write install commands in the setup script, such as pnpm install. The setup script runs before every task and a failure kills the task, so it has to be as reproducible as a CI script.
2. Environment variables and secrets: put in the variables the tests need. Do not put in production secrets — what runs in the container is a program that executes commands autonomously, and whatever you give it, it can use.
3. Public internet access: off by default. On, and it can npm install a new dependency or look up documentation; off, and it can use only what the setup phase installed. The middle path is to allow the network during setup for dependency installation and cut it off during the task.
4. AGENTS.md: still in effect. It gets cloned into the container with the repository, so the handbook you wrote yesterday applies in the cloud too — precisely the benefit of putting the rules in the repository rather than in your head.

Configure it once and every later task shares it, so it is worth half an hour to get it into the state where any task you send has its setup pass. In the lab you will actually configure one.

Code review: /review locally and @codex review on GitHub

The work has come back — who reviews it? You will of course look, but you can also have another reviewer go first. Codex's code review has two entry points matching two rhythms.

Locally, inside a session: type /review in the CLI and it offers three options — review the currently uncommitted changes, review the whole branch diff against a base branch, or supply a custom review instruction ("only look for missing error handling"). The results appear as line-by-line comments and do not touch your working tree; it only reports problems. The unattended version is codex review, non-interactive and suited to a pre-push script.

Remotely, on a PR: with Codex's GitHub integration installed on the repository, writing @codex review in a PR comment has it read the whole PR context and the existing comments and post its review back as inline comments. A team can configure it to review every PR automatically.

A natural question: if the same vendor's model both writes and reviews the code, is the review worth anything? Yes, but understand its boundary. A review gives the model different input — it sees the diff rather than the requirement, and it stands in the position of finding problems rather than completing a task, and that role switch alone catches plenty of oversights from generation time (missed edge cases, callers left un-updated). What it cannot catch is a misunderstanding of the requirement itself, because reviewer and generator share the same reading of the requirement. So the most valuable review combination is generate with one vendor and review with another, and on D5 we build that workflow properly.

MCP integration: one command to give Codex another pair of hands

The contractor is very capable, but some things are beyond them: querying your company's internal ticketing system, reading your in-house knowledge base, operating some internal service. You need to grant them accounts and tools. MCP (the Model Context Protocol) is the general protocol for wiring external tools into a coding agent — an MCP server exposes a set of tools, and any MCP-capable client can call them. D23 of the 30-day course has the protocol details; here we only cover using it in Codex.

Wiring up a server is one command:

codex mcp add <server-name> --env KEY=VALUE -- <command that starts the server>

After -- comes the command that starts this stdio-type server, and --env passes the environment variables it needs. Behind the command, a block of configuration is written into ~/.codex/config.toml:

[mcp_servers.<server-name>]
command = "npx"
args = ["-y", "some-mcp-server"]
env = { SOME_TOKEN = "read from an environment variable; never hard-code it" }

Editing that block by hand is equivalent to running the command. codex mcp list shows the servers wired up; for a remote server requiring OAuth, codex mcp login <server-name> completes the authorization. Once connected, Codex treats those tools as its own capabilities in a session — you only say, in plain language, "file this bug in the ticketing system," and it finds the right tool itself.

One reverse usage is worth knowing: codex mcp-server turns Codex itself into an MCP server. That is, another agent — including the one you write with the Agents SDK on D4 — can call "have Codex change the code" as a tool. That is the entry point for embedding a coding agent inside a larger system.

Custom instructions and skills: rules go in AGENTS.md, workflows go in a skill

You now have two ways to teach Codex: AGENTS.md for rules and MCP for tools. One is missing — a reusable workflow. Take the pre-release checklist: bump the version, update the changelog, run the full test suite, tag. That is neither a rule nor a tool but a sequence of steps with some judgment in it, and you do not want to describe it from scratch in the prompt every time. That is the problem skills solve.

A skill is a directory containing a SKILL.md whose frontmatter carries at minimum name and description, with the body describing how the workflow goes; alongside it you can put scripts/ (scripts the workflow runs) and references/ (documents it consults). Where you put it decides its scope: .agents/skills/ inside a repository applies to that project only, while ~/.agents/skills/ in your home directory applies to all your projects.

There are two ways to invoke one: explicitly, by typing $skill-name in the input box, or not at all — Codex decides from the description whether the current task matches a skill and uses it automatically if so. So the description should say when to use me, not what I am.

The division of labor among the three fits in one sentence: AGENTS.md governs the rules of working, MCP governs the external systems it can reach, and a skill governs a workflow you walk through repeatedly. Rules are read every session; tools are called on demand; workflows are matched per task. When you cannot tell which is which, ask: is this content something to obey every time (a rule), something that fetches data from outside (a tool), or a multi-step procedure (a workflow)?

If you have taken the companion course on using Claude effectively, you will notice Claude Code has an almost isomorphic trio: CLAUDE.md, MCP, and .claude/skills/. The two vendors' designs converge tightly at this layer, and that convergence is itself a signal — this division of labor is the general pattern for coding agents, so learning it once serves you on both sides.

IDE integration: hand it the code you selected

The last entry point is the editor. Codex's IDE extension supports VS Code and its derivatives (Cursor, Windsurf), the JetBrains family, and Xcode. Once installed you get a Codex panel in the sidebar, and selecting a stretch of code in the editor makes it the context of the conversation — no more copy-pasting, no more describing which lines of which file you meant.

The workflow inside the IDE matches the CLI: the same AGENTS.md, the same approvals and sandbox, the same /review. Two things are extra. First, diffs are accepted or rejected block by block right in the editor, which is far more comfortable than reading git diff in a terminal. Second, you can send the current task to the cloud in one click, keep working locally, and come back when it finishes. The extension also creates git checkpoints before and after a change, making a wholesale rollback easy.

When to use the IDE and when the CLI? A rough rule: local changes that need you to look at surrounding code often go to the IDE; large tasks spanning many files, unattended runs, and anything script-driven go to the CLI. They share the login, the configuration, and the session history, so switching costs nothing.

Source Reading

Hands-On Lab

Today is a documentation-style lab whose deliverable is a one-page reusable cloud task checklist. starter/ is the checklist template with blanks and solution/ a worked version filled in for this course's TODO API. Readers without a GitHub repository can push the TODO API from D1 to a new private repository.

1. Create an environment for the repository at chatgpt.com/codex: pick the Node runtime, put pnpm install in the setup script, leave the public internet off, and send a read-only task listing every route in the project to verify setup passes.
2. Send out "add input validation to POST /todos" and "add unit tests for the existing routes" as two simultaneous tasks, note the start time of each, and write on the checklist whether you expect them to touch the same files.
3. When both return, read the summary and diff of each and make the three-way decision from the checklist (accept / follow up / discard), writing one line of reasoning per decision.
4. Apply the accepted one locally with codex apply, run the tests, then run /review and mark each review comment as agreed or disagreed.
5. Write three things you would do the same way next time and three you would change, into the retrospective section at the end of the checklist.

Interview Questions

Today's 3 questions are in the question bank below, weighted toward the approval boundary of a cloud coding agent, the split between code review and code generation, and the difference between MCP and skills. Expand each one and read the analysis before the key points — practicing the derivation beats memorizing bullets.

Checklist and Tomorrow

• Send a task to run in parallel in a Codex cloud environment, come back to review the diff, and decide whether to open a PR
• Have Codex review code with /review and @codex review on GitHub, and explain the split between reviewing and generating
• Wire in an MCP server with codex mcp add, and capture a reusable workflow with skills
• State the division of labor among AGENTS.md, MCP, and a skill in one sentence
• All 4 acceptance criteria of the lab pass
• Answer at least 2 of the 3 interview questions without looking at the key points

Tomorrow (D3) we drill down a layer: how a finished product like Codex uses the Responses API underneath to organize the model, the tools, and multi-turn state. Using the product before reading the API is a deliberate order — you have already watched the loop of the model requesting a tool, receiving the result, and continuing, right there in Codex, so when the function_call and function_call_output fields show up tomorrow you will know which step each corresponds to instead of reading an abstract interface document.