This guide covers the ten MCP servers worth connecting to Codex, and the three that keep appearing on other lists but should not be on yours. The first is the Bright Data MCP, which closes the gap Codex cannot close on its own: reading the live web from pages that defend themselves. You will learn:
- How MCP support in Codex actually works in 2026, including what changed and what most guides still get wrong.
- Which ten servers earn their place, with the exact TOML for each.
- What every server costs you before it does any work.
- Which popular servers to skip, and why two of them are security problems rather than preferences.
A note on method, because most lists in this category are vague about it. We could not obtain credentials for every vendor here, so this guide does not claim to have run all ten end to end. Every configuration block below is taken from the vendor’s own documentation or repository, every tool count is the documented count rather than a runtime tools/list result, and where a vendor has published no Codex instructions at all, the entry says so plainly.
The ten, at a glance
| # | Server | What it adds to Codex | Transport |
|---|---|---|---|
| 1 | Bright Data MCP | Unblocked scraping, multi-engine search and structured data from 100+ platforms | Remote HTTP |
| 2 | Context7 | Version-accurate library docs, at a cost of two tools | Both |
| 3 | GitHub MCP Server | Issues, pull requests, Actions and code search | Both |
| 4 | Chrome DevTools MCP | Performance traces, console and network from a real browser | stdio |
| 5 | Serena | Symbol-level navigation and refactoring via language servers | stdio |
| 6 | Sentry | What actually broke in production, with stack traces | Remote HTTP |
| 7 | Postgres MCP Pro | Query plans, index tuning and workload analysis | stdio |
| 8 | Playwright | Driving a browser through an accessibility tree | stdio |
| 9 | Figma | Design context instead of a screenshot | Remote HTTP |
| 10 | Linear | The ticket without the copy and paste | Remote HTTP |
What MCP support in Codex actually looks like in 2026
Start here, because a large share of the guides currently ranking for this topic are describing a version of Codex that has not existed since 2025. The claim you will keep meeting is that Codex speaks only stdio and cannot connect to remote MCP servers. That was true for about five weeks. Streamable HTTP support shipped in Codex 0.44.0 on 3 October 2025, and the experimental_use_rmcp_client flag that originally gated it was deleted outright in 0.77.0 that December. Any article still instructing you to set that flag is describing a no-op, and several vendor documentation pages have not caught up either.
What Codex supports today is stdio and Streamable HTTP, with bearer tokens, full MCP OAuth including Client ID Metadata Documents and Dynamic Client Registration, and ChatGPT session authentication for trusted first-party servers. What it does not support is equally worth knowing: there is no SSE transport and no WebSocket transport. A server that publishes only an SSE endpoint needs a stdio bridge in front of it, which is the single most common reason a config copied from a Claude Code tutorial fails in Codex.
Servers live in ~/.codex/config.toml under [mcp_servers.<name>], or in a project-level .codex/config.toml that Codex reads only in trusted projects. One file serves the CLI, the IDE extension and the ChatGPT desktop app. Transport is inferred rather than declared: give a server a command and it runs over stdio, give it a url and it runs over HTTP. There is no type field to set.
# stdio
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
# remote HTTP, token from the environment
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"The CLI covers the same ground without editing TOML by hand. codex mcp add <name> -- <command> registers a stdio server, codex mcp add <name> --url <url> registers a remote one, and codex mcp login <name> runs the OAuth flow. Inside a session, /mcp lists what actually connected, which is the first thing to check when a server appears to do nothing.
Every server you add costs something before it does any work
This is the part that separates a working Codex setup from a slow one, and it is almost entirely absent from other lists. Codex starts every enabled MCP server when a session opens, whether or not the model ever calls one of its tools. An OpenAI issue filed in September 2026 puts it plainly: Codex initializes and starts every enabled MCP server when a local session is opened, even if none of that server’s tools are used. Ten servers is ten processes or handshakes at every session start, and each one’s tool definitions occupy context for the whole session.
The tool counts make the arithmetic obvious. The official GitHub server documents around 88 tools, Playwright around 71, Chrome DevTools 57, Notion 35. Install those four together and the model is choosing from roughly 250 tool definitions before you have written a prompt. Codex gives you three levers that most guides never mention, and they are the difference between a useful server and an expensive one.
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
# trim the surface to the toolsets you actually use
enabled_tools = ["search_code", "get_pull_request", "list_issues"]
# reads run unattended, writes stop and ask
default_tools_approval_mode = "writes"
# a chatty tool cannot blow up the context window
[mcp_servers.github.tools.search_code]
output_token_limit = 25000enabled_tools is an allow list and disabled_tools is a deny list applied after it. default_tools_approval_mode takes auto, prompt, writes or approve, and writes is the setting most people actually want: read-only tools run unattended while anything that changes state stops and asks. tools.<tool>.output_token_limit caps what a single tool can return. Figma’s own documentation records a design-context call returning over 351,000 tokens, and where Claude Code answers that with an environment variable, Codex answers it here, per tool.
Two defaults will bite you before any of this does. Codex allows a server ten seconds to start and sixty seconds per tool call. Servers installed through npx or uvx routinely need longer on a cold cache, and the failure is quiet rather than loud: the session reports aggregating zero tools from one server and carries on. A developer on r/codex described the experience precisely in November 2025, after trying Serena, Context7 and Playwright on Windows: the installation guides make it look like you just open config.toml, add a snippet and it works, which leaves you assuming you have missed something basic. Usually you have only missed startup_timeout_sec.
What the Codex sandbox does not cover
Codex has a sandbox and a network allowlist, and it is easy to assume both extend to the servers you connect. They do not. The configuration reference is explicit on this in more than one place: the network proxy feature does not filter web search, apps, MCP or other hosted tools, and the experimental network domain list does not restrict web search, apps or MCP servers. A domain allowlist constrains what the agent’s own shell can reach. It does not constrain what an MCP server reaches on the agent’s behalf.
That is not an argument against MCP. It is an argument for treating each server as something with its own credentials and its own blast radius, which is why the approval and allow-list settings above matter more in Codex than the equivalent settings do elsewhere. It is also the reason two widely recommended servers are in the do-not-install section at the end of this guide rather than in the ranking.
1. Bright Data MCP: the live web, unblocked
Codex can already read a URL, and for an unprotected documentation page that is enough. The gap opens on the sites that most commercial work actually targets. Retailers, marketplaces, job boards and social platforms serve a different page to an automated client than they serve to a browser, and the failure is rarely a clean error. It is a page that returns, parses and contains the wrong thing, which is the worst possible outcome for an agent that will state the result with confidence.
The Bright Data MCP puts the whole web-data stack behind one endpoint: search across multiple engines, scraping that returns clean Markdown from pages behind bot management, structured extraction from over a hundred platforms, and browser automation when a page only yields to interaction. It exposes 69 tools in total, and it is one of the servers where trimming with enabled_tools is worth the five minutes. Every Bright Data account includes 5,000 requests per month at no cost and with no card, which is enough to evaluate it properly on a real task.
[mcp_servers.brightdata]
url = "https://mcp.brightdata.com/mcp?pro=1"
bearer_token_env_var = "BRIGHTDATA_API_KEY"
startup_timeout_sec = 20
tool_timeout_sec = 120
default_tools_approval_mode = "auto"Two of those settings are deliberate. Scraping a defended page can take longer than Codex’s sixty-second default allows, so tool_timeout_sec is raised. And because every tool here is a read against the public web rather than a write against your systems, auto approval is safe and removes the prompt-per-call friction that makes browser-style servers tiring to use. For the hosted server there is nothing to install; the local package is @brightdata/mcp if you would rather run it over stdio.
If you want the longer version of this setup, including running it against a real task end to end, see our guide to connecting Codex to Bright Data.
2. Context7: documentation that matches your installed version
The most common way a coding agent wastes an afternoon is confidently using an API that was renamed two minor versions ago. Context7 resolves a library to a specific version and returns its documentation, and it does this with exactly two tools. On a list where the alternative is 88, that ratio is the entire argument. It is the cheapest useful server here by a wide margin, and the first one to add.
codex mcp add context7 -- npx -y @upstash/context7-mcpIt runs anonymously, with an API key raising the rate limit and a free tier of 1,000 calls a month. The honest caveat is that quality varies by library: the criticism you will find in developer forums is that for less popular packages it returns the same thin slice of Markdown repeatedly. For widely used frameworks it is reliably better than the model’s training cutoff, which is the case that matters.
3. GitHub MCP Server: the other half of the job
Codex is already good at editing a repository on disk. What it cannot see is everything around the code: the failing Actions run, the review comment that explains why a function looks strange, the linked issue that describes the actual requirement. The official GitHub server closes that, and it is the one server on this list where the tool budget genuinely needs managing, with roughly 88 tools across 22 toolsets.
GitHub gives you the controls to do that: --toolsets or the GITHUB_TOOLSETS environment variable to load only the groups you need, --tools for individual selection, and --read-only to remove write access entirely. Start read-only. A prompt-injection route from a public issue into a private repository was demonstrated by Invariant Labs, and while GitHub has shipped mitigations, its own documentation is careful to say that lockdown mode is not an authorization boundary. Worth knowing too: many developers find the gh CLI covers the same ground more cheaply, since Codex can already run shell commands.
4. Chrome DevTools MCP: why the page is broken, not what it does
This one appears in OpenAI’s own Codex documentation and almost nowhere else, which makes it the most under-recommended server on this list. The distinction from Playwright is worth getting right, because they are not competitors. Playwright drives an application: click this, fill that, assert the other. Chrome DevTools MCP explains an application: performance traces, source-mapped console errors, the network waterfall, and thirteen heap-inspection tools for chasing memory. When Codex has written code that works but is slow, this is the server that tells it why.
It documents 57 tools, which --slim reduces considerably. It is Chrome-only by definition. And usage statistics are sent to Google by default, so add --no-usage-statistics if that matters in your environment.
[mcp_servers.chrome_devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--slim", "--isolated", "--no-usage-statistics"]
startup_timeout_sec = 30The --isolated flag is not optional in practice. Browser-driving servers fail under Codex with an error about the browser profile already being in use, and it happens even with full filesystem access granted. Running each session against a throwaway profile is the fix, and it applies to Playwright below for the same reason.
5. Serena: symbol-level edits instead of text search
Serena puts a language server behind MCP, so the agent works with symbols rather than strings. Find every reference to this function, rename this class across the project, read only the body of this method instead of the whole file. On a large codebase that is a different quality of operation from grep, and it spends dramatically fewer tokens to reach the same answer.
It earns its place here for a reason specific to Codex: Serena ships a --context=codex mode that disables its own tools which duplicate what Codex already has. That is exactly the context hygiene the rest of this guide argues for, done by the vendor rather than left to you.
[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex"]
startup_timeout_sec = 60The timeout is generous on purpose. Serena indexes a project on first run, and this is the server most likely to trip the ten-second default.
6. Sentry: what actually broke, from production
Pasting a stack trace into a prompt works. Letting the agent pull the issue itself, with the release, the breadcrumbs and the frequency, works better, and it stops you from being the bottleneck. Sentry’s remote server is plain Streamable HTTP with OAuth, so codex mcp login sentry is the whole setup.
One point of accuracy, since other lists imply otherwise: Sentry’s documentation has setup tabs for Claude Code, Cursor and VS Code, and none for Codex. OpenAI recommends it in the Codex documentation and the transport is fully supported, so it works — but nobody at Sentry has written the Codex instructions, and you should not expect a copy-paste path. Scoping the endpoint to /mcp/{org}/{project} hides the discovery tools and keeps the surface small.
7. Postgres MCP Pro: query plans, not just a connection
Most database MCP servers give the agent a way to run SQL. This one gives it a way to reason about SQL. It explains query plans, analyses a workload against pg_stat_statements to find the queries actually costing you, and simulates hypothetical indexes so the agent can test an idea before you build it. It does that with nine tools, and because it runs over stdio it sidesteps every remote OAuth failure mode on this list.
Two honest caveats. The maintainers have not published Codex instructions — an open request has sat unanswered since January 2026 — though a stdio block is trivial to write yourself. And point it at a replica, with --access-mode=restricted, before you point it at anything that matters.
8. Playwright: driving the application
Playwright MCP drives a browser through the accessibility tree rather than pixels, which makes it deterministic in a way screenshot-based automation is not, and it works across Chromium, Firefox and WebKit. For end-to-end tests and reproducing a reported bug, it is the obvious tool.
It is ranked eighth rather than higher because of an unusual signal: Microsoft’s own README now steers coding agents away from the MCP server, recommending the Playwright CLI and skills as more token-efficient and better suited to high-throughput agents, and positioning the MCP for specialised agentic loops. When the vendor tells you their own server is the wrong shape for your use case, that belongs in the ranking. Add --isolated, and expect approval friction: an open issue with substantial community backing reports that approval_policy = "never" still prompts on every call, which default_tools_approval_mode = "auto" on the server resolves.
9. Figma: design context instead of a screenshot
Handing an agent a PNG and asking for the component produces approximately the right thing. The Figma server hands it the variables, the tokens, the layout constraints and the component structure instead, and the output stops being an approximation. It documents 29 tools over remote HTTP with OAuth.
The constraints are real and worth checking before you plan around it. A Dev or Full seat is required; View seats get 20 tool calls a month. Figma restricts connections to clients in its own catalogue, and Codex is currently on that list, but it is a list. And this is the server that most needs output_token_limit — Figma’s documentation records a single design-context response of over 351,000 tokens.
10. Linear: the ticket without the copy and paste
A one-line setup that removes a small, constant tax: codex mcp add linear --url https://mcp.linear.app/mcp, then codex mcp login linear. The agent reads the issue, the acceptance criteria and the comment thread directly, and can move the ticket when it is done.
Note that this is not the same thing as Linear’s first-party Codex integration, which runs in the opposite direction — mentioning Codex in an issue to dispatch a cloud task. The MCP server is for local work in the CLI or IDE extension. If you have seen Linear’s own documentation mention the experimental_use_rmcp_client flag, ignore it; that flag has not existed since December 2025.
What not to install
These three appear on most comparable lists. Two of them are security problems and one is simply redundant, and leaving them out will make your Codex setup better rather than poorer.
- Filesystem MCP. Codex already has native file tools governed by its own approval system. Adding this server duplicates them while moving file access into a process outside that system, so you get less oversight rather than more. It also has a history of sandbox-escape vulnerabilities, CVE-2025-53109 and CVE-2025-53110, of the kind you do not want in the component that reads your disk.
- Slack. The official server declines Dynamic Client Registration and expects a directory-published or internal Slack app, which effectively rules out Codex CLI. The old npm package is deprecated and carries a data-exfiltration advisory. The popular community alternative authenticates with browser session cookies, which is very likely against your workspace policy.
- The community Atlassian server. Carries CVE-2026-27825, an arbitrary file write leading to remote code execution rated 9.1, alongside a separate SSRF issue. Atlassian’s official Rovo server exists and does not.
Wiring it up, and checking it worked
Add servers one at a time and confirm each before adding the next, because a failure at startup is quiet. Run /mcp inside a session to see what actually connected; a server that is configured but missing from that list has failed rather than loaded. If a server is absent, raise startup_timeout_sec first, since ten seconds is not enough for a cold npx or uvx download. If tools appear but Codex never calls them, that is a known behaviour rather than a broken config: name the server or the tool in your prompt once and it will start reaching for it.
Two more things that cost people an afternoon. Project-level .codex/config.toml is read only in trusted projects, so a config that works in one directory can silently do nothing in another. And if you configure servers through a plugin manifest rather than config.toml, the OAuth fields there are camelCase while everything in config.toml is snake_case.
Frequently asked questions
Does Codex support remote MCP servers?
Yes. Streamable HTTP shipped in Codex 0.44.0 on 3 October 2025, with bearer tokens and full OAuth including CIMD and Dynamic Client Registration. The experimental_use_rmcp_client flag that once gated it was removed in 0.77.0 in December 2025, so any guide still telling you to set it is out of date. Codex does not support SSE or WebSocket transports.
How many MCP servers should I install in Codex?
Fewer than you want to. Codex starts every enabled server when a session opens, whether or not its tools get used, and each server’s tool definitions consume context for the entire session. Four servers with trimmed tool lists will outperform ten installed as-is. Use enabled_tools to narrow each one and enabled = false to park the servers you only need occasionally.
Why does my MCP server show no tools in Codex?
Almost always the ten-second startup timeout. A server installed via npx or uvx can take longer than that on a cold cache, and Codex reports aggregating zero tools rather than an error. Raise startup_timeout_sec to 30 or 60 and try again. If the server is a browser one, add --isolated, which resolves a profile-locking failure that occurs even with full access granted.
Does the Codex sandbox restrict what an MCP server can reach?
No, and this is widely misunderstood. Codex’s configuration reference states that its network proxy does not filter MCP or other hosted tools, and that the experimental network domain list does not restrict MCP servers. A domain allowlist governs the agent’s own shell, not what a connected server fetches on its behalf. Treat every server as holding its own credentials and its own blast radius.
Can Codex scrape websites that block bots?
Not on its own. Codex can fetch a URL, but sites with bot management return a different page to an automated client, and the failure is usually silent rather than an error. The Bright Data MCP handles unblocking, multi-engine search and structured extraction from over a hundred platforms behind one endpoint, with 5,000 requests a month free and no card required.
The ten MCP servers worth connecting to Codex, with the exact TOML for each, what every server costs you before it does any work, and the three popular ones to skip. Bright Data MCP leads for unblocked web access.
