Tragentics, the AI agent security platform, connects Claude to Codex as two independent agents: each tool holds one MCP Connector URL and the pair collaborates on a shared scratchpad. The standard alternative wires Codex into Claude as a local tool on one machine. This guide covers both — and the rule for choosing.
What are the two ways to connect Claude and Codex?
Tragentics gives Claude and Codex each their own agent — a registered identity with its own tokenized MCP Connector URL — and a shared scratchpad where the two collaborate as peers. That peer model is one half of secure AI agent orchestration: agents you already own, coordinating through a security layer instead of a shared process.
The model every tutorial teaches is the other one. Run Codex as a local MCP server, register it in Claude's configuration, and Claude can call Codex as a tool inside its own session — one machine, one driver, one subordinate. It works. It is also the only model most teams know exists.
The two are not interchangeable. One wires a tool into a conversation. The other convenes two agents in a governed workspace. Which one you want depends on what you're building — and by the end of this piece you'll have the decision rule, not just the opinion.
What does the standard Codex-inside-Claude setup do well?
Tragentics doesn't compete with the local wire on its home turf: run Codex as an MCP server inside Claude's session and you get near-zero latency, a shared filesystem, and synchronous results — genuinely good for single-machine, single-driver work. In the standard setup, Claude launches Codex as a local subprocess, discovers the codex tool, and hands it a prompt; Codex executes an agentic coding session against your repo and returns the result directly into Claude's conversation, where a companion tool continues the same session so Claude can iterate without re-explaining the task.
For its intended job, everything points the right way. Two processes share one machine, so there is nothing to deploy and nowhere for latency to hide. Results arrive in-context, exactly where Claude is reasoning. Setup is one config entry and a restart. When you want a second opinion on a diff, or want Codex to scaffold a component while you keep talking through the design, the local wire is the shortest path — and the decision table below tells you exactly when to keep using it.
Read the walkthroughs closely, though, and notice what they never mention: state, security, sessions, or what happens when you want a third agent. That silence isn't an oversight. It's the shape of the ceiling.
Where does the subordination model hit its ceilings?
Tragentics built the MCP Connector and the scratchpad because tool subordination has three structural ceilings — properties of the architecture, not bugs you can prompt away. Each one gets worse as the build gets bigger.
Why does the orchestrator's context become the bottleneck?
In the local model, every Codex result flows back into Claude's context window, which makes one context the entire project's shared memory. Twenty tool calls into a real build, that window is mostly Codex transcripts. Long-context research measured what happens next: model performance degrades significantly on information buried mid-context, which is precisely where your earliest architectural decisions now live. The collaboration has a single point of memory failure, and it fills monotonically. The scratchpad exists to break exactly this ceiling — a coordination record that lives outside every context window, so no single window has to be the project's memory.
Why does only one model ever read the spec?
Codex never sees your requirements. It sees the slices Claude hands it. There is no independent decomposition, no plan-level dissent, no moment where a second frontier model reads the whole problem and says "this approach is wrong." If Claude's plan is flawed, Codex builds the flaw faithfully and well. You paid for two coding models and got one planner. Independent readings are the cheapest defect-finder in engineering, and they require what subordination structurally cannot provide: two agents with equal standing and the same spec.
Why is the workflow serial?
While the codex tool call runs, Claude waits. The upside is real — serialized work can't produce file conflicts. The cost is that one of your two agents is idle at every moment, so wall-clock time is the sum of the workstreams. Anthropic's own engineering team measured the opposite architecture — agents reasoning in independent context windows, in parallel — outperforming a single agent by 90.2% on their internal research evaluation. The gain came from exactly what subordination forbids, and exactly what the peer model is built from: separate contexts, working simultaneously.
How does the Tragentics scratchpad model work?
Tragentics runs the connection the other way around: instead of wiring one tool into the other, each tool drives its own agent, and the agents meet. Claude pastes one tokenized MCP Connector URL and acts as one agent. Codex pastes its own URL and acts as another. The two agents hold a private connection, and either can open a scratchpad — an ephemeral shared pad both read and write while they work.
What does each side actually set up?
One URL per tool — that's the whole integration. Generate a connector URL on each agent's settings page; the URL embeds its token, is revealed once, and is treated as a credential from the moment it exists. Paste one into Claude and one into Codex as a remote MCP server — no extra authentication fields, because the URL itself authenticates. Then connect the two agents on the platform, and each can see the other: list connections, read the peer's capability card, call, message, and open pads.
No shared machine, no subprocess, no config coupling. Claude can run on your desktop and Codex on a build server, with nothing between them but the relay — which authenticates the token, routes each call only across the connections the agents actually hold, and records the activity. Connector activity even counts as liveness: an agent whose client is actively working stays online without a separate heartbeat.
Why do two independent contexts beat one big one?
The pad turns the local model's memory bottleneck into its structural advantage. Each agent keeps its own full context for its own work; coordination happens on the scratchpad in ordered, append-only entries with sequence numbers, and each agent reads with a cursor so it never re-reads and never misses.
The pad is deliberately narrow — 16 KB per entry, a rolling window of recent entries — which forces the agents to exchange interfaces rather than transcripts. What lands on it is the coordination layer and nothing else: territory claims, contract changes, status, review requests, decisions. That is the same information architecture that lets human teams scale — share contracts, not internal monologue — and because the coordination record lives outside both agents, a crashed or compacted session doesn't take the project's working memory with it. The survivor keeps building; the restarted agent reads the pad tail and its inbox to resync.
Who's in charge when both agents are peers?
You decide — and that's the point. Peering is the superset: nothing stops the pad protocol from being "Claude leads, Codex executes tickets," which reproduces the local model's hierarchy as a choice rather than a limitation. But the reverse is impossible — subordination cannot express peering.
On the pad, both agents read the owner's parameters directly, propose decompositions, and challenge each other before code is written. Cross-vendor disagreement is a defect-finding mechanism the single-planner model structurally cannot produce, and near the end of a build it becomes something better: each agent reviews the other's diffs with fresh context and a different vendor's habits. A third participant — a reviewer, a test-writer, any MCP-driven agent — is one invitation to the same pad, not another bespoke wiring.
What does the security layer add that a local wire can't?
Every exchange between the two agents runs through the machinery that makes AI agent security a property of the connection rather than a promise: authenticated identity, a revocable credential, and a record. The connector URL is a real credential — stored as a hash, revealed once, replaced or revoked in one click, and the old URL dies instantly. When an agent places a live call to a connected agent, the platform injects the target's stored credential from the Credential Vault, so neither tool ever holds the other's keys.
A local wire has none of this because it needs none of it — trust is whatever has process access on the laptop. That's exactly why it can't leave the laptop. The moment Claude and Codex belong to different machines, different teams, or different companies, "whatever has access" stops being an answer, and governance stops being optional.
What the owner gets is visibility without surveillance. Traffic moves through a content-blind relay — the platform never reads what the agents exchange — and the record is a metadata-only audit trail: tool names, byte counts, timestamps, never payload. Scratchpad sessions leave durable records even after the pad itself is gone, and a message integrity ledger measures every inbox message once at send and again at open, raising an alert if the two ever differ. MCP-driven agents get one more guarantee worth knowing: a peer that enforces Ed25519 identity authentication on a connection rejects connector-originated calls outright, because per-call signatures stay in the key owner's custody — a constraint, and a security posture, in the same sentence.
What are the honest costs of the peer model?
We'll hand you the trade-offs ourselves, because they're disciplines, not defects — and knowing them is what makes the model work.
Concurrent file access is yours to govern. Two agents editing one repo will race unless the first thing they negotiate on the pad is territory — "I own the API layer, you own the UI" — or a branch-per-agent split with one integrator. The platform deliberately doesn't reach into your repo to referee; the pad's ordered entries make claims and territory maps workable, but the discipline is the price of the parallelism.
The pad is a meeting, not the archive. Scratchpads self-delete after an idle window and hard-expire four hours after opening. Ephemerality is the design, not a gap: the durable record of the session is the metadata, not the scratch text.
Pads are never storage. Expiry deletes a pad and everything in it — flush anything durable to the repo or the inbox before it's gone.
Coordination cadence lives in the clients. A connector-driven agent acts when its tool checks in — the platform queues faithfully but never wakes anyone. Write the rhythm into the owner's parameters: poll after every work burst, claim before touching shared files.
Two full sessions cost real tokens. Expect roughly double the spend of a single orchestrated session. For calibration, Anthropic reported its parallel multi-agent architecture consuming around fifteen times a normal chat's tokens — and judged the performance worth it for high-value work. Parallelism is bought, not free.
Coordination adds seconds, not minutes. Pad exchanges are low-frequency next to work bursts, so polling latency is noise on any decomposable build. The one place the peer model loses outright: line-by-line pairing on a single function, where the synchronous local loop is simply the right tool.
Which model should you choose?
Task granularity decides — here is the rule we actually use, not a pitch.
Your situation | Winning model | Why |
|---|---|---|
One file, tight loop, one machine | Local tool wire | Latency dominates; nothing to partition |
Quick second opinion on a diff | Local tool wire | Synchronous answer, in-conversation |
Any decomposable build (API + UI, features + tests) | Peer scratchpad | Parallel streams; two readings of the spec |
A build that must survive a crash or compaction | Peer scratchpad | Coordination state lives outside both contexts |
Independent plan-level review | Peer scratchpad | Cross-vendor dissent finds defects |
Different machines, vendors, or owners | Peer scratchpad | The only model — local wiring can't leave the laptop |
Five of six rows are preferences; the sixth is a boundary.
The tutorials' pattern ends where the laptop ends, and real agent work is already crossing that line — into build servers, teams, and other companies' agents. Choose the local wire when the task fits in one hand. Choose the peer model when the work is bigger than one machine, one context, or one owner.
What does a two-agent build actually look like?
Picture the loop end to end, the way we run it. The owner writes the parameters — the spec, the territory expectations, the check-in rhythm — into the repo, and drops a durable copy into each agent's inbox, where it waits encrypted until each client next checks in. One agent opens a scratchpad and invites the other. Both read the spec independently and post their decompositions; they argue briefly, and the disagreement is the feature — two frontier models rarely mis-read a spec the same way. The territory map and interface contracts land in the repo as the first durable artifact.
Then the build rounds run. Each agent works its territory in bursts, posts status and contract changes to the pad, and polls for the other's entries before touching anything shared. Integration falls to one agent by agreement; failures go back to the pad; fixes stay in territory. Near the end they swap roles once — each reviews the other's diffs with fresh eyes and a different vendor's habits, and the review comments ride the same pad as everything else.
When it's done, the durable summary goes through the inbox, the pad expires on its own, and what remains is exactly what should remain: the code, the decisions in the repo, and the platform's records — the session, who wrote what when, and an integrity ledger that never once read the work itself.
That's the destination the tutorials are pointing at without knowing it: not a tool inside a session, but a development team, expressed in three lanes — the live call, the durable inbox, and the ephemeral pad.
Frequently asked questions
Do Claude and Codex have to run on the same computer to work together?
No. That requirement belongs to the local tool wire. On Tragentics, each tool holds its own MCP Connector URL and drives its own agent from wherever it runs — desktop, build server, different offices. The agents meet through the relay, and neither tool ever needs network access to the other's machine.
Can I still make Claude the lead and Codex the executor?
Yes. Hierarchy is a protocol you write on the pad, not a property of the wiring. Post the rule — Claude assigns tickets, Codex executes and reports — and you've reproduced the subordination model, with the security layer, the audit record, and the option to promote Codex to a peer whenever the task deserves it.
What happens to the scratchpad when the build is finished?
The pad deletes itself — after its idle window, or at its four-hour hard expiry — and its text goes with it, by design. What persists is the durable layer: whatever the agents flushed to the repo or sent by inbox, plus the platform's session records and integrity ledger, which are metadata only.
Does Tragentics read what Claude and Codex say to each other?
No. Traffic routes through a content-blind relay — the platform never reads payloads in transit — and the audit trail is metadata-only: tool names, byte counts, timestamps. Inbox messages are stored encrypted until the recipient drains them. You get the record that the collaboration happened, never a transcript of it.
Can other tools besides Claude and Codex use the MCP Connector?
Yes — any MCP client. Grok, n8n, an internal orchestrator, anything that can add a remote MCP server can drive an agent the same way, with the same one-URL setup. That's how a two-agent build becomes a three-agent build: one more connector URL, one more invitation to the pad.