A developer guide to interfaces, cloud execution, and programmatic integration
Updated 26 October 2026.
Choosing how to use Codex starts with the work you want to do. A developer fixing a bug in an editor, a team coordinating several repositories, and an application running unattended coding tasks need different controls—even when they use the same underlying agent.
Desktop, CLI, and IDE experiences share the Codex harness: the software around the model that manages context, tools, execution, and approvals. Their interfaces and available features still differ. For application builders, the choice also includes who operates that harness and maintains its state. [1]
Naming note: “Desktop” below means Codex in the current ChatGPT desktop app. OpenAI has folded the former Codex app into that app, where developers can select Codex as their default view. [2]
Choose the working environment
| Option | Where you interact | Where project work runs | Particularly useful for |
|---|---|---|---|
| Desktop | Projects and chats in a graphical workspace | Your selected local or remote environment | Supervising parallel work and reviewing outputs |
| CLI | Terminal | The host or environment running Codex | Terminal workflows, scripts, and CI |
| IDE extension | Beside your source code | Local editor workflow, with cloud delegation available | Focused edits and review with editor context |
| Codex Cloud | Web, desktop, or mobile | An isolated workspace from a published cloud environment | Delegated tasks that continue while your computer sleeps |
Desktop provides a place to coordinate projects and inspect files. CLI fits the command line and repeatable processes. The IDE extension brings open files and selections into the conversation and keeps changes beside the source. Cloud changes the execution environment: repositories, dependencies, and access must be available there. [3–6, 27]
Cloud is an execution choice as well as a product experience. Starting a cloud task from desktop does not turn it into a task running on your laptop. Each new Codex Cloud task receives its own workspace from the prepared environment. [6]
Compare the local interfaces
Documented support · 
Conditional or experimental support · 
Additional setup or another workflow · 
Explicitly unavailable in that interface.
The table describes local development. Account, operating system, version, and workspace controls can affect availability.
| Capability | Desktop | CLI | IDE extension |
|---|---|---|---|
| Read and edit project files | |
|
|
| Run project commands and tests | With permissions |
With permissions |
With permissions |
| Review code changes | Visual review |
Terminal review |
Beside the code |
| Use a separate Git worktree | Integrated workflow |
--worktree requires local execution |
Open the worktree in the editor |
| Reuse standalone Skills | |
|
|
| Connect configured MCP servers | |
|
|
| Install and use Plugins | |
|
|
| Use the built-in Browser | |
|
|
| Manage scheduled tasks through Scheduled | |
|
|
Core development workflows are covered in [3–5]; worktrees and CLI commands in [7–8]; Skills, MCP, Plugins, Browser, and scheduling in [9–13]. The worktree row distinguishes a managed interface from simply opening a Git checkout.
Skills package reusable instructions and resources. MCP connects tools and external systems. Plugins can distribute skills and MCP servers together. These are separate capabilities: the IDE extension supports standalone Skills and MCP despite lacking Plugin support. Local clients on the same Codex host share MCP configuration. [9–11]
The Browser row refers specifically to the built-in product feature. Connecting a browser tool through MCP is a separate integration and does not provide that same interface. [10, 12]
Scheduling also has two meanings. Desktop can manage scheduled local work, which requires the computer to remain on and the app running. A CLI job can instead be launched by your own scheduler or CI system. CLI and IDE do not expose the Scheduled management interface. [4, 13]
Choose a programmatic integration
“Use the API” covers several architectures. A useful comparison asks which runtime you need and what your application must provide.
| Integration | What it provides | What you operate | Typical use |
|---|---|---|---|
codex exec |
A non-interactive Codex run with text or JSONL output | Runner, repository, credentials, job scheduling | A bounded script or CI step |
| Codex SDK | Programmatic control of local Codex threads | Host environment and application workflow | Coding automation inside an internal service |
| Codex App Server | Client protocol for threads, events, history, and approvals | Client UI, server deployment, protocol integration | A custom Codex client or integration prototype |
| Agents API | An OpenAI-managed Codex harness and durable sessions | Application tools and execution configuration | A service delegating longer tasks |
| Agents SDK | Agent runner, tools, and handoffs in your application | Deployment, storage, approvals, runtime integration | Custom agent workflows |
| Responses API | Model responses, hosted tools, and application tools | Your integration and chosen orchestration | Direct model calls or a custom agent architecture |
These options are documented in [8, 15–18, 25–26]. They address different amounts of infrastructure ownership; they are not interchangeable names for the same endpoint.
Codex SDK and Agents SDK serve different purposes. Codex SDK controls Codex itself and currently documents TypeScript and Python libraries. Agents SDK supplies components for running agents within your application. Select between them according to whether you want an existing Codex runtime or your own application-level agent workflow. [15, 25]
Agents API provides a managed route. OpenAI handles session state, orchestration, context compaction, and recovery. Execution can use an OpenAI-hosted sandbox, a self-hosted sandbox, or no sandbox. Your application still defines its tools and access. [17–18]
App Server has a material maturity constraint. The current documentation marks the app-server command and WebSocket transport as experimental and unsupported for production workloads. Treat its protocol capabilities and its deployment support status as separate considerations. [16]
Calling a model also does not automatically grant it repository access. With a custom API integration, file access, command execution, and test execution must come from the tools and environment you configure. [18, 26]
Compare access and operating costs
| Usage path | Access and billing basis | What to check |
|---|---|---|
| Local Desktop, CLI, or IDE with ChatGPT sign-in | ChatGPT plan entitlements and usage limits | Plan, workspace permissions, model availability |
| Local Desktop, CLI, or IDE with an API key | Usage billed to the API account | API rates and limits on ChatGPT-dependent features |
| Codex Cloud | ChatGPT sign-in required | Cloud access and prepared environment |
| Agents API | Model API usage, tool charges, and hosted sandbox charges where applicable | Total session cost and execution needs |
Authentication and feature availability are documented in [19–20]; Agents API pricing is described in [18]. A local client using an API key follows API billing rather than included ChatGPT plan credits.
For a team evaluating cost, include engineering time alongside usage charges: maintaining runners, dependencies, tool integrations, approvals, and observability can matter as much as the model bill. Which route costs less depends on the workload and the infrastructure you already operate.
Distinctions that affect real projects
Local execution and local inference are separate. With OpenAI models, Codex can operate on files and commands on your machine while the model performs inference in the cloud. Local file access should not be interpreted as offline processing. [23]
An open runtime does not include unrestricted model access. OpenAI publishes components including Codex CLI, SDK, and App Server as open source. Model access and paid services have their own authentication and usage terms. [1, 19, 22]
Parallel tasks need suitable isolation. Desktop worktrees provide separate checkouts; cloud tasks use separate workspaces. Dependencies and setup still matter, and changes eventually need review and integration. [6–7]
Hooks and schedules solve different problems. Hooks run scripts or MCP tools at lifecycle events, such as around tool use or when a turn ends. Schedules determine when a task starts. A team might use a schedule for a daily maintenance task and a hook for its completion check. [13–14]
Interface choice alone does not establish code quality. Model selection, reasoning settings, supplied context, tools, and execution conditions all affect the work. To compare workflows in your own project, use the same task and acceptance tests, then measure successful completion, review effort, elapsed time, and total cost. [1, 21]
Practical starting points
| Your task | Start with | Why |
|---|---|---|
| Fix a problem in files already open | IDE extension | Source, selected context, and review stay together |
| Supervise several project tasks | Desktop | Projects, parallel chats, and worktrees are visible |
| Add an AI step to an existing pipeline | codex exec |
A simple non-interactive entry point |
| Build recurring coding workflows in a service | Codex SDK | Programmatic Codex threads and continuation |
| Delegate work while your laptop is offline | Codex Cloud | Execution lives in the cloud environment |
| Build a service using a managed agent runtime | Agents API | Managed sessions and orchestration |
| Own the agent workflow inside your application | Agents SDK or Responses API | Application-level control over integration |
These are practical starting points, not exclusive choices. A team can investigate a bug in the IDE, delegate another task through desktop or cloud, and run a repeatable check in CI. Choose each interface according to the work it makes easier to inspect and maintain.
Official sources
All sources below are OpenAI documentation or announcements. Accessed 26 October 2026. Current feature documentation takes precedence over older launch descriptions.