command + argsLocal stdio
Codex starts a local process and exchanges MCP messages over standard input and output. Environment variables can supply process configuration, but secrets still belong in the local credential boundary.
Client compatibility
MCP server compatibility in Codex
Codex can connect to local stdio servers and remote Streamable HTTP servers. That protocol support narrows the question; provider documentation, authentication, allowlists, permissions, and current product behavior decide the usable result.
Connection contract
The server must fit one of two Codex paths
Codex stores MCP configuration in config.toml and makes it available through its CLI and IDE surfaces. The desktop app can configure the same local host.
url + authStreamable HTTP
Codex connects to a remote MCP URL and can use OAuth or a bearer token supplied through configuration. Legacy SSE-only support is not part of the current Codex profile.
Direct provider evidence
Current hosted MCP comparisons for Codex
A documented result means the provider names Codex in its own setup material. A requirements match means the connection methods intersect without that direct claim.
| Client | GitHub MCP Server | Linear MCP Server | Figma MCP Server | Notion MCP | Atlassian Rovo MCP Server |
|---|---|---|---|---|---|
| Codex | Conditional | Documented | Conditional | Conditional | Conditional |
Setup sequence
Check compatibility before debugging the tool
Work from the outer contract inward. This separates an unsupported pairing from an authentication problem or a disabled provider capability.
Transport
Confirm that the server exposes stdio or Streamable HTTP, not only a legacy or proprietary connection path.
Authentication
Match OAuth, bearer token, or no-auth requirements and complete any interactive authorization on the Codex host.
Provider policy
Verify that the provider supports Codex, the account plan is eligible, and the organization has not disabled access.
Tool permission
Inspect the exposed tools and grant only the read or write scope needed for the task; a connected server is not blanket consent.
Common failures
A visible server can still be unusable
Connection health, discovery, and authorization are separate receipts. Preserve that distinction when a tool does not appear or a call is refused.
Configuration not loaded
Confirm the active Codex host, restart the surface after a configuration change, and inspect the MCP status or tool list.
Authorization expired
Re-run the provider login when OAuth consent, refresh tokens, or organization access has changed.
Provider restriction
A technically compatible endpoint can remain unavailable when the provider limits supported clients, plans, regions, or capabilities.
Evidence limits
What the matrix refuses to infer
ResolveMesh does not connect your Codex host or execute the provider tools behind these public endpoints.
A matching protocol proves availability
Standards overlap is evidence of likely compatibility, not proof that the provider permits or currently serves Codex.
A connected server is trusted
Tool descriptions, schemas, and results remain external input. Apply the same review and least-privilege rules after connection.
A write tool is authorized
Codex and the provider still apply user approval, account scopes, workspace policy, and action-specific validation.
Primary sources
References
The Codex contract comes from current OpenAI documentation; direct examples come from the provider that owns each server.
OpenAI: Model Context Protocol in Codex
Primary OpenAI reference for Codex MCP transports, authentication, configuration, CLI commands, and desktop sharing.
Read the primary sourceLinear: MCP server
Provider-owned example documenting a hosted Streamable HTTP server and direct Codex configuration.
Read the primary sourceFigma: Remote server installation
Provider-owned example documenting its remote endpoint, supported clients, and Codex installation path.
Read the primary source