AI client integration
Connect Codex through MCP Beast — one endpoint, every MCP server.
Add MCP Beast as the single MCP server in Codex's config and stop duplicating server entries and tokens across machines.
The token problem
How MCP setup in Codex normally sprawls.
Codex configures MCP servers in its local config, and every server needs its own credentials wired in — usually via environment variables. The same list, with the same secrets, gets recreated on every machine where Codex runs, which makes rotation a multi-machine chore and leaves token copies scattered through dotfiles.
Credential copies in client configs are also a security problem, not just a chore — see the token-passthrough discussion in our MCP security guide.
How it works
Point Codex at one endpoint.
Connect your MCP servers to the MCP Beast Mac app once; tokens go into the macOS Keychain.
Add one MCP Beast entry to Codex's MCP configuration.
Codex reaches every downstream server through that single entry, and the gateway's semantic routing keeps tool schemas out of Codex's context until they're needed.
This is the core of the gateway model: clients connect through MCP Beast, servers are connected to it. Read the full picture in the MCP gateway guide.
FAQ
Codex + MCP Beast questions, answered.
Does Codex work with an MCP gateway?
Yes. MCP Beast is a standard MCP endpoint, so Codex treats it as one configured server while the gateway fans requests out to everything connected behind it.
Where do server tokens live in this setup?
In the macOS Keychain, managed by MCP Beast. Codex's config holds only the gateway entry — no per-server secrets in dotfiles.
Can Cursor, Claude Code, and Codex share the same gateway?
That's the point: connect each server to MCP Beast once and every AI client on the machine uses the same endpoint and the same single copy of each credential.
Get started
Give Codex one endpoint to rule them all.
Walk through routing, credential isolation, and audit for your stack with us.