Codex CLI MCP Server for Codebase Context

Codex CLI is built to run long, mostly unattended tasks in a terminal: a migration, a refactor, a multi-file bug fix, with minimal check-ins along the way. On a small repo that works because Codex can read every file that matters. On a large one, its default context strategy is reading and grepping through source files to reconstruct structure it was never given, and that costs tokens on every turn while still missing the parts of the codebase that never got opened. A shared helper renamed in one file, three callers in files Codex never read, and the task finishes green with a broken build waiting on the other side.

Symvanta closes that gap with an MCP server that hands Codex the actual code graph instead of a pile of text to search: exact symbol definitions and signatures, real caller and dependency edges, blast radius for a change before it ships, and cross-repo edges when the callers live in a different repository entirely.

Add MCP servers to Codex CLI

Codex keeps its MCP servers in ~/.codex/config.toml, and reads a project-scoped .codex/config.toml too when a server should only exist inside one repo. Each server is a TOML table named [mcp_servers.<name>], and the fields you set depend on the transport.

A local stdio server is a command Codex launches as a subprocess:

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["LOCAL_TOKEN"]

[mcp_servers.context7.env]
MY_ENV_VAR = "MY_ENV_VALUE"

command is the only required field. args, cwd, the env sub-table, and env_vars (names forwarded from your shell) are optional.

A remote streamable HTTP server is a URL:

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

url is required here. bearer_token_env_var names an environment variable holding a static token, and auth picks the login method (oauth or chatgpt) for servers that run a real sign-in.

The codex mcp subcommands write the same file, so the editor is optional. codex mcp add <name> -- <command> registers a stdio server, codex mcp add <name> --url <url> registers a streamable HTTP one, and --bearer-token-env-var attaches the token variable to either. codex mcp list prints what is configured, codex mcp login <name> runs the browser login for a server that needs one, and codex mcp --help covers the rest. Codex stores the variable name and never the token value, which keeps config.toml safe to check in.

Symvanta uses the remote shape and an OAuth login, so no token variable is involved.

Setting up Codex CLI with Symvanta

1. Create a free Symvanta account and connect GitHub. No card required to start.
2. Index your repos. Pick which ones Symvanta should parse into a graph. A webhook reindexes automatically on every push, so the graph Codex reads from stays current. Plans start at $19/month, with a 7-day trial on the Pro tier.
3. Add the Symvanta MCP server to ~/.codex/config.toml. Codex CLI supports remote streamable HTTP MCP servers natively, configured under an [mcp_servers.<name>] table:

[mcp_servers.symvanta]
url = "https://mcp.symvanta.com/mcp"
auth = "oauth"

auth = "oauth" is the default for streamable HTTP servers, so the line above is there for clarity more than necessity. If you would rather not open an editor, codex mcp add symvanta --url https://mcp.symvanta.com/mcp writes the same table from the terminal.

4. Authenticate. Run:

codex mcp login symvanta

This opens a browser for the standard OAuth PKCE flow and stores the resulting credentials for Codex to use on every session afterward. No API key to paste, no token to babysit.

5. Confirm the server is live:

codex mcp list

Once symvanta shows up there, Codex can call it in any session, including the long, autonomous ones this tool is built for.

What Codex gets

The graph covers TypeScript, JavaScript, Python, Java, Kotlin, C#, Go, Rust, Swift, PHP, and Ruby, so a polyglot repo gets the same precision on every language in it.

See the architecture pages for real module maps built this way on well-known open-source repos.

Long tasks surface what they break

The place this matters most is exactly the workload Codex CLI is built for: a task you kick off and check back on later, unsupervised in between. Take a migration that touches a shared authentication helper across a dozen call sites in three services. A grep-based approach finds the string, edits the definition, and reports success, because success from a text search perspective just means the pattern was found and changed. It has no way to know that two of those call sites route through an interface with a different name, or that a fourth service in a different repository imports the same helper and was never opened during the task.

Before Codex commits to that kind of change, a relate call with kind: blast_radius on the helper returns every real caller, across every indexed repository, ranked by confidence. That's the difference between a task that finishes and a task that finishes correctly: the graph doesn't stop Codex from making the edit, it stops Codex from being surprised by what the edit touches. We go deeper on why this specific failure mode is so common in agent-driven changes in blast radius analysis.

Frequently asked questions