Codex Windows update: MCP and mobile use

To add MCP to Codex without losing your review loop, register each connector only for the repo scope that needs it, write down what it may read and write, and end every task in a diff you can check. MCP is the Model Context Protocol, the open standard that lets a coding agent reach outside systems like a database, an issue tracker, or a docs server. Codex CLI, OpenAI's coding agent, reads that connector list, your AGENTS.md rules, and your verification commands as one setup. The Windows update widens where work can start, including computer use and mobile access, but it does not change the rule that work must finish in a reviewable change.

Most teams that stall here are not short a feature. The work is just scattered across an ad hoc prompt, a loose shell habit, and a connector someone set up once and never wrote down. Pull those three together and the agent stops guessing.

Write down the MCP boundary before you connect anything

The common failure is simple: the agent can reach the right system, but nobody recorded the boundary. Setup turns into tribal knowledge, and reviewers end up guessing what a connector was allowed to touch.

Fix it with one short note next to your repo rules. Say what the connector may read, what it may write, and what needs a human to approve. Keep it beside AGENTS.md, not buried in a chat thread.

When the scope lives in the repo, setup stops being a memory test. New contributors see the allowed path, and reviewers check that path instead of reconstructing it. If the scope is not written down, treat it as not real.

Let the right AGENTS.md win in the right folder

Codex reads AGENTS.md, and you can add an AGENTS.override.md for exceptions. So the real question is not whether you have instructions. It is whether the correct rule wins in the folder where the agent is working.

Put your durable repo rules in AGENTS.md. Use AGENTS.override.md only for a temporary exception, and delete it once the task is done. Nested files should narrow scope, not pile on noise.

This is usually where teams get their speed back. The agent stops inventing architecture rules, and the diff starts matching the shape your repo already has. Keep the default rule small, then override only where a task truly needs it.

Close the verification loop with codex exec

If Codex can make a change but cannot prove it, you have a demo, not a workflow. The CLI docs make the headless path clear: use codex exec for automation, then verify the result before you trust it.

The loop is plain. Ask for the change, run the check, read the diff, and repeat until the output is boring. For a team that means tests, lint, or a targeted command that shows the change did what the prompt asked.

This is the step that turns agent work into something a reviewer can sign off on. It is slower than a blind accept and a lot faster than a broken merge. No verification, no ownership transfer.

Paste this checklist into your repo

Use this starter when you add MCP to a repo that already runs Codex CLI:

# Codex MCP integration checklist

- [ ] Add or update `AGENTS.md` with the repo rules Codex must follow.
- [ ] Add a short MCP boundary note: allowed systems, denied systems, and approval steps.
- [ ] Register the connector or server only for the repo scope that needs it.
- [ ] Decide whether the task belongs in `codex exec` or an interactive session.
- [ ] Define the verification command before the agent starts work.
- [ ] Run the command and inspect the diff before review.
- [ ] If the task repeats, move the steps into a `SKILL.md` package.
- [ ] If the task needs a temporary exception, use `AGENTS.override.md` and remove it after.
- [ ] Record what was verified in the pull request description.

It is short on purpose. It forces you to name the boundary, the instruction source, and the proof, which is the same trail a reviewer wants whether the work started in a terminal, on a Windows surface, or on a phone.

Common questions

• How do I add MCP to Codex? Register the connector or server for the specific repo scope that needs it, then write a one-line boundary note next to AGENTS.md covering what it may read, what it may write, and what needs approval. The Codex CLI docs cover the setup commands. Keep each connector scoped to the repo, not enabled everywhere by default.

• What is the difference between AGENTS.md and AGENTS.override.md? AGENTS.md holds your durable repo rules, the ones every task should follow. AGENTS.override.md holds a temporary exception you add for one task and delete afterward. Keep the default rule small so the agent rarely needs an override, and make nested files narrow scope rather than add new noise.

• When should I use codex exec instead of an interactive session? Use codex exec for headless automation, where a change runs and you verify it with a command. Use an interactive session when you want to steer the work step by step or explore an unfamiliar area. Either way, define the verification command before the agent starts, then read the diff before you accept anything.

• Does the Windows and mobile access change my review habit? No. Computer use and mobile access widen where work can begin, which helps teams move tasks around. They do not replace a local verification habit. The change still has to land in a reviewable diff with a clear check, no matter which surface it started on.

• How do I stop the same setup steps from being rewritten every time? When the same setup or review steps show up twice, move them into a SKILL.md package with a clear description and invoke it when the task is routine. That cuts prompt sprawl and gives the team one place to review the method. See the openai/skills repo for the package format.

Start with one connector

Pick the connector you are adding this week, write its boundary note, and define the verification command before you run it. For the full path and templates, see our Codex CLI workflows topic.