After spending a few days with Codex, I've built out a configuration that's different from my Claude Code setup in some interesting ways. The tools are similar in concept — both live in the terminal, both can execute tasks, install things, and act as a coding partner. But the configuration approach diverges.
Here's what my Codex setup looks like.
Model and Core Settings
Codex is configured to use gpt-5.4 with high reasoning effort. This is OpenAI's current top-tier model for coding tasks. The high reasoning setting means it thinks through problems more carefully before responding — slower on simple tasks, but significantly better on multi-step or ambiguous ones.
On Windows, Codex runs in elevated sandbox mode. This gives it the permissions it needs to interact with the filesystem, run commands, and manage processes without constantly hitting permission walls. I've marked my active development projects as trusted, which means Codex can operate on them without approval prompts for every action.
MCP Servers
This is where the Codex setup gets interesting. I'm running five MCP servers:
GitHub MCP
Connects Codex to GitHub via the official @modelcontextprotocol/server-github package. This gives Codex direct access to repository operations — searching repos, reading code, checking PRs, and more — without needing to leave the terminal or context switch to a browser.
Supabase MCP
Two Supabase projects connected. Codex can query databases, check migrations, and interact with project data directly. This is useful when debugging data issues or verifying what's actually in the database during development.
Vercel MCP
Direct connection to Vercel for deployment operations. Codex can check deployment status, read build logs, and manage project settings without opening the Vercel dashboard.
Playwright MCP (MS Edge)
Same MCP I run on Claude — browser control via Microsoft Edge. Codex can navigate to URLs, take screenshots, click elements, and verify that what got deployed actually looks right. Useful for visual verification after pushing changes.
Claude-Mem MCP
This one is the most interesting. I'm running the same claude-mem MCP server for Codex that I use for Claude Code. Both tools connect to the same memory database.
What this means in practice: when Claude Code writes an observation at the end of a session — a decision made, a pattern established, context about a project — Codex can read it in the next session. And vice versa. The memory is shared.
This came together while I was using both tools in the same week. It made no sense to maintain two separate memory stores when both tools were working on the same codebase. So I wired them to the same claude-mem instance.
RTK Integration
RTK (Rust Token Killer) is configured for Codex as well. The same CLI proxy that compresses git log, cargo test, and other command output for Claude also works for Codex sessions. Terminal output gets stripped of noise before it enters the context window — 60–90% compression on verbose commands. Less tokens spent on reading metadata, more tokens available for actual work.
The RTK documentation is stored in ~/.codex/RTK.md as a reference for how to use the proxy and what commands it supports.
Rules and Skills
Codex has its own rules and skills directories (~/.codex/rules/, ~/.codex/skills/). These are separate from Claude's rule system but serve the same purpose — shaping how Codex approaches problems in different languages and domains.
AGENTS.md
Codex uses an AGENTS.md file in project directories for persistent project context. This is similar to Claude Code's CLAUDE.md. It contains session history, decisions, and context about what's been built — about 500 lines of accumulated notes on the portfolio project alone.
How This Compares to My Claude Setup
The biggest difference is the MCP footprint. Codex is running more external integrations — GitHub, Supabase, Vercel — built into the config by default. With Claude Code, those integrations exist but I've kept the config leaner and rely more on skills and rules.
The shared claude-mem database is the intentional bridge. Both tools are doing different things well, and both now have access to the same running context about what we're building. It's not perfect — the memory formats are slightly different — but it's close enough that sessions feel continuous regardless of which tool I'm using.
Speed vs. cost is the practical tradeoff day to day. Claude executes faster. Codex costs less and has higher usage limits. For long autonomous sessions where I want to stay in flow, Codex is the right choice. For fast, targeted tasks where turnaround speed matters, Claude wins.
The setup is stable. Two tools, one shared memory layer, and enough configuration on each side to make the sessions genuinely useful.