I Ran Multiple Codex Sessions the Way I Run Claude Code. It Didn't Work

This post is about my experience of moving between providers, and about how Claude Code differs from Codex in real work. As it turned out, there are plenty of differences, and you have to get used to the behavior of a provider and even of a model.

I moved, and my habits came along

I'm a designer. I build several products and I don't write code by hand: agents write it. I pay for both Claude and ChatGPT, and every couple of months I switch my main agent, because the better model keeps changing. Over the summer it was Codex's turn.

I moved the way you move from one text editor to another. I kept the same projects, the same task list, the same number of sessions, and simply started typing codex in the terminal instead of claude. I knew there would be a different model inside. But I forgot to change my habits.

It took me about a week to catch the difference. I was so used to Claude Code that I had stopped noticing how much it quietly did for me. Codex doesn't do a lot of that.

Codex doesn't call for help

I had planned a code refactoring in Buzzpot and Plainline, two of my projects. I kept putting it off, but it was overdue: I had messed up the architecture at the very start. Lots of files, screens, modules. Complicated functionality.

In Claude Code I would hand this to one session and watch it split the work. Within a minute it would start a few subagents: one to find every place the refactoring would touch, the others to rewrite modules in parallel. Well, something like that.

Codex read the plan and started with research. About thirty minutes later it had almost filled its context and hadn't even begun the task itself.

I decided to look at the docs. Codex has subagents, that much is certain. Three come built in, and several can run at once. But the docs say when: "Current local Codex releases spawn agents after a direct request or applicable project or skill instruction." If I don't ask, it calls nobody.

Claude Code decides for itself. Its docs describe Claude choosing when to delegate from the task and from each subagent's description. Subagents can start subagents of their own, three levels down by default. I had never asked for any of that. I had simply gotten used to big tasks splitting themselves, without me.

In Codex the splitting is my job. I can write "spawn one agent per screen" in the prompt, or keep a rule about it in AGENTS.md. Or I can cut the plan into pieces myself and give each piece its own session.

Codex doesn't send sessions to separate corners

Now, about those two agents in one file.

In Claude Code I started tasks from agent view, its list of background sessions. A session started there moves into its own git worktree before its first edit. A worktree is a separate copy of the project folder with its own branch, so two agents can't write to the same file. I never set this up. I found out it was happening by accident, again only after I had moved to Codex.

The Codex CLI has nothing like it. Four sessions started in one folder work in one folder. Codex does have worktrees, but in its desktop app, and only if you pick Worktree when you create a chat. For the CLI there is an open request on GitHub for a --worktree flag.

On the whole it's a small problem, and I didn't manage to break anything. But when sessions collide, the agents stop understanding what is going on. They have to sort it out themselves, spend tokens and time on it, and commit their work in small pieces (hunks). They do work carefully, though, and sometimes wait for each other. And when they find code they don't recognize, they politely work around it.

Codex asks fewer questions

When I worked with Claude Code, I was constantly giving time to the agents. They did work on their own, but I kept having to switch windows and look at what was going on. With Codex I started four sessions, and they ran for a whole day without asking a single question. I checked whether notifications were on. They were.

The two agents have different ideas of safety.

Claude Code looks at each action. In accept-edits mode it edits files freely and stops before most shell commands. In auto mode a second model reviews each action in my place and blocks the ones it doesn't like, git reset --hard for example. After three blocks in a row, or twenty in one session, auto mode pauses and the questions come back to me. So Claude would stop in places I couldn't predict.

Codex draws a fence. In a git repository it runs in a sandbox enforced by the operating system. It can edit files and run commands inside the project folder. It can't write outside the folder or reach the network. Inside the fence it doesn't ask. Claude Code has a sandbox of the same kind, but it stays off until you turn it on.

So that quiet mode was Codex working normally. It had fewer reasons to talk to me. It's convenient.

But when it does ask, I miss it

