Codex CLI 0.121.0 for repo workflows

A repo workflow is the contract your repository states for agent runs: what the agent may touch, what evidence it leaves, and who answers for each piece. Codex CLI, OpenAI's coding agent, version 0.121.0, makes that repo faster to work in, but speed alone does not make a pull request easy to review. The thing that does is a name beside every connector and a replay recipe beside every diff. This piece shows how to write that contract so a reviewer who has never seen the repo can still approve the change.

Most blocked reviews are not blocked on tool quality. They are blocked because nobody can explain why the agent did what it did, and the answer lives only in a chat window the reviewer cannot see.

Give every connector a named owner

The first thing a new reviewer trips over is a connector that widens what the agent can reach, with no person attached to it. Each MCP server you add expands blast radius. When connectors pile up quietly, least-privilege erodes one merge at a time.

Fix it by keeping a connector roster in the repo root, with an owner named beside each entry and the actions it is allowed to take. The MCP specification frames capability scoping the same way: a connector is a grant, and a grant needs an owner. When the roster is checked in, a security review starts from a list instead of a memory test.

A simple roster looks like this:

# connectors.md

| Connector    | Owner       | Allowed actions             |
| ------------ | ----------- | --------------------------- |
| github-mcp   | @priya      | read PRs, comment, no merge |
| staging-db   | @lars       | read-only queries           |
| browser-tool | @priya      | navigate staging, no prod   |

If a connector cannot get an owner, that is a signal to remove it, not to ship it.

Pin the model and escalation rule in AGENTS.md

Casual model swaps wobble what a reviewer expects from a run. A diff produced under one model and reviewed under the assumptions of another is a quiet source of confusion. The repository, not each contributor's habit, should state the default.

Pin the default model and the escalation rule inside AGENTS.md, near the top, so a lead can reason about blast radius before reading a single line of the diff. Keep the same file honest by capping it with a Definition of Done: ten bullets or fewer, in your team's own words. When AGENTS.md grows past that, Codex starts optimizing for the wrong version of done.

# AGENTS.md verification snippet

- Every Codex CLI run ends with the transcript snippet reviewers can replay.
- Pair browser evidence with the project's normal CLI checks before merge.
- If MCP servers are enabled, list allowed actions beside each connector name.

The drill library that goes with these rules lives under CLI workflows, and in our methodology this is the Review stage: a stranger must be able to explain the change.

Make the PR body carry its own proof

The point of all this is one moment: the reviewer opens the pull request and can approve it without asking you anything. That only works if the PR body carries the evidence with it.

Use a short table to route the review, then a checklist the author fills before requesting eyes:

And the author's checklist:

• Scopes in the PR body match the folders in the diff.
• Primary-doc links were smoke-checked after publishing edits.
• MCP connectors mentioned, if any, list their owners.
• Verification command output is pasted or linked.

If the body cannot carry that, the diff is not ready, no matter how green CI looks.

Keep hard calls with humans

Browser workflows in Chrome diverge from CLI habits, which gives reviewers two sources of truth instead of one. Document staging URLs and credential boundaries right beside the browser task so the demo and the CI artifacts stop contradicting each other.

For the tool itself, the Codex CLI docs, the features page, and the slash commands reference cover what the agent can do, while the openai/codex and openai/skills repositories track what lands next. Versions change what the agent can do. The contract states what it may do. Threat models, customer promises, and blast radius calls stay off autopilot and with a person.

Common questions

• What is a repo workflow for Codex CLI 0.121.0?

  It is the operating contract a repository states for agent runs: boundaries, evidence, and owners. In practice it is four artifacts checked into the repo. A browser bridge note beside Chrome tasks, a pinned model and escalation rule in AGENTS.md, a connector roster at the repo root, and a done checklist of ten lines or fewer. Each one answers a question a reviewer would otherwise have to ask you.

• Who should own an MCP connector?

  A named person, listed in the roster beside the connector and its allowed actions. Connectors that widen blast radius without a named owner are the first thing a new reviewer trips over. The question of who approved a server, and what it is allowed to reach, should live in a checked-in file, never in someone's memory of a Slack thread from three weeks ago.

• What belongs in the PR body before review starts?

  Scopes that match the folders in the diff, smoke-checked links if docs changed, owners beside any MCP connectors mentioned, and pasted or linked verification output. The test is simple: a reviewer who has never seen the repo should be able to approve the change from the body alone. If the body cannot carry that, the diff is not ready yet.

• Does upgrading Codex CLI replace the operating contract?

  No. A new version changes what the agent can do; the contract states what it may do and who answers for it. Faster shipping without matching explainability just moves the cost downstream, where the next reviewer pays it back with interest. Upgrade the tool and write the contract; they solve different problems.

Start with one repo

Count the connectors in your busiest repo against the number of named owners. If connectors win, contact us and we will map the contract onto that repo with your reviewers in the room.