The question usually arrives sideways. You've used Claude Code for months, someone swears Codex caught a bug Claude walked right past, and now you want both. Not one instead of the other. Both, on the same codebase, at the same time.
So you open two terminals in the same folder, start `claude` in one and `codex` in the other, and within ten minutes they are editing the same file. One reformats what the other just wrote. A test passes, then fails, and neither agent knows why, because neither knows the other exists.
The tools aren't the problem. The shared folder is. Two agents in one checkout is two people typing into the same document with no idea anyone else is there.
The fix is to give each one its own checkout of the same repo. That's what a workspace in Frontier already is: a named container for one piece of work, and activating it checks out its own git worktree on its own `df-code/<workspace>` branch. Attach the same repository to two workspaces and you get two checkouts side by side. Nothing one agent does lands in the other's files until you decide to merge it.
Then you choose the instrument per workspace. Frontier has a global default connector, and any workspace can override it for itself from its Settings tab. Claude Code and Codex CLI are both verified end to end: live runs, tool calls, background Agents, terminal-session sync, and Frontier's own tools reachable from inside the conversation all work the same through either one.
Setting it up takes a few minutes. In Settings → Connectors, Quick Setup shows one card for Claude Code and one for Codex. Each is enabled once that CLI is installed on your machine. Tick both, pick which one should be the default, and apply. Frontier installs the session hooks and registers its own tools with each CLI for you, and skips anything already in place. Codex asks for one extra step the first time: open any `codex` session and run `/hooks` to approve the hooks, since Codex wants every new hook trusted once before it runs.
Now create two workspaces against the same repo. Call the first one `checkout-redesign` and leave it on the default. Call the second `checkout-redesign-review`, and in its Settings tab set the connector to Codex CLI. Two checkouts, two branches, two CLIs, one repository.
Three shapes tend to earn their keep.
Builder and reviewer. Claude builds in one workspace. When it believes the feature is done, the work is handed to the Codex workspace as a new thread with a self-contained summary, and the review comes back the same way: a message in the builder's own thread, not a verdict from nowhere. A second CLI reading the diff cold is a genuinely different pair of eyes. It wasn't there when the code was written, and it doesn't share the assumptions that wrote it. The Engineer / Reviewer tutorial walks through wiring this up once as a reusable Strategy. After you instantiate it, point the reviewer's workspace at Codex.
Same brief, two attempts. Give both workspaces the same task and let each have a go. Each workspace's History tab shows its full diff against where it branched, so comparing them is a matter of reading two diffs, not untangling one. Keep the better one, or the better half of each.
Split by the kind of work. You probably already have opinions about what each CLI is better at. Act on them. Give the refactor to one and the test suite to the other, each in its own workspace, and merge them one after another.
You don't have to give up the terminal to do any of this. Start `claude` inside one workspace's worktree and `codex` inside the other's, and each session syncs into its own workspace's thread through those hooks. It shows up in progress while it runs, and as unread when it stops. You keep typing where you like to type, and the app keeps the two conversations apart.
One thing worth knowing up front. The connector is set per workspace, not per thread or per Agent, so "Claude and Codex in one project" means two workspaces, not one. That's deliberate. It's the same line that keeps their files apart, and a workspace is cheap. Switching a workspace's connector later doesn't touch its history: past conversations stay as they were, and only new runs use the new one. Gemini and Aider are registered too, but they are scaffolded rather than verified, so treat them as a starting point.
Q: Can Claude Code and Codex work on the same repository at the same time in Frontier? A: Yes. Attach the repository to two workspaces and set one workspace's connector to Codex CLI. Each workspace gets its own git worktree on its own branch, so the two never edit the same files until you merge.
Q: How do I make one workspace use Codex while the rest use Claude Code? A: Leave the global default on Claude Code and set that one workspace's connector override in its Settings tab. Resolution is workspace override, then global default, then Claude.
Q: Do terminal sessions of both CLIs show up in Frontier? A: Yes. Claude Code and Codex CLI both support Frontier's session hooks, so a `claude` or `codex` session started inside a workspace's worktree syncs into that workspace's thread. Codex needs its hooks approved once with `/hooks`.
Q: Can a Codex agent review work that Claude Code built? A: Yes. Put the reviewer in its own workspace on the Codex connector and hand the finished work to it as a new thread. Its feedback goes back as a message in the builder's thread.
The fastest way to see this running is to start from a setup that already has a builder and a reviewer in it. Browse the example setups, each one installable in a click, or download Frontier and point two workspaces at your own repo tonight.