OpenAI Codex talks to remote MCP servers through its configuration: add an mcp_servers entry pointing at https://<slug>.denkops.host/mcp, complete the OAuth login where your Codex version supports it, and your tools are available in Codex sessions. It is the fourth client in this series, and the server side is byte-for-byte the same as for the other three.
As before, this assumes a server deployed on DenkOps with "connector": true in denkops.json. That single flag is what puts a full OAuth flow in front of your /mcp endpoint, explained in the one-flag OAuth post.
How do I configure a remote MCP server in Codex?
Codex reads MCP servers from its config file. A remote server is an mcp_servers entry whose value carries the server URL:
[mcp_servers.my-tools]
url = "https://my-tools.denkops.host/mcp"Codex has been moving fast and the exact keys, and whether the CLI offers a command to add servers for you, vary by release. Treat the shape above as the idea, and check the Codex documentation for your installed version before copying it. What does not vary is the DenkOps side: one HTTPS URL, and everything behind it already running.
Does OAuth work from Codex?
Where your Codex version supports OAuth for remote MCP servers, the flow is the standard one your connector always serves. Codex fetches the OAuth discovery metadata from the connector's domain, registers itself through dynamic client registration, and opens a browser for the hosted login and consent screen. You approve once, and Codex holds a grant tied to your identity, not a shared secret in a dotfile.
There is no OAuth app to create anywhere, for this client or any other. Dynamic client registration means each MCP client registers itself at connect time, which is why the same URL can be handed to Claude, ChatGPT, and Codex without you touching a developer console.
Access is decided by the connector, not the client. The project owner sets the policy in the dashboard's Access tab: public, or an allowed-email list. A login from someone off the list fails at the consent step, before any tool call reaches your code. If a teammate's Codex cannot connect while yours can, the access list is the first thing to check.
Using the tools in a Codex session
Once configured and authorized, your tools sit alongside Codex's built-in abilities. Ask for outcomes and let the agent choose: it reads the tool descriptions and input schemas your server publishes over MCP. Because the server is hosted and always on, there is no local process for Codex to spawn, nothing to install on each machine beyond the config entry, and a redeploy on your side updates the tools for every connected client at once.
The one-URL story, completed
Four clients, one server, zero client-specific code. The DenkOps side is identical every time: https://<slug>.denkops.host/mcp, hosted OAuth with dynamic client registration, and an owner-controlled access list. The client side is only ever "where do I paste it": Claude web and desktop, Claude Code, ChatGPT, and now Codex. If you have not shipped the server yet, the starter gets you a live connector URL in one deploy.