In mid-2025 there was an awkward gap in the agent world: MCP had won as the way to give models tools, but OpenAI’s Codex, the cloud SWE agent, couldn’t speak it. Codex could run shell commands in its sandbox, and that was the opening. If the agent has a terminal, the terminal can be the MCP client. tmcp is that bridge: a single binary an agent invokes like any other CLI, using tmcp list to see its tools or tmcp call context7__resolve-library-id '{"libraryName": "express"}' to use one, while the binary handles the actual MCP session against local stdio servers or remote HTTP ones, custom auth headers included.
The environment dictated most of the engineering. A Codex sandbox is a fresh, minimal Linux box on every task: no Node, no Python, no package installs you can count on, and every process launch adds latency an agent multiplies by however many tool calls it makes. So the client is compiled with Bun into a standalone executable with zero runtime dependencies. It is cross-compiled for Linux x64/ARM64 and both Mac architectures, starts in under 100ms, and installs with one curl | bash line in the sandbox’s setup script. It also reads the mcp.json configs that Cursor and Claude Code already write, because nobody wants to maintain a second copy of their server list for one more client.
The agent gets a different binary, not a flag
The security model is the part I’d keep even if everything else changed. The obvious design is one CLI with an --agent-mode flag or a config option that restricts what the agent can do, and it’s wrong, because anything enforced by configuration can be un-enforced by an agent that can edit configuration, and editing files is the one thing coding agents are best at. So there are two binaries. The developer version does everything: parse configs, discover servers, write the tool manifest. The agent version, installed by a separate script, can do exactly two things: list the configured tools and call them. It contains no code paths for changing configuration, adding servers, or touching the manifest. The boundary isn’t a check the agent might route around; it’s capability that simply isn’t present in the executable the agent has. The same “make the boundary structural, not procedural” instinct runs through Zodex and spaceship-cli.
The human stays in the loop at the manifest: tmcp init connects to every server in the config, extracts each tool’s schema, and writes a tools.json where every entry carries an enabled flag and a ready-made example invocation. Flip anything to false and the agent binary won’t offer or execute it. Curation is an edit to a JSON file you own, on a machine the agent’s binary can’t reconfigure.
The 1550-byte line break
My favorite detail in the repo is the least glamorous one. Codex’s cloud shell environment at the time crashed on output lines longer than 1600 bytes. It didn’t truncate them; it crashed, taking the agent’s turn with it. And MCP tool results are exactly the kind of output that produces five-kilobyte single-line JSON blobs. So every response tmcp prints is formatted to keep lines under 1550 bytes, breaking JSON intelligently at word boundaries while keeping the structure valid, so the agent can still parse what it reads. It’s three sentences of feature description and it was the difference between “works in the demo” and “survives real tool output in the environment this was actually built for.” Debugging your way to a number like 1550 is what building for agents mostly is.
The ecosystem eventually closed the gap. Codex got native MCP support, and this stopped being load-bearing infrastructure. But for its window it did the job: any agent with a shell got the whole MCP ecosystem, safely, in one binary.