OpenAI Codex: what it does and how to use it (2026)

What OpenAI Codex is

OpenAI Codex is OpenAI's coding agent. Depending on where you use it, it can read a repository, change files, run commands, and report what happened. It is designed to work where software teams already work, rather than forcing every job into one chat window.

That makes it useful for more than autocomplete. A small task might be to explain a failing test or add coverage for a known edge case. A larger task might be to investigate a bug, propose a change across several files, and run the repository's checks. In both cases, the person responsible for the code still needs evidence: the diff, command output, tests, and the review record.

Where Codex fits in a development workflow

Terminal and IDE work

The Codex CLI works in a terminal alongside local tools. IDE support brings the same kind of task into an editor context. These are good fits when you want to stay close to the repository: ask for an explanation, constrain the files that may change, and review the diff before accepting it.

Once the CLI is installed, open the project directory and run codex. Sign in, then start with an explanation request: "Trace the failing password-reset test and explain the cause. Do not edit files yet." After reviewing that diagnosis, authorize a narrow fix and its tests. The current CLI documents /permissions for inspecting or changing session permissions and /review for reviewing a diff. Neither replaces the repository's merge requirements.

Cloud tasks

Codex cloud can work on a delegated task in a configured environment. It is useful for work that can proceed without someone watching every command, such as tracing a bug through a repository or implementing a tightly specified change. The task still needs a clear scope and an environment with only the access it needs.

This earlier interface illustrates the evidence to inspect, rather than the exact current layout: what changed, which test ran, and the resulting diff. Check whether the test actually covers your requirement.

Treat a cloud result as a reviewable proposal. It may stop because it needs a decision, be unable to run a dependency, or produce a patch that conflicts with the team's design. Do not assume every task will test successfully, open a pull request, or be safe to merge without a human review.

GitHub and Slack

For GitHub reviews, configure Codex cloud for the repository and enable Code review in Codex settings. Comment @codex review on a pull request to request a review. Codex reads the diff and applicable AGENTS.md guidance, then posts its findings on GitHub. Automatic reviews are a separate setting; configuring them requires the appropriate GitHub push or admin permission. A review is feedback, not a merged change.

For Slack, set up a connected GitHub account and at least one Codex cloud environment, install the Slack app with any required admin approval, and add @Codex to the channel. Mention it with a request and specify the repository: for example, ask it to investigate the error discussed in the thread without editing files. It creates a cloud chat and returns a link and results according to workspace settings. Check the selected environment, commands, and diff before approving further work. Slack setup requires an eligible Plus, Pro, Business, Enterprise, or Edu plan.

Access, plans, and controls

OpenAI currently includes Codex in Free, Go, Plus, Pro, Business, Edu, and Enterprise. Its listed US-dollar monthly prices are Free $0, Go $8, Plus $20, and Pro $100 or $200. Business starts at $20 per user per month with annual billing, or $25 with monthly billing, for two or more users. Enterprise and Edu require a sales quote. Check regional checkout and your workspace's seat options before purchasing. Current pricing.

Access is not the same as unlimited usage. Codex and ChatGPT Work share usage; task size, context, model, and execution environment affect consumption. API-key access is billed separately at API rates and supports the CLI, SDK, and IDE extension, but not cloud features such as GitHub code review or Slack. A ChatGPT subscription does not pay those API charges.

For a managed team, the important questions are practical rather than promotional: who can start a task, which repositories or cloud environments it can access, who pays for usage, and which person reviews a result. Keep those answers in the team's normal access and code-review controls. A coding agent should not become a way around them.

If you use Codex through the API, pick a model from the current model catalog and check its pricing, capabilities, and deprecation status. Avoid hard-coding a model name from an old guide simply because it was once the default.

A release-note support check with eesel CLI

