The IDE Extension

Start with the idea everything else hangs on: the IDE extension is not a different product — it is the same Codex agent, rendered inside your editor.

Codex is an umbrella over a family of surfaces — the CLI, the IDE extension, cloud/web, the desktop app, mobile, GitHub — that all share one model family and one ChatGPT account. The extension is the editor surface of that single agent. It reads the same AGENTS.md, obeys the same sandbox and approval controls, and runs the same agent loop (inspect repo → propose changes/commands → pause for approval → iterate) that you met in the CLI lessons. The window dressing changes; the engine does not.

Why use the editor surface at all, when the CLI already does everything? Three concrete wins:

• Native diff review. Proposed edits show up as real editor diffs, in the files you already have open, with your syntax highlighting and gutters.
• Effortless context. The files you're looking at and the code you've selected become context automatically — no copy-pasting paths into a prompt.
• A door to the cloud. A single click ("Run in the cloud") offloads a long task to an isolated cloud environment and brings the diff back, all without leaving the editor.

Keep the surface/agent distinction crisp: when you change the model in the IDE, or approve a command, or edit AGENTS.md, you are configuring Codex, not "the VS Code plugin." That is why the skills transfer cleanly between terminal and editor.

The extension ships from the Visual Studio Code Marketplace under the id openai.chatgpt (the same one the CLI's codex lineage lives under), and OpenAI provides install links for each supported editor.

Supported editors and platforms:

It runs on macOS, Windows, and Linux. On Windows you can run it natively (the Windows sandbox) or via WSL2 — the same options as the CLI.

After install, Codex opens in the right sidebar by default (you can drag it to the left). On a VS Code fork like Cursor, moving the icon may require toggling the activity bar orientation.

Signing in mirrors the CLI exactly: on first run the extension prompts you to sign in with your ChatGPT account or with an API key.

• ChatGPT account (recommended) — plans that include Codex (e.g. Plus/Pro/Business/Edu/Enterprise) carry Codex usage with no separate setup. This is the path most people want.
• API key — usage-based billing through the API; useful for shared or automation-leaning setups.

Because the account is shared, signing in once ties the editor to the very same Codex identity as your terminal — your sessions, history, and entitlements come along.

The extension's mode switcher offers three modes. They look like a simple dropdown, but each one is really a pairing of two independent controls you already know from the CLI: a sandbox mode (WHERE Codex may act) and an approval policy (WHEN it must stop and ask). The modes are just friendly presets over that pair.

The single most important thing to internalize: sandbox and approval are independent axes. Sandbox is an OS-enforced read/write/network boundary; approval is the policy for when the agent pauses for a human. The IDE bundles them into three sensible presets, but under the hood they are the same two knobs the CLI exposes via --sandbox/sandbox_mode and --ask-for-approval/approval_policy. Understanding the pairing is what lets you reason about "what can actually go wrong here?" instead of trusting a label.

A few practical implications:

• Agent is the everyday default. It can edit and run routine commands inside your workspace, but it will pause and ask before reaching the network or touching files outside the working directory.
• Agent (Full Access) removes both guardrails — it maps to danger-full-access with no approvals. That is genuinely useful for trusted, well-scoped work, but it is the editor equivalent of the CLI's most permissive posture. Reach for it deliberately, not by habit.
• Chat is the safe place to think: ask questions, plan, and read the code with zero risk of an unexpected edit or command.

The editor's biggest ergonomic advantage is how naturally it feeds context to the agent. You spend far less effort telling Codex what to look at, because the editor already knows.

Pointing Codex at code:

• @filename references — type @ and pick a file to attach it explicitly to the conversation.
• Open files + selected code are used as context automatically. Select the function you're worried about, write a short prompt, and Codex already has the relevant snippet — shorter prompts, faster results.

Choosing the brain:

• A model switcher sits under the chat input. Pick the model that fits the task; leaving it on the recommended default lets ChatGPT-auth users track whatever OpenAI currently recommends.
• A reasoning effort control offers low / medium / high, with medium as the recommended default. Higher effort means deeper reasoning but more tokens (and latency); lower is snappier for simple edits. This is the same model_reasoning_effort concept from the CLI config, exposed as a picker.

Model names and the exact default rotate frequently, so don't memorize a specific string — pick from what the switcher offers and confirm the current recommendation on the live models page.

  ┌──────────────────────────────────────────────┐
  │  Codex chat (editor sidebar)                   │
  │  @auth.ts  @rate-limit.ts   [+ selection]      │
  │  > Add rate limiting to the login route        │
  │                                                │
  │  [ model: <recommended> ▾ ]  [ effort: medium ▾ ]│
  └──────────────────────────────────────────────┘

For local IDE tasks, web search is enabled by default. That lets Codex pull in current information — an error message, a library's current API — without you switching to a browser.

The important nuance is how it searches: results come from an OpenAI-maintained web search cache (an index of web results), not a live hit to the open internet for every query. That distinction matters for two reasons:

1. Speed and consistency — cached lookups are fast and don't depend on a live fetch round-trip.
2. Security — every piece of retrieved web content is untrusted input and a vector for prompt injection. Serving from a cache reduces exposure compared with live, arbitrary fetches. Codex's broader security stance treats all web results, MCP output, and external content as untrusted, with the sandbox as the primary defense.

So: web search is a feature you get for free locally, but keep the security framing in mind. The safest posture is the default Agent mode (workspace-write, approval for network/out-of-workspace), which limits what a malicious search result could actually cause the agent to do.

The headline feature unique to the editor surface is the local → cloud hand-off. When a task is too long to babysit locally — a big refactor, a sweep across many files, something you'd rather run in the background — you offload it to Codex cloud without leaving the IDE, and the context comes with it.

The flow:

1. Configure a cloud environment in settings (a container that checks out your repo at a branch/commit, runs your setup script, and installs dependencies).
2. Click "Run in the cloud" to offload the task. Codex spins up an isolated cloud sandbox for it.
3. Monitor progress without leaving the IDE.
4. Preview the cloud's proposed changes and ask follow-up questions.
5. Apply the resulting diffs locally to test and finish.

The property that makes this more than "open the web app" is that context persists across the local → cloud transition — the cloud task starts with what you were already working on, rather than from a blank prompt. It is the same one-account, one-agent design paying off: the cloud run is the same Codex, just on a beefier, isolated host.

A couple of details worth carrying over from the cloud lesson: cloud tasks run in their own containers (so several can run in parallel), and internet access is OFF by default during the agent phase (setup scripts keep it on for dependency installs). You configure that per environment.

Because all three are the same agent, the choice is about ergonomics and where the work should run, not capability. Use this as a decision guide:

The through-line: start where the work is. If you're reading and editing code, the editor is the lowest-friction home and the hand-off to cloud is one click away. If you're automating or scripting, the CLI is your surface. And because configuration (AGENTS.md, sign-in, sandbox/approval posture) is shared, you can move between them mid-project without re-learning anything.

Reviewing diffs is the same discipline everywhere: Codex always surfaces a transcript and a diff, and there is no /undo — you roll back through your normal git workflow. The editor just makes that diff prettier to read.