MCP servers in Codex: when they are worth it

Adding an MCP server to Codex takes one command. What you get is a connection that stays open across sessions, holds whatever credentials you gave it, and lets the model decide when to call it. That is the right shape for some work and an expensive default for the rest.

Try a CLI first

Codex runs shell commands inside its sandbox, under the same approvals as any other command. If the thing you want to reach has a command-line client — gh, kubectl, psql, a vendor's own CLI — Codex can drive it today, with nothing new installed, nothing new holding a token, and every call visible in the transcript as the command it was.

A server earns its place when that stops being enough: when you need live state the model can query in a form it can read, when authentication has to be handled once and refreshed on its own, or when the whole team should get the same tool by cloning the repository. If none of those is true of the task, the CLI is the lighter answer and the one you can reason about.

Three doors, one file underneath

Codex gives you three routes to a server: codex mcp add on the command line, the gear menu in the IDE extension, and the [mcp_servers.<name>] table in config.toml. All three write the same configuration, and the file is the one to read when you want to know what is actually connected.

The scope decision hides in the file's location. ~/.codex/config.toml is yours. A project-scoped .codex/config.toml is checked in, which means adding a server there is a decision you are making for every colleague who clones the repository. Treat it the way you would treat adding a dependency.

One boundary to know: ChatGPT on the web does not read local Codex configuration. A server you added at the terminal is not there in the browser, where tools come through plugins your workspace administrator controls.

Two options that reach further than they look

For HTTP servers the configuration carries two settings worth reading twice.

http_headers_helper is described as a "Local command that prints a JSON object of header names and string values". Codex executes that command to build the request headers. It is a useful hook for short-lived tokens, and it is arbitrary code running on your machine every time the connection is set up, so it deserves the same scrutiny as any hook.

auth = "chatgpt" uses your current ChatGPT session to authenticate to the server. Convenient for first-party origins, and it means the server acts with your identity rather than a scoped credential you issued for it. Read the trust decision before pointing that at anything you did not write.

What a server buys that a CLI does not

Live state, in a form the model queries rather than one you fetch and paste. Authentication handled once, including OAuth through codex mcp login, with stored credentials the model does not see. A shared configuration your team inherits from the repository.

Those are real. They are worth it when the integration is part of your daily loop. They are overhead — and a standing credential — when it is not.

What goes wrong

Reaching for MCP where a CLI exists. The CLI was already there, already scoped, already visible in the transcript.

A project-scoped server nobody discussed. It is a dependency with credentials, added for the whole team by one commit.

A helper command nobody read. http_headers_helper runs code. Read it as code.

Expecting the browser to see it. Local configuration stays local; ChatGPT web uses plugins.

Installing speculatively. Every configured server is a connection that persists after the task that justified it.

How to check it worked

Run codex mcp list and, for each server, name the task that needs it this week and the credential it holds. A server with an answer to the first question earns its place. One without is a standing grant to code nobody is watching, and codex mcp remove is cheaper than the alternative.