Codex App vs CLI vs IDE Extension: Which Codex to Use

The Codex CLI, the IDE extension and the desktop app are the same agent in three places, not three products. The CLI suits people who work in a terminal and want scripting and full keyboard control. The IDE extension suits people who want Codex beside the file they are editing, with its changes shown as diffs in the editor. The desktop app, now the Codex view of the ChatGPT desktop app, suits people running several pieces of work at once, each in its own thread, with Git worktrees to keep them apart. Behind all three sit Codex cloud, for tasks that run on OpenAI’s machines while you do something else, and Codex review on GitHub. They share one sign-in, one set of instructions in AGENTS.md, and, for the CLI and extension, one config.toml, so choosing one does not lock you out of the others.

This is a comparison, not an install guide. Installing is in Codex CLI setup, and Windows gets its own page: Codex CLI on Windows.

The surfaces, as OpenAI lists them

Codex CLI

A terminal program you start with codex in a repository. OpenAI’s Codex CLI page↗ (opens in a new tab) describes it as a way to inspect code, make changes, run commands and automate repeatable work without leaving the terminal. It is the only surface with a non-interactive mode, codex exec, which streams results to stdout or JSONL, so it is the one to put in a script or a CI job. It also has codex resume to pick up an earlier session, codex mcp to manage MCP servers, and an experimental codex cloud to browse and start cloud tasks without leaving the terminal.

The IDE extension

Codex inside your editor. The IDE extension page↗ (opens in a new tab) names VS Code and compatible editors, including Cursor and Windsurf, and notes that Xcode and JetBrains IDEs provide their own integrations. What it adds is editor context: you can point Codex at open files, selected code and recent chats from the composer, review focused diffs and keep only the changes you want. It can also hand a longer task to Codex cloud and let you review the result later.

The desktop app

What used to be called the Codex app is now the Codex view of the ChatGPT desktop app, on macOS and Windows, with a Linux version in preview↗ (opens in a new tab). Choose Codex from the top-left menu; its history stays separate from your ChatGPT chats. It is built for managing more than one thing at a time: projects, parallel threads, Git worktrees, scheduled tasks, file previews and a built-in browser for checking a page you are building. codex app from the CLI opens it on macOS or Windows, or starts the installer if it is missing.

Codex cloud

Tasks that run in isolated environments on OpenAI’s side rather than on your machine. Codex cloud↗ (opens in a new tab) takes work from the web, the IDE extension, the CLI, Slack, GitHub, Linear and GitLab (in beta); you set up each repository’s environment once (dependencies, tools, variables), and each finished task comes back as a summary and a diff, or opened as a pull request. Several can run in parallel without tying up your laptop.

Review on GitHub

Once cloud is set up for a repository, a pull request comment of @codex review asks for a review, and an automatic setting reviews every new pull request. According to the GitHub review guide↗ (opens in a new tab), Codex flags only P0 and P1 issues, reads review rules from a ## Code Review Rules section in AGENTS.md, and takes other requests in the same way: @codex fix the CI failures starts a cloud task with the pull request as context.

What they share

• Sign-in. The desktop app, CLI and extension all accept Sign in with ChatGPT or an API key for local work. Codex cloud requires the ChatGPT sign-in.
• Configuration. The CLI and the extension read the same ~/.codex/config.toml layers: model, approval policy, sandbox and MCP servers, with a project’s .codex/config.toml layered on top when you trust the project.
• Instructions. The CLI, extension, desktop app and cloud all load AGENTS.md files at the start of a task, from ~/.codex down to the folder you are in.
• Controls. /permissions, /review and /mcp work in both the app and the CLI, and the sandbox modes mean the same thing everywhere.

The practical effect: write your AGENTS.md and your MCP servers once, and every surface picks them up. Change the approval policy in config.toml and the terminal and editor agree. The one thing that does not travel automatically is conversation history: the desktop app’s Codex threads, a CLI session and a cloud task each keep their own.

Where they differ

• Where the work runs. CLI, extension and app run on your machine inside the local sandbox. Cloud runs on OpenAI’s machines in an environment you configured.
• How you review. The CLI shows diffs in the terminal and /review on request. The extension shows them in the editor. The app can put a thread in its own Git worktree and preview files. Cloud hands back a diff or a pull request.
• How much runs at once. The app and cloud are built for several tasks side by side; the CLI and extension centre on the session in front of you.
• Automation. Only the CLI has codex exec for scripts and CI. The app has scheduled tasks. GitHub review runs on pull request events.

Who each one suits

• You live in the terminal, use tmux or SSH into servers, or want Codex in a script: the CLI.
• You want to select a function, ask about it and accept or reject each hunk where you are already reading the code: the IDE extension.
• You run two or three pieces of work at once and want them kept apart, each in its own worktree, with a list you can glance at: the desktop app.
• The task is long, well specified and does not need your machine, or you want to try several in parallel: Codex cloud.
• You want a second reader on every pull request, whoever wrote it: review on GitHub.

Two surfaces often work well together. One pairing is the extension for the task in front of you and cloud for the ones you have delegated; another is the CLI for work in the repository and GitHub review as the check before merge. The shared configuration is what makes that painless.

One list across all of them

Five surfaces means five places where work can start, and no single place that says what is in progress. That list belongs outside any one of them. Every Codex surface that runs locally reads MCP servers from the same config.toml, so adding fenbs once connects the CLI and the extension to the same board: each reads the task from Next Up, moves it to In Progress, comments what it did and moves it to Completed. Every change is recorded in the board’s History under the assistant’s name, on your behalf, whichever surface made it. The connection steps are on Codex CLI on fenbs.