SynaBun was built in conversation with Claude. That part is obvious. The hooks, the workflows, the war stories on this blog, the entire shape of the product so far. Claude has been the AI sitting in the room with us while most of this system got built.
But SynaBun was never supposed to belong to one model.
The whole point of SynaBun is that your AI should have infrastructure: memory that survives, a browser that stays logged in, a whiteboard it can draw on, a workspace it can share, and a record of what happened before. That idea is bigger than any single CLI.
So we are bringing Codex into the SynaBun ecosystem.
Why Codex Belongs Here
An AI workspace gets more useful when it stops assuming there is only one valid brain attached to it.
Different models are good at different things. One is better at architectural reasoning. Another is faster at implementation. One gives you the answer you wanted. Another gives you the answer you actually needed. If your workspace only works well with one of them, the workspace is the bottleneck.
SynaBun should be the opposite of that. It should be the layer that makes strong AI tools more usable over time, not the layer that forces you to pick a permanent favorite.
Codex fits that direction naturally. It is another serious coding agent with its own workflow, its own strengths, and its own style of operating in a real codebase. We do not want Codex sitting outside the SynaBun loop. We want it inside the same memory system, the same project surface, and the same collaborative environment.
This Is Not About Replacing Claude
Claude is not going anywhere. This is not a migration post. It is an expansion post.
The goal is not "switch from Claude to Codex." The goal is "stop treating AI sessions like isolated islands."
Right now, most AI workflows are still trapped in tool silos. You start in one assistant, build up context, make decisions, touch files, maybe store a few notes, and then if you want another model involved you basically start over. Even when the files are shared, the session is not. The reasoning chain is not. The momentum is not.
That is the real problem.
The Problem: Shared Files, Fragmented Sessions
A shared repository is not the same thing as a shared working session.
You can have Claude and Codex both pointed at the same codebase and still lose a stupid amount of time re-explaining everything:
- what the task actually is
- what was already tried
- which files matter
- which decisions are tentative
- which decisions are locked
- what the current blocker is
- whether the last agent was planning, debugging, or halfway through a fix
That is friction. And it compounds.
SynaBun already solves part of this with persistent memory, shared workspaces, and linked terminal sessions. But the bigger step is making the session itself portable enough that one AI can hand work to another without the whole thing collapsing into manual recap.
The goal is not to make Codex behave like Claude, or Claude behave like Codex. The goal is to let both of them participate in the same long-running thread of work.
What Cross-Compatible Sessions Actually Mean
We are not pretending Claude and Codex use the same native protocol. They do not. Their tools, formats, and session semantics are different.
So cross compatibility does not mean fake uniformity. It means building a shared handoff layer above them.
In practical terms, that means a SynaBun session should be able to carry the parts of work that actually matter across model boundaries:
- the project and active files
- the relevant memory set
- the task summary and current objective
- the recent decisions and open questions
- the important tool outputs
- the state of the workspace the next agent needs to continue
Start in Claude. Hand off to Codex. Continue in the same workspace without rewriting the entire story from scratch. Or do the reverse. Use Codex for implementation pressure, then bring Claude back in for review, planning, or cleanup.
Same project. Same memory. Same thread of work. Different AI.
Why This Matters
Once sessions become portable, model choice becomes tactical instead of permanent.
That changes the shape of AI development.
You can use the model that is best for the phase you are in instead of the model you happened to start with. Teams can keep their preferred agent without breaking collaboration. Shared workspaces become genuinely multi-agent, not just multi-terminal.
This also makes SynaBun more honest as a product. We already believe the infrastructure layer matters more than the chat box. Memory, browser state, workspace visibility, and continuity across time are the durable parts. If that belief is real, then the system should work across more than one serious coding agent.
Codex is the next obvious test of that principle.
What We Will Build First
We are taking this in phases.
First: Codex becomes a proper participant in the SynaBun workspace.
Then: explicit handoff flows between Claude and Codex, where one session can package the current state of work for the other.
After that: deeper resume compatibility, where the handoff is not just a summary but a structured continuation layer built from memory, artifacts, file state, and session breadcrumbs.
That is the direction. Not one AI to rule the workspace. A workspace that can coordinate multiple AIs without erasing context every time you switch.
SynaBun started as a way to stop AI from forgetting. The next step is stopping sessions from becoming trapped inside whichever model created them.
Codex is joining the ecosystem. Claude is staying. The interesting part is what happens when they can both work the same thread without starting from zero.