Run Claude Code, Codex and Gemini CLI in One App (2026)

To run Claude Code, Codex and Gemini CLI in one app (with Grok alongside them), you have three real options. You can put them in panes of a terminal multiplexer. You can give each one its own git worktree. Or you can use one conversation that several engines take turns answering. The first two are cheap and work well for parallel coding, but each CLI usually keeps its own history, tools and instructions, so switching models tends to start from nothing. The third is what you need if you want to use each model for what it is good at inside one thread. It only works if something solves memory, tools and prompt parity for every engine.

This post walks through all three patterns and names the tools in each. It also covers where each CLI actually stores a conversation, and why tools tend to vanish when you switch to Codex. It ends with the honest limits, including one that changed in June 2026.

Why run Claude Code, Codex and Gemini CLI in one app?#

Because they are not the same tool, and 2026 comparisons keep reaching a similar rough split:

• Claude Code for large, coherent multi-file changes.
• Codex for sandboxed, unattended work. Daniel Vaughan's May 2026 showdown describes its OS-level sandbox: Seatbelt profiles on macOS, Landlock and seccomp on Linux.
• Gemini CLI for very large context. Comparisons list a 1M-token window, including DeployHQ's.
• Grok (through a grok CLI) if you already pay xAI.

The other reason is plain arithmetic. You may already pay for Claude and ChatGPT, and each plan has its own usage window. When one runs out mid-afternoon, the other is sitting there. Benchmarks move every release, and the split above will too. The lasting question is how you move between them without starting over.

Pattern 1: a terminal multiplexer (cheap, and mostly nothing is shared)#

The simplest setup is tmux, or one of the agent-aware multiplexers built on the same idea. Each CLI runs in its own pane, and you watch them side by side.

As of September 2026, the ones people actually use:

• amux (mixpeek). A self-hosted control plane (MIT plus Commons Clause licence) for many parallel Claude Code, Codex and Gemini CLI workers, run from a web dashboard or its phone app. It has a shared kanban board, schedules, inter-worker messages and layered "memories" (instructions composed global, then group, then worker). It also says it can swap the model on a running worker and keep the context. A different project also called amux is a Rust clone of cmux that marks which pane needs your input.
• Beam. A terminal organizer for Mac, Windows and Linux with tabs, split panes and saved layouts. It keeps project memory as Markdown files that Claude Code, Codex and Gemini CLI load and update.
• wmux. A multiplexer that runs natively on Windows (no WSL) and registers MCP tools (browser control, terminal reading, agent-to-agent messages) for the agents in its panes.

These are good tools, and some share more than a plain tmux would. amux has layered memory, a board and model swaps on a worker, Beam has shared memory files, and wmux gives every pane the same MCP tools. But in most setups the conversation is still per CLI. Claude Code in pane one and Codex in pane two have separate transcripts. A shared memory file carries decisions that were written down, not what the other agent was told ten minutes ago or what its last tool call returned.

Pattern 2: one worktree per agent (built for parallel code)#

The second pattern isolates the work rather than the terminals. Parallel Code is the clearest example. For each task it creates a git branch and worktree, symlinks node_modules, starts the CLI you pick (Claude Code, Codex, Gemini, Copilot or Antigravity) in that folder, and gives you a diff to review and merge. It is free, MIT-licensed, and runs on macOS and Linux.

This is the right shape when you want five features built at once, or the same prompt run twice to compare approaches. Agents never overwrite each other's working copy.

It is the wrong shape for handing a task from one model to another. By design, each worktree is its own agent's world, with its own branch and its own conversation.

Pattern 3: one conversation, several engines#

The third pattern is one thread you keep working in, where the engine is a setting you can change. You plan with Claude Code, ask Codex to write the tests in a sandbox, then go back to Claude. That only works if three problems are solved.

Here is how the three patterns compare on what matters when you switch.

Where does each CLI store its conversations?#

This is the crux of memory. Every CLI saves its sessions as ordinary files, but each in its own place, keyed its own way, and none reads another's:

Three things follow from that table.

Resuming is per CLI. claude --resume cannot open a Codex rollout, and gemini --resume only lists chats from the project you are in. Switching engines means the new one has never seen the conversation.

The key is often a path. Move a project to another folder or another Mac, and the CLI no longer finds its history. Claude Code also prunes old sessions, which leads to the "No conversation found with session ID" error. That one has its own post.

Nobody owns the whole picture. If the conversation only exists in one CLI's folder, switching models means pasting a summary by hand, or keeping a memory file the way Beam does.

The fix is to keep a transcript that belongs to neither CLI. Then whichever engine has never seen the session is handed that transcript as its starting memory.

Why do tools disappear when you switch to Codex?#

MCP is supported by all four CLIs, so this sounds like it should be solved. The catch is where the tools live.

