Codex xli is nearly always a typo for Codex CLI

The search behind codex xli

We see this query land on our pages every month. There is no product called codex xli. The letters sit next to each other on a keyboard and the C gets dropped. What people want is the command line agent that OpenAI ships for Codex, the one you run in a terminal inside a repository rather than in a browser tab.

The other possibility is that someone read XLI as a roman numeral in a version string somewhere. Codex does not version itself that way. If you saw XLI in a changelog, it came from something else.

What the terminal agent actually does

You start it in a project directory. It reads files, runs commands, edits code, and shows you a diff before anything is written. The loop is the point. A browser chat has to be told what your code looks like. A terminal agent goes and reads it, then runs your test command and reads the failure output too.

That changes the kind of task you can hand it. Instead of pasting a function and asking for a fix, you can say what is broken and let it find the file.

Where teams get stuck

• Approvals. The first hour is spent confirming every command. Learn the approval settings early, decide as a team which mode you run in, and write it down. Guessing per developer produces inconsistent behaviour and bad habits.
• Sandboxing. Network access and write access are separate concerns. If your build needs to pull dependencies and the agent cannot reach the network, the run fails in a way that looks like a model problem and is not.
• No project instructions. Without a file describing how to build and test, the agent invents a command, it fails, and it spends turns recovering.
• Enormous first tasks. A prompt like "migrate the auth layer" produces a large diff nobody wants to read. Ask for the smallest change that can be verified.

A first session that works

Pick a repository with a fast test suite. Add a short instructions file at the root that names the exact commands, something like:

Build: pnpm build. Test: pnpm test -- --run. Never edit files under generated/.

Then give the agent a task with a visible finish line. "The date parser drops the timezone on ISO strings without a Z. Write a failing test first, then fix it." Watch what it does. When it proposes a diff, read the diff, not the summary of the diff. The summary is a description written by the same system that wrote the code.

The honest limit: on unfamiliar code, the first attempt is often close and wrong in one specific way. That is fine if you review. It is expensive if you approve on trust and find out three commits later.

What to do next

Install the CLI, run it on a repository you know well, and give it three tasks you could have done yourself in twenty minutes each. You are not testing whether it can code. You are calibrating how much of its output you need to check, which is the only number that matters for your team.

If you want help putting this into practice, talk to us.