Codex vs Claude Code, from the files on your disk
Not a verdict on which writes better code. A description of how the two actually behave, written by the people who had to make one window drive both of them.
Why this comparison is different from the others
Most of what is written about Codex vs Claude Code is a benchmark on somebody's laptop, and it is stale within a month because both ship models faster than anyone can write about them. This page does not do that. Whether one writes better code than the other is a question about models on the day you ask it, and we are not going to pretend to settle it.
What we can tell you is what the two programs are made of, because vobuda had to read both of them to draw a control bar over either. Where each keeps its sessions, what it calls resuming one, whether it can be asked from outside what models it has, how it announces the mode it is in. Those are facts on your own disk, they change slowly, and they are what determines how each one fits into a day of work.
The short version: Claude Code is the more legible of the two from the outside. It writes its models into a file, keeps its sessions in a folder per project, and takes a flag to resume one. Codex keeps more of itself to itself. Its models cannot be asked for from outside, so the honest thing to do is open its own picker rather than ship a list that will be wrong.
Where each one keeps what
Everything in this table is on the machine in front of you, and you can go and look.
| Claude Code | Codex | |
|---|---|---|
| Past sessions | A folder per project under ~/.claude/projects | One index, ~/.codex/session_index.jsonl, naming every thread |
| Open an old one | --resume <id> | resume <id> |
| Pick up the last one | --continue | resume --last |
| Skills | ~/.claude/skills, plus the matching folder in the project | ~/.codex/skills, plus the matching folder in the project |
| Model list | Its own file, written as its server tells it, so a new model appears the day it ships | Cannot be asked from outside. Its own picker is the only honest answer |
| Setting the model | The model on its own | Model and reasoning level in one command, /model gpt-5.5 high |
| Its settings | settings.json | config.toml |
| What its status line says | Opus 5 with high effort, Claude Max | gpt-5.6-terra medium |
| How the process looks | claude | node, because Codex runs as node |
Read September 2026 against current installations of both. Their own documentation is the authority; this is what the two look like from a window that has to drive them.
Three traps we hit so you can recognise them
Every one of these was a defect in vobuda first, and each says something true about the two agents.
A Claude session's deepest process is often codex
Claude Code runs Codex as a helper of its own. So taking the deepest process in the tree to decide which agent a block belongs to made the dock say CODEX over a Claude session and made new restart the wrong program. The agent a block belongs to is the one the person started, not the one it started.
Codex is not node_repl
Codex runs as node, and a shell starts a program by forking itself and then replacing itself with that program, so the process list keeps calling it by the old name for the rest of its life unless the executable is asked for by name. A block running Codex used to be titled node_repl.
One agent's list over another agent's block
Two model lists and a continue flag were written when there was one agent and stayed global when there were three. Opening a Codex block offered Opus, Sonnet, Haiku and Fable, and continue sent codex --continue, which Codex answers with a usage error. Anything read from a program now belongs to that program and is asked for only over it.
The words in an agent's furniture change
Reading an agent's answer, or the request it was given, by looking for particular words in its interface fails at that agent's next release. Both are recognised by shape instead: an agent is known by the waiting prompt it puts before what you type, not by the box drawn around it, because the box is a fashion and the prompt is not.
The answer most people actually want is both
In practice nobody picks one and deletes the other. One is better at the thing you are doing this hour, the other has the session where you were doing something else, and both have usage limits that arrive at inconvenient times. What matters is whether running both at once costs you anything.
In vobuda it does not. Two blocks in one tab, or two tabs, each with its own bar reading its own agent, each with its own model, effort and permission mode showing. Both hand their signals to the window the same way, so a badge, a sound and a notice mean the same thing whichever one raised them, and the record of what happened while you were away lists them side by side, grouped by block.
Neither is connected by a settings section or a toggle, because a signal you have to configure before it works is not a feature, it is homework. They connect themselves on launch. Existing third-party hooks stay in place, and anything already occupying an event gets called right after ours.
Codex and Claude Code, asked plainly
Which is better, Codex or Claude Code?
On code quality, that is a question about which models each is running on the day you ask, and any answer written down goes stale. On how they behave as programs, Claude Code is the more legible from the outside: it writes its model list to a file, keeps sessions in a folder per project and takes a flag to resume one. Codex keeps more of itself internal.
Can I run Codex and Claude Code side by side?
Yes. Two blocks in the same window, each with its own control bar reading its own agent. Both announce when they finish or need permission, and both appear in the same record of what happened while you were away.
Why does vobuda not list Codex models?
Because Codex cannot be asked from outside what models it has. We shipped a list of two it does not run, which was wrong on the day it shipped. The model button now opens Codex's own picker, which is right by construction.
Does either of them need an account with vobuda?
No. vobuda has no accounts at all. Each agent uses whatever subscription or key you already gave it, and vobuda never sees either.
What about a local model instead?
A local model through Ollama is an entry in agents.json and needs no code. It gets a block and a bar with whatever that agent can honestly declare about itself.
One window, both agents
Free, no account, and each bar reads the agent underneath it.
curl -fsSL https://vobuda.com/install.sh | sh