Is Codex CLI giving MCP more reach than reviewers expect?

Codex CLI does not hand MCP servers any reach your own repo never granted them. Codex CLI is OpenAI's coding agent that runs in your terminal, and MCP (the Model Context Protocol) is the standard way it connects to outside tools and data. The reach reviewers fear is real, but it comes from a gap in your repo, not from the tool: nobody wrote down which actions each connector is allowed to take. Write that line, and the worry mostly goes away.

The version in front of most teams right now is Codex CLI 0.129.0, and the questions people bring to it cluster tightly: what changed in the release, how approval modes work, and what MCP support actually exposes. Those are three phrasings of one anxiety. The good news is that they all have the same fix, and it lives in your repo, not in a setting.

Write the allowed-actions line beside every connector

The single most useful artifact is a list of allowed actions next to each connector name in AGENTS.md. If a security reviewer can read that list and predict what a connector will and will not do, MCP stops being a mystery box.

This matters because a reviewable diff is a change someone unfamiliar can trace without replaying the chat. If an MCP server fired during a run, that has to leave a trail a reviewer can follow later, the same way a test or a migration does. A connector with no written boundary is a connector nobody can review.

So before you enable a second MCP server in any repo, add the boundary line for the first one. The Codex CLI docs cover the approval-mode switches; the boundary text is yours to author.

# AGENTS.md verification snippet

- Every Codex CLI run ends with a 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.

Keep AGENTS.md short enough to follow

A long AGENTS.md is worse than a short one. Once the file grows unchecked, Codex starts optimizing for the wrong definition of done, because the real intent is now buried under length.

Cap the top of the file with a definition of done in ten bullets or fewer, written in the words your team actually uses in review. Short and specific beats long and thorough here, because reviewers can hold ten bullets in their head and check the output against them.

The same instinct applies to slash commands. When they spread around undocumented, they turn into private folklore and operators drift apart. Keep a docs/codex-commands.md, link it from AGENTS.md, and check it against the official slash commands reference so the team shares one set of moves.

Make verification something a reviewer can see

The rule worth enforcing: every codegen step ends with a transcript snippet showing the tests ran. Exec shortcuts that skip tests let regressions slip back in quietly, and a green merge only means something when the test ritual actually happened.

Browser work needs the same treatment. Chrome-driven tasks can show reviewers a demo that disagrees with what CI produced, so document the staging URLs and credential boundaries right next to the browser task. Then the demo and the CI artifacts tell one story instead of two.

Here is the field checklist I hand teams, plus the strip reviewers tick before approving:

• Red-folder paths received explicit human acknowledgement.
• Scopes in the PR body match folders in the diff.
• Primary-doc links were smoke-checked after publishing edits.
• MCP connectors mentioned (if any) list owners.

Connector wiring itself is specified in the MCP specification, and the features page and quickstart cover capability and setup. Releases land in openai/codex. None of those docs name who approved your connector. That line is yours.

Common questions

• What stops Codex CLI from giving MCP servers more access than the team expects?

  One rule from this memo: if MCP servers are enabled, list allowed actions beside each connector name in AGENTS.md. The field checklist backs it by asking which MCP servers fired and whether they were expected, and the review strip requires every connector you mention to name an owner. Together they make a connector's reach predictable before a run, not after.

• What makes a diff reviewable in Codex CLI 0.129.0 workflows?

  A reviewable diff is a change someone unfamiliar can trace without replaying the chat. The receipt-match gate makes that testable: the PR body lists scopes plus the verification transcript, and the scopes named there match the folders actually touched in the diff. If a reviewer needs the original session to understand the change, it is not yet reviewable.

• How long should AGENTS.md be before it becomes a problem?

  Keep the definition of done to ten bullets or fewer at the top of the file. Once AGENTS.md grows past what a reviewer can hold in their head, Codex starts optimizing the wrong done, because the real intent hides in the length. Short and specific keeps agent output aligned with the vocabulary your team uses in review.

• What is the verification latch?

  The verification latch is the rule that every codegen step ends with a transcript snippet showing the tests ran. It exists because exec shortcuts that skip tests let regressions return quietly, so a green merge only means something when the test ritual is enforced and visible. It gives reviewers proof they can check instead of memory they have to trust.

Where to go next

Pick one repo and add the allowed-actions line beside every connector before you enable the next MCP server. If MCP reach is the argument blocking your rollout, our training installs these boundaries with your own repos on the table, and the rehearsal drills live under CLI workflows.