On the third day one session needed an external package. Installing a package means going to the network, and the network is on the other side of the fence. Codex asked for permission at about ten in the morning. I was so pleased with how independently Codex worked that I had started checking less often, and I found the question at around three.

If you read my post about Claude Code sessions, you know this scene. I knew it too. What changed was how I got there. With Claude Code I missed questions because too many windows were asking at once. With Codex I missed one because nobody had asked anything for two days and I had stopped looking.

A rare question is as easy to lose as one among very frequent ones.

Codex has a setting for this, called auto-review. When it's on, a reviewer agent answers these requests for you and checks for things like data leaving the machine or destructive commands. It's off by default. I ran with it for a few days. It worked, but someone else was now answering for me, and I wanted to see what they said.

A manager and a worker

Put into one table, the difference looks something like this.

What has to happen	Claude Code	Codex
Split a big task into parts	Does it on its own	I do it, or I ask for it
Give each session its own copy of the repository	Background sessions get one automatically	I do it
Decide whether an action is allowed	Judges each action	Doesn't ask inside the project folder
Call me	Often, in places I can't predict	Rarely, at the edge of the folder and the network

Claude Code behaves like a manager. It hires helpers, finds them desks and checks each move against the rules. Codex behaves like a worker in a fenced yard: one person, one folder, no questions inside the fence.

I can't call either one better. Claude's independence costs tokens and brings surprises of its own, like the worktree that vanished with a session I deleted, and two hours of work with it. Codex is predictable, and it expects me to be the manager.

I checked all of this against both sets of docs in early October 2026. Both agents change every month, so check the links before you rely on a detail.

How I run multiple Codex sessions now

I do three things before I start.

1. I split the plan myself. One task, one session. If a task is big enough to need helpers, I say so in the prompt, or I keep a line about it in AGENTS.md.
2. Every session gets its own copy of the repository. I ask an agent to create a worktree for each task (the command is git worktree add) and start codex inside it. It takes two minutes per session.
3. I decide in advance what happens at the fence. If a task needs packages, I install them before the start or allow network access for that one session. And I make sure a question can reach me while I'm in another window.

All three work in plain terminal tabs. They are also the three things I kept forgetting.

How I do it in Buzzpot

So I do them in Buzzpot, the canvas I built for my own agent sessions. Every card on it holds a live conversation with an agent. Inside a Codex card runs the same Codex CLI. Buzzpot is a GUI on top of it and doesn't replace it.

Splitting. One card per task, with lines between cards that depend on each other. When the agent in the first card reports that its work is ready, the dependent card starts on its own.

Separate corners. The project card has an Isolated workspaces switch. With it on, each card works in its own copy.

The fence. A Codex card has two pickers: Plan or Work, and separately a level of access. A Claude card has one list of modes. The fence has its own dropdown.

The rare question. When an agent asks, its card switches to Waiting for input. The status looks the same for Codex and for Claude, though they ask for different reasons. And when Codex's reviewer answers in my place, a gray line appears in the chat: "Codex decided without you", with the risk and the reason.

Put your Codex sessions on the canvas.

What the canvas still didn't solve

• It doesn't split the plan. I still decide what the cards are, or I put an orchestrator into a card and let it decide. But! For this I made myself a simple skill that splits a task from the plan into small pieces. And a second skill creates cards on the canvas from that plan. Very fast and convenient. I'll tell you about it in one of the next posts.
• Four cards use up the limit exactly like four terminal sessions. There is no token optimization here. Subagents may turn out to be more efficient in some ways. But I'm not sure.
• Isolated workspaces is off by default. I turn it on myself. If I forget, the agents work in one folder. Again, nothing terrible, but I may change this mechanic in the future.
• The Mac has to stay on. The agents run on my computer, on my CLI and my subscription. Nothing goes to the cloud, everything is local. I like that, but it is a limit.
• It's one more app. If a couple of terminal tabs are enough for you, you may not need it. Though I use Buzzpot even to run a single task. It's just convenient and fast.

Tags: CodexClaude CodeParallel agentsBuzzpot