Check MCP Access in Codex

To check enabled MCP in OpenAI Codex, OpenAI’s coding agent, verify both the configured MCP servers and the tools reachable inside the active Codex CLI session. A server is only useful if it is configured, connected, allowed by your repo rules, and safe for the task.

Model Context Protocol, or MCP, is a standard way for coding agents to connect to external tools and data sources such as GitHub, issue trackers, docs, databases, and design systems. In a Codex workshop or codex cli training setting, the habit to teach is simple: check access before the change, record the boundary in AGENTS.md, then make Codex produce a reviewable diff.

Verify MCP in the same Codex session

Start with the Codex CLI, not a screenshot of someone else’s setup. Run the CLI’s MCP listing command for your installed version, commonly codex mcp list, then check the active session with the MCP-related slash command if your version exposes one.

The important distinction is config versus reachability. A codex cli mcp server can appear in local config but still fail because an environment variable is missing, a token expired, the command is not installed, or the repo policy blocks the use case.

A good first prompt inside the repo is short:

Before changing files, list the MCP servers and tools you can actually access in this session. Then say which ones you will not use for this task and why.

That prompt gives you a session-level receipt. It also makes the Codex agent slow down before pulling context from outside the repository.

For a narrower audit pattern, see Verify Codex MCP Access. For broader training paths, keep this habit with the related training topic.

Put MCP boundaries in AGENTS.md

AGENTS.md is the right place to write durable repo instructions for Codex workflows. Keep it boring and specific: which MCP servers may be used, what they are for, and what must stay out of scope.

The trap is writing “use MCP when helpful.” That sounds flexible, but it gives reviewers no way to know whether the agent used the right source or crossed a team boundary.

Here is a small example from a production repo pattern:

# AGENTS.md

## MCP access rules

- Before editing files, check which MCP servers are reachable in the active Codex CLI session.
- Use the GitHub MCP server only for reading issues, pull requests, and code review comments for this repository.
- Do not use MCP to mutate production systems, secrets, billing settings, customer data, or deployment state.
- If an MCP server is unavailable, continue with local repository context and mention the missing server in the final note.
- For every change, include the verification command, test command, and files changed in the final response.

That is enough for a codex team to review behavior without turning the repo instructions into a policy novel. Nested AGENTS.md files can narrow the rule further for sensitive directories such as infra/, billing/, or data/exports/.

Turn the check into a production loop

The practical answer to how to check enabled mcp in codex is not one command. It is a loop: list servers, confirm reachable tools, state the boundary, make the change, run verification, and review the diff.

Use this loop for real work, not only demos:

1. codex mcp list
2. Start Codex in the target repository.
3. Ask Codex to summarize reachable MCP tools for this session.
4. Confirm which MCP sources are allowed by AGENTS.md.
5. Ask for the smallest safe code change.
6. Run tests, lint, typecheck, or the repo-specific verification command.
7. Review the diff before merging.

This works well for OpenAI Codex training because it teaches the shape of safe autonomy. Codex can gather context, but the team still owns the boundary and the final diff.

The limitation is that MCP does not replace normal engineering verification. If a codex mcp server can read a ticket, that does not prove the implementation is correct. Tests, typechecks, logs, and human review still matter.

Treat changelog notes as prompts to re-check

As of June 22, 2026, the official Codex changelog includes an entry titled “ChatGPT for iOS 1.2026.167.” A mobile app version marker does not, by itself, prove anything about your local Codex CLI MCP configuration.

It is still a useful governance reminder. When a product surface changes, teams should re-check the workflow they actually depend on: CLI version, MCP server config, AGENTS.md rules, and verification commands.

The trap is assuming all Codex surfaces behave identically. A ChatGPT for iOS changelog entry, a Codex CLI feature, and a repository-local MCP setup are different layers. Check the layer you are using.

Paste this MCP integration checklist

Use this as a PR checklist, onboarding note, or workshop handout. It is intentionally small enough that people will actually use it.

# Codex MCP Integration Checklist

## Setup
- [ ] I know where this repo defines Codex instructions (`AGENTS.md` or nested `AGENTS.md`).
- [ ] I ran the Codex CLI MCP listing command for my installed version.
- [ ] I confirmed the active session can reach the expected MCP servers.
- [ ] I know which MCP server is allowed for this task and which servers are off-limits.

## Boundary
- [ ] The task does not require MCP access to secrets, production data, billing, or deployment state.
- [ ] If external context is needed, Codex will read only the minimum relevant issue, PR, doc, or design record.
- [ ] If MCP is unavailable, Codex will continue from local repo context and report the missing access.

## Change loop
- [ ] Codex states the intended files before editing.
- [ ] The diff is small enough to review in one pass.
- [ ] Tests, lint, typecheck, or the repo-specific verification command ran.
- [ ] The final response includes MCP used, commands run, files changed, and known caveats.

## Review
- [ ] No generated change depends on an unreviewed external assumption.
- [ ] No MCP-powered action mutated an external system.
- [ ] The PR description includes any MCP context that shaped the change.

A checklist like this is better than a long policy nobody reads. It gives the Codex agent a route and gives the reviewer something concrete to inspect.

Common questions

• How do I check which MCP servers are enabled in Codex?

  Check the Codex CLI MCP list for your installed version, then confirm reachability inside the active repo session. The citable artifact is the session receipt: server names, reachable tools, allowed use, and unavailable servers, ideally copied into the final Codex response or PR notes.

• Is codex mcp list enough by itself?

  No, a list command is necessary but not sufficient. It can show configured servers, while the active session may still fail because of auth, missing binaries, network rules, or repo instructions. Always pair the list with a live reachability check before relying on MCP context.

• Where should AGENTS.md mention MCP rules?

  Put broad MCP rules in the root AGENTS.md and stricter rules in nested files near sensitive code. A good boundary names the allowed codex mcp server, the permitted read or write behavior, and the fallback when access is unavailable.

• Should every engineering repo use the same MCP setup?

  No, shared defaults are useful, but repo risk should decide access. A documentation repo may safely use a docs or GitHub MCP server, while an infrastructure repo may require tighter rules, extra review, or no external mutation at all.

• Does a ChatGPT for iOS changelog entry change my Codex CLI workflow?

  Not automatically. Treat the June 22, 2026 “ChatGPT for iOS 1.2026.167” changelog entry as product recency, not proof that your local Codex CLI MCP setup changed. Verify the CLI, repo instructions, and active session you are actually using.

Further reading

• OpenAI Developers — Codex quickstart
• OpenAI Developers — Codex CLI
• OpenAI Developers — Codex CLI features
• OpenAI Developers — Codex slash commands
• Model Context Protocol — specification
• GitHub — openai/codex
• GitHub — openai/skills
• OpenAI Developers — Codex changelog

Make the check boring

Add the checklist to your repo, run it on the next Codex-assisted change, and keep the final diff small enough for a teammate to review without archaeology.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.