A change can be only a few lines long and still leave you wondering what it might break. Codex can help you work through that question in the project itself: read the surrounding code, find the tests, make a proposed edit and run the tools you already use. It is OpenAI’s coding assistant, and this guide covers its command-line interface, or CLI, which runs in a terminal. We will start with the connection between a change and its tests, because understanding that connection makes the next edit easier to judge.
01Fit
02Requirements
Check the account you will use before starting a long session. CLI access, included usage and limits depend on that account; billing through an API key is separate from a ChatGPT subscription. The current access table explains what is included and when another charge may apply.
Check current access and pricing03Setup
On macOS or Linux, the command below downloads and runs the official installation script. Review the script before running it. Windows has its own instructions on the same setup page.
curl -fsSL https://chatgpt.com/codex/install.sh | shSave your current work in Git, open the project directory in a terminal and run codex. Follow the sign-in flow available to your account. Having a saved starting point lets you see what Codex changes and return to the original code if you decide against the patch.
codexUse /permissions and /status to inspect the session’s access and settings. For an initial look around, the security guide also describes launching Codex read-only. A request to explain the code tells Codex what you want; read-only filesystem permissions prevent an unwanted edit while you are still discussing it.
04Using Codex
A request can fail from the caller’s point of view after the service has already done the work. In this synthetic support client, retry.mjs retries every rejected write. The supplied transport creates a ticket, loses its response, and then creates another when called again. Use Codex to turn that concrete failure into a small change you can review.
Included example files
Synthetic code, logs, a deliberately stale runbook, and six support tickets. The JavaScript uses Node.js 22+ with no packages or network calls. Product accounts and model access are separate.
node --test client.test.mjs retry.test.mjsnode --test checks/retry-contract.test.mjsRead retry.mjs, retry.test.mjs and checks/retry-contract.test.mjs. The contract is: a write with an ambiguous outcome must not be retried automatically. Explain how the current code can create two tickets. Propose a focused regression test that observes the number of writes, not just the return value. Do not change files yet. After I approve the plan, fix the implementation while preserving the successful-call behavior and the original rejection. Do not change or weaken the supplied contract check.The artifact you are working toward
The result is a changed retry.mjs plus a test that proves one attempted write and the original rejection. You should be able to explain the exact execution path without relying on Codex’s description.
export async function submitWithRetry(send) {
return send();
}Once is still an extra write. Ask Codex to walk through the supplied transport line by line and show the size of writes after each call.
That can be a production design, but it needs matching server behavior that this project does not contain. Keep this patch within the single-send contract; assess a real idempotency design separately.
Keep the patch when the behavior, tests and diff agree. This example deliberately sacrifices automatic recovery because it cannot establish whether retrying a write is safe; it does not argue against retries on reads or against a service with a verified idempotency contract.
The included baseline tests and evaluation script were checked locally. The deliberately failing contract tests demonstrate the defects in the starter. No AI product was installed or run for these examples; model responses and reviews will vary.
05Next steps
If each new task begins with missing dependencies or the same setup commands, a prepared cloud environment can save that repeated work. The Codex Cloud guide explains what belongs in reusable setup and what remains specific to an individual task. That distinction matters when a successful run depends on files left behind by an earlier session.
Read the guidanceThe person reviewing your patch will need the same connection you just established between the behavior, the edit and the test. Keep the tested revision, commands and results with the change. The release-engineering guide follows that information into a release review, where a passing result is useful only if everyone knows what was actually checked.
Read the guidance06Alternatives
07Evidence and scope
Product behavior is based on the linked official documentation. This walkthrough uses an authored synthetic starter project. Its baseline tests and local checker were checked; no installation, model response or product performance was independently tested for this guide.
Documentation checked