Check Codex MCP Access

To check MCP access in OpenAI Codex, OpenAI's coding agent, list the MCP servers configured for your Codex CLI environment, then verify each one with a tiny task that uses it. Do not stop at seeing a server name; prove the server works inside the repo workflow your team actually uses.

MCP is the Model Context Protocol, a standard way for coding agents to connect to external tools such as GitHub, docs, databases, and internal systems. For Codex CLI workflows, the useful habit is simple: inventory the enabled servers, document the boundary in AGENTS.md, and require a verification loop before any diff is reviewed.

Check what Codex can reach

Start with the local Codex CLI MCP inventory. In a current Codex CLI setup, that usually means running the CLI's MCP listing command, such as codex mcp list, and comparing the result with the team-approved config for the repo or workstation.

This is the direct answer to how to check enabled mcp in codex: list the configured servers, then test the ones that matter. A Codex MCP server that appears in config but cannot authenticate, start, or answer a small request is not truly available for production work.

Do not treat MCP as global background magic. A server may be installed on one developer machine, missing in CI, or intentionally disabled for a sensitive repo. Put the exact expectation in your local Codex CLI workflows docs so a teammate can reproduce it without guessing.

Put the MCP boundary in AGENTS.md

AGENTS.md is the repo instruction file that tells Codex how to behave in a codebase. Use it to explain which MCP servers are allowed, what they are for, and when Codex should ask before using them.

For example, a payments repo might allow a GitHub MCP server for issue context and pull request lookups, but forbid database access unless the task explicitly asks for it. That boundary matters because Codex will otherwise optimize for task completion, while your team still owns access control and review quality.

Keep this short. Avoid writing a policy essay that nobody maintains. A good AGENTS.md note is more like a guardrail than a handbook.

Verify the server inside the real loop

After inventory, run one small Codex CLI task that needs the enabled server. Ask Codex to fetch a linked issue, summarize a design doc, or inspect a pull request thread, depending on what the server is supposed to provide.

Then make Codex produce a reviewable diff or a no-change note. A healthy loop looks like this: gather context through MCP, edit the code, run the repo's checks, and summarize what changed with file paths and test results.

Do not test MCP with a toy prompt that never touches the production workflow. A codex cli mcp server is useful only if it survives the same loop your team uses for real changes: branch, edit, verify, review.

For a nearby example of turning a Codex app update into a workflow check, see Codex Workflow After App 26.616.

Treat app updates as workflow audit prompts

The official Codex changelog entry for Codex app 26.616, dated June 18, 2026, is best treated as a reminder to re-check assumptions. The changelog is the source of truth for product changes, but your team still needs its own operational check for MCP, AGENTS.md, and verification habits.

This is especially important when developers use a mix of the Codex app and Codex CLI. The app version may change, the CLI version may change, and the configured MCP servers may be different across machines.

Do not assume that a product update automatically updates your team rules. Keep a lightweight review checklist, and run it when the CLI, app, repo rules, or MCP server config changes.

Paste this Codex MCP integration checklist

Copy this into a repo issue, onboarding doc, or AGENTS.md review. It is intentionally small enough to finish in one pairing session.

# Codex MCP integration checklist

## Inventory
- [ ] Run `codex mcp list` or the equivalent MCP inventory command for the installed Codex CLI version.
- [ ] Record each enabled Codex MCP server by name, purpose, owner, and auth method.
- [ ] Confirm the config source: local user config, repo setup notes, devcontainer, or team-managed bootstrap script.

## AGENTS.md boundary
- [ ] Add a short MCP section to AGENTS.md.
- [ ] Say which servers Codex may use without asking.
- [ ] Say which servers require explicit task permission.
- [ ] Say which servers are forbidden for this repo.

Example AGENTS.md note:

Codex may use the github MCP server to read issues, pull request comments, and linked design discussions for this repository. Codex must not use database, billing, or customer-data MCP servers unless the task explicitly grants that access. When MCP context changes the implementation plan, summarize the external context in the final response.

## Verification loop
- [ ] Run one tiny task per enabled server.
- [ ] Ask Codex to name the external context it used.
- [ ] Require a local check such as tests, typecheck, lint, or a no-change explanation.
- [ ] Review the final diff as normal code, not as trusted automation.

## Review checklist
- [ ] Does the diff cite the files Codex changed?
- [ ] Did Codex explain which MCP server was used and why?
- [ ] Are secrets, customer data, and private docs absent from the final patch?
- [ ] Did the verification command actually run in this repo?
- [ ] Is the AGENTS.md instruction still accurate after this change?

Common questions

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

  Run the Codex CLI MCP inventory command for your installed version, commonly codex mcp list, then compare the result with your team-approved config. The citable check is two-part: the server appears in the Codex CLI MCP list, and a tiny repo task proves it can start, authenticate, and return useful context.

• Is a configured Codex MCP server the same as an approved server?

  No. Configured means Codex can see or start the server; approved means your team has allowed that server for a repo, task type, and data boundary. Put approval rules in AGENTS.md, because that file travels with the codebase and gives reviewers one place to check expectations.

• Should MCP verification happen before every Codex task?

  No, not before every task. Verify MCP when the server is added, credentials change, the Codex CLI is updated, AGENTS.md changes, or the task depends on external context. For normal edits, a final summary naming the MCP server used is usually enough for review.

• What should Codex do when an MCP server is missing?

  Codex should say the server is unavailable and continue only if the task can be completed safely without that context. For production code, ask it to leave a no-change note or a narrower diff rather than guessing from stale memory, especially when the missing server contains issue, schema, or design context.

• Can I use the same MCP setup for every repo?

  You can share a baseline, but each repo should define its own boundary. A docs repo, internal platform repo, and payments repo rarely deserve the same external access. Use shared setup scripts for installation, then let nested or repo-local AGENTS.md files narrow what Codex may use.

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

Next step

Pick one repo and run the checklist against its current Codex setup. If the MCP boundary is not written down, add the AGENTS.md note before the next Codex-assisted change.

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.