Each CLI reads MCP servers from its own config: ~/.claude.json or project settings for Claude Code, ~/.codex/config.toml for Codex, ~/.gemini/settings.json for Gemini. An app that wires its tools into one CLI's config does not automatically give them to the others. And many apps' most useful tools (a browser the agent drives, typed documents and sheets) run inside the app's own process, not as a command a CLI can spawn.

Codex can connect to a streamable HTTP MCP server by url, so the answer is a local HTTP bridge in front of those same in-process tools. Then there is one more trap. Codex refuses MCP calls with MCP tool call requires approval, but approval policy is never unless the server is set to default_tools_approval_mode = "approve". Without that, the tools look connected and every call fails. We wrote up that error and the fix in a separate guide.

The last piece is the instructions. If Claude is told how to save a spreadsheet and Codex is not, Codex will say it made one when it did not. The prompt has to be the same text on every engine. The only honest difference is when an engine really does not have a tool on that run.

What are the honest limits?#

Even with memory, tools and instructions handled, some differences are real and do not go away.

Gemini CLI's personal Google login is gone. On 18 June 2026, Google stopped serving Gemini CLI requests for the Code Assist for individuals, Google AI Pro and Google AI Ultra tiers. Gemini CLI still works with a Gemini API key, Vertex AI, or a Code Assist Standard or Enterprise license. Google now directs individuals to Antigravity CLI. If an older guide tells you to "sign in with Google", expect the browser step to succeed and the first request to fail.

Each engine has its own sandbox. Codex has read-only, workspace-write and danger-full-access. Claude Code works through permission prompts and modes. Gemini and Grok have their own approval settings. The same request can be allowed on one engine and refused on another, so check what "can write files" means on the engine you just switched to.

A handed-over transcript is memory, not experience. The new engine reads what was said and done, but it did not run those tool calls itself. Point it at the files it needs, rather than assuming it has the other model's working state.

Small models have small windows. Open models, whether local through Ollama or hosted, sometimes have context windows of a few thousand tokens. A long conversation cannot fit, so a switch to a small model sees less of the history than a switch to Claude or Gemini.

Subscriptions have rules. Using a Claude or ChatGPT plan inside another app is allowed in some ways and not others. Read what is allowed in September 2026 before you plan around it.

Where Universe fits, and when another tool is the better choice#

Universe is a Mac app built for pattern 3. It runs agents on your Mac through model accounts you already have:

• Claude Code on your Claude Pro or Max plan (or an Anthropic API key)
• Codex on your ChatGPT Plus, Pro or Business plan (or an API key)
• Gemini CLI, within Google's June 2026 sign-in change above
• Grok with your xAI key
• Open models through Mantis, free when they run on your own machine

Copies of Claude Code and Codex ship inside the app. Gemini CLI, Grok and Mantis are installed when you first need them.

What it does about the three problems:

• Memory. You can switch the model inside a conversation, and the new engine is given the conversation so far, so switching does not start from nothing. The record is files in ~/.universe, not in any one CLI's folder.
• Tools. Universe's own tools, including the browser and typed artifacts like sheets and decks, also work in Codex, through a local bridge.
• Instructions. Every engine gets the same instructions.
• Skills. A SKILL.md skill can be published into the folders all four CLIs read. There is a separate guide on sharing skills.

Universe charges for the workspace, not for model usage. There are no credits, and a free plan runs three sessions at once (pricing).

Pick something else when:

• You want many branches at once and to merge the winner. Parallel Code is built for exactly that, it is free, and it runs on Linux.
• You want a real terminal you type into. Beam, or amux on tmux, keep you in the CLI itself.
• You are on Windows or Linux. Universe is Mac only. Beam and wmux run on Windows, and amux and Parallel Code run on Linux.
• You want dozens of agents claiming tickets off a board, watched from your phone. That is amux's whole design.

Universe also has limits of its own. A turn you move to another Mac gets the model's own tools but not Universe's browser and typed artifacts. In a shared room, each Mac's agent keeps its own model memory, so the transcript is shared but the context is not one continuous conversation.

How to set it up in Universe#

1. Download Universe for Apple silicon or Intel (macOS 13 or later).
2. Sign in to the accounts you have: Claude for Claude Code, ChatGPT for Codex. Connect Gemini, add an xAI key, or set up a local model for the others.
3. Start a session and pick the model you want to begin with.
4. When the task changes shape, change the model in the same conversation. For example, plan with Claude, have Codex write and run the tests, then return to Claude to review. The new engine picks up from the conversation so far.
5. If one account hits its limit, add a second one. Universe runs your accounts in the order you set, and the transcript says when it moves to the next.

If you are still deciding what kind of tool you need, start with what an AI agent workspace is. It sets out the difference between a place to run agents and a place to do the work with them.