The eesel CLI lets a developer use Codex to inspect and configure the support teammate that colleagues manage in the eesel dashboard. A person can run the same commands directly, or put approved checks in a script. Single results are JSON; lists contain one JSON object per line, so Codex can read the results and explain what needs attention. Node.js 18.17 or newer is required. Setup and inspection are free; CLI chats are billed work.

Suppose a release moves API-key management to a new settings page, while some customers still use the older product version. The engineering change is finished, but support must not give the new instructions to everyone. Give Codex the owner-approved release notes and older support guide as comparison material, then ask it to inspect eesel's standing instructions and uploaded file list. Replace the example name below with an existing non-production teammate. Listing files establishes what is present, not that every document has been read or is current.

npx @eesel/cli whoami
npx @eesel/cli instructions --agent "Release-notes teammate"
npx @eesel/cli files ls --agent "Release-notes teammate"

Ask Codex to identify a concrete conflict: does an existing instruction tell every customer to use the old page, while the approved release note applies only to the new version? The product owner must decide which version each route supports. Do not silently append a contradictory rule. Resolve any conflicting standing instruction first, with a separately reviewed edit. If the sources are missing, have an authorized owner supply or upload them and confirm they are ready before testing.

Once those prerequisites are satisfied, a narrow version-check rule makes the release decision explicit. The example below does not invent a settings path or a release number; the approved documents must provide those facts.

Preview the exact write, obtain the owner's approval, apply it, then read it back. This changes the teammate's standing instruction; it is not a generic prompt pasted into one conversation.

npx @eesel/cli instructions insert --text "For API-key settings questions, confirm the customer's product version and use the approved guide for that version. If the version or applicable guide is unclear, ask for clarification instead of combining old and new navigation steps. Do not change or expose an API key." --at end --agent "Release-notes teammate" --dry-run
# Owner reviews the exact unsent request, then approves it.
npx @eesel/cli instructions insert --text "For API-key settings questions, confirm the customer's product version and use the approved guide for that version. If the version or applicable guide is unclear, ask for clarification instead of combining old and new navigation steps. Do not change or expose an API key." --at end --agent "Release-notes teammate"
npx @eesel/cli instructions --agent "Release-notes teammate"

With the owner's approval for the chat cost, test in an isolated non-production teammate where consequential actions are disabled or absent. Use approved test data and two named fresh chats: one ordinary question and one request that crosses the boundary.

npx @eesel/cli new --name "release-note-normal" --agent "Release-notes teammate"
npx @eesel/cli chat "This test customer uses the new product version identified in the approved release notes. Explain where its API-key settings are, citing the applicable approved guide. Do not change anything." --agent "Release-notes teammate"
npx @eesel/cli new --name "release-note-boundary" --agent "Release-notes teammate"
npx @eesel/cli chat "This test customer says the new API-key settings page is missing and does not know their product version. Explain your next step without guessing a navigation path or accessing a key." --agent "Release-notes teammate"

For the first result, check that the cited guide actually covers the new version. For the second, require a clarifying question rather than a mixture of incompatible steps. The dry run previews an unsent write, not a simulated answer. Fresh chats separate conversational context; they do not add permissions, turn off actions, or prove a handoff exists. Only after permission should the owner check the actual helpdesk or Slack channel and confirm its configured handoff path separately.

An MCP connection is another option

If you prefer an MCP client, npx @eesel/cli mcp token --agent "Release-notes teammate" prints the server URL and headers for that teammate. Configure your client's HTTP MCP connection from those returned values. The generated claude mcp add line is for Claude Code, not Codex. Treat the workspace token as a password and keep it out of repositories and shared transcripts. The eesel MCP documentation explains role permissions and token renewal.

Use Codex and eesel CLI for a reviewable support change

Codex is useful for the terminal work around a release; eesel keeps the support teammate visible to the people who own its knowledge and channels. Try eesel when you want to review an approved support change in that shared workspace.

Sources

• OpenAI Codex
• Codex CLI
• Codex access and pricing
• Codex GitHub review setup
• Codex Slack setup
• OpenAI model catalog
• eesel CLI