Codex

What the name means now

Codex has meant two different things. It was a code-completion model, available through an API and retired years ago. Today it is OpenAI's coding agent, which is the subject below.

The distinction matters because search results and older tutorials still cover the model. If you find documentation about completions and insertion endpoints, you are reading about the retired product.

Today's Codex is a tool that acts. The documentation describes starting "with a goal, idea, or task" and having it "gather context, take action, and produce something useful." You do not call it; you give it work.

Where Codex runs

More surfaces than most agents, and the choice changes the workflow rather than the capability:

• A CLI, for the terminal.
• An IDE extension.
• A cloud environment, where tasks run on OpenAI's infrastructure.
• A web interface.
• The ChatGPT desktop app, on macOS and Windows.
• Remote connections, for driving work on another machine.

The split that matters is local against cloud. Running locally, the agent works in your checkout with your credentials and your environment. Running in the cloud, it works in a container OpenAI provisions, which is better isolated and needs your repository and setup to be reachable.

Pick based on what the task touches. Work needing your local database or your unpushed branch belongs locally. Long-running work you would rather not tie up your machine with belongs in the cloud.

Sandboxing and approvals as the operating decision

An agent that edits files and runs commands is a trust decision before it is a productivity tool. The documentation covers sandboxing, agent approvals, auto-review, permission profiles, guardrails, and workspace roles for organizations.

The shape is two controls working together.

Sandboxing limits what the agent can reach: which directories it can write to, and whether it has network access. This is the boundary that holds when the agent does something you did not anticipate.

Approvals decide what happens automatically and what waits for you. Looser settings mean less interruption and less review; stricter settings mean you see each action before it happens.

The modes and their names change, so check the current documentation rather than a setting quoted in an article. What is worth internalizing is the question: before running an agent on a repository, know what it can write to, whether it can reach the network, and which actions it will take without asking.

Two habits make the rest easier. Work on a branch, so everything the agent did is a diff you can read and discard. And keep secrets out of the environment the agent runs in, because anything it can read is something it can put into a command or a file.

Reviewing the changes Codex makes

The output is a change to your code, which means the review is a code review.

The agent is confident in the same way a model is confident. A change that runs and passes tests can still be the wrong change, and one that touches more files than expected is worth reading closely. Auto-review helps and does not replace reading the diff.

Treat it as work from a capable colleague who has not met your codebase's history and cannot ask why a strange function exists. That framing gets the review attention right without either dismissing the tool or trusting it blindly.

Further reading

• OpenAI, Codex documentation: surfaces, sandboxing, approvals, and configuration.
• Claude Agent SDK: building an agent harness rather than running one.
• Function calling: the mechanism under every coding agent.