← all posts
// tutorial · codex

Codex CLI: from install to first merged diff

The right way to evaluate a coding agent is one session, in one repo you actually maintain, ending with a diff you'd merge without embarrassment. Forget the benchmark, forget the launch-day demo. This is how I run that first session with Codex CLI, and what the loop feels like from the inside.

Codex CLI is the terminal end of OpenAI's coding stack: the same GPT-5-class models also drive an IDE extension and a cloud agent, but the CLI is where I would start. It runs in any repo, it shows you everything the agent does, and it is the cheapest place to build calibrated trust.

Install, sign in, say hello

Installation is a one-liner, and the session starts wherever your code lives:

npm install -g @openai/codex
cd your-repo
codex

First run walks you through auth: sign in with your ChatGPT account or paste an API key. Then you're in an interactive session rooted at the repo. Before asking for anything, run /init and let Codex draft an AGENTS.md. Skim it, fix what's wrong, commit it. That file is how your second session skips twenty minutes of rediscovery, and it deserves real care once you adopt the tool.

One setting matters more than all the others on day one: the approval mode. Start in suggest mode, where Codex proposes every file edit and every command and nothing happens without your sign-off. The looser modes are worth having. Later. I wrote up how to choose between them separately; for a first session, maximum visibility beats maximum speed.

Pick a task with a fence around it

The classic first-session mistake is asking for a refactor. Refactors have fuzzy edges, subjective success criteria, and diffs too large to review honestly. What you want instead is a task with a fence:

  • Small surface. Two or three files, not a subsystem.
  • An objective pass signal. A failing test to fix, a bug with a reproduction, a pure module that needs tests. Green or red, no vibes.
  • Cheap reversal. Nothing touching migrations, auth, or CI config. If the diff is wrong, git checkout is the entire cleanup.

Good first tasks: fix this failing test, add input validation to this one endpoint, write table-driven tests for this parser. Boring is the point: you're calibrating an instrument, not staging a demo.

Riding the loop

Strip away the branding and Codex is the same control loop as every serious coding agent: read context, propose an edit or a command, observe the result, repeat. Suggest mode lets you watch each turn. Codex greps and reads files to orient itself, proposes a patch as a reviewable diff, asks to run a command (usually your test suite), reads the output, and iterates until the signal goes green.

Two habits make this productive. First, watch what it reads. If it's orienting off the wrong module, interrupt and point it at the right one; steering early is cheap, and un-steering a finished diff is not. Second, treat each command approval as a real decision. Tests and linters, approve freely. Anything that mutates state outside the working tree, slow down and read twice.

A first session surveys where Codex stumbles in your repo, while the blast radius stays one approved action at a time.

Expect a mixed run. In my experience the model is strong at orientation and patch mechanics, and weaker at your project's unwritten rules. That's exactly the gap AGENTS.md exists to close over time.

The bar for merging is simple: would you accept this diff from a new teammate? Read every line, run the tests yourself, and if it holds, merge it. Shipping the result is what keeps the evaluation honest. If the session went sideways instead, keep the transcript and write down where it derailed. That note becomes your first steering rule, and the second session starts smarter than the first.

#codex#tutorial#cli