Using Codex More Than Claude: A Week of Agent Harness Lessons

For the past week I made a point of firing up OpenAI Codex instead of my usual Claude Code for most of my day-to-day coding. I did it deliberately, because for months I had been the person who picks one assistant and stays loyal — the same skill files, the same muscle memory, the same way of asking. A Ruby developer named Lucian Ghinda actually wrote up his own week of doing the exact same thing on All About Coding, and it lined up so closely with what I felt that I want to pull the practical lessons out of it. This is a field-notes guide, not a fanboy post. I went in expecting a model showdown and came out realizing the harness — how you point the agent at your repo, your skills, and your workflow — matters more than the model underneath. If you want to follow along with the official tooling, the OpenAI Codex documentation and the open-source Codex repository are the right starting points, and Anthropic keeps the Claude Code reference separate for good reason.

Why this deserves a week of your attention

If you only skim headlines, every coding assistant sounds interchangeable. Type a request, get a diff, merge, move on. The reality is that the difference between Claude Code and Codex shows up less in the first answer and a lot more in how the session runs: how eager the tool is, how much of your intent it guesses, how it handles git, and how it treats your long tail of personal skills. Those are harness behaviors, and you can actually steer them. Over this week I found roughly six concrete things worth borrowing.

1. Sync your skills folder across agents instead of rebuilding it

Ghinda’s first realization is the one I think the most people miss. He keeps Claude and Codex on an even footing with the same set of plugins and skills, but over time Claude got more skills because he created them out of past sessions and never ported them over. His fix is beautifully simple: point Codex at your Claude skills folder and ask it to translate them. You are not re-creating your toolbox by hand — you are handing one agent’s procedural memory to the other and letting it do the conversion.

This is exactly the workflow I wrote about in my guide to writing agent skills for AI coding agents. Skills are just files with instructions and references. Nothing stops you from keeping one canonical folder and letting each assistant adapt it. The moment you treat skills as repo assets you update once instead of as per-tool settings, switching agents stops being a fresh start every time.

2. Keep a second agent for the moments you are stuck

The most honest admission in his post is that when he was in a rush — debugging something that felt urgent — he still opened Claude. Not because it was better, but because it was familiar. There is real value in that, and it is not sentimental. When you are debugging, you want a tool you already know how to read; you do not want to simultaneously learn a new one and chase a bug.

So do not read this as “delete Claude, go all-in on Codex.” Read it as: pick a primary agent for steady feature work, and keep the familiar one in your back pocket for pressure moments. If you are juggling more than one backend anyway, an AI model router like LiteLLM lets you switch models per request without uprooting your whole setup. The strategic move is deciding which assistant owns which kind of moment, not swearing a loyalty oath.

3. Focused sessions beat one enormous session

Halfway through the week, Ghinda started opening many small, focused Codex sessions instead of the one long Claude session he used to keep. He admits this may not be specific to Codex — it just became obvious while he was using it. I think that is the real lesson and it applies to any agent: a long-lived session accumulates context, bleeds focus, and makes a tool more willing to drift into guesses about what you want.

Treat each session like a work item. Open it with a clear goal, do the work, close it, review the diff. Agents that hold a conversation that has grown into five unrelated objectives lose the plot — and the bigger agents get, the more their architecture has to manage that. My piece on Meta’s Muse Code, built for huge repos, covers how seriously real agent systems take session and context management.

4. The “above and beyond” tradeoff is real

Here is the sentence from his post that I keep coming back to: Claude feels like a colleague guessing what you want and doing it, while Codex feels like a companion that does what you tell it and stops at the first sign it might be done. That difference cuts both ways.

Claude’s eagerness is great when your prompt is loose and you want it to fill in the blanks. It is also how you end up with a pile of abstractions, type aliases, and Sorbet signatures you never asked for — which is exactly what Ghinda observed. I wrote before about a Claude Code session that reverse-engineered a dead HP printer, and that is the same trait in action: give it a target and it will barrel ahead. Codex, meanwhile, produced fewer comments and a more contained solution, which he liked. But it also sat back and waited when it genuinely was not sure, which meant he had to be explicit.

The takeaway: loosen your prompt for the eager tool, tighten it for the contained one. If you do not feed Codex the scope explicitly, you cannot complain that it does not guess. If you feed Claude tight scope, you get less of the extra abstraction detritus. The harness you build — the prompt file, the session structure, the expectations — does most of the steering.

5. Protect your git workflow before an agent touches it (I tested this)

The scariest anecdote in the whole post is the git one. Codex set up a branch that targeted another branch that targeted main, and when asked to rebase, it rebased against main — dragging in an unrelated stream of commits and opening a pull request with 4,000+ additions. The fix was to be explicit and tell it to rebase only with the target. This is a harness-safety problem, and it is worth defending against in advance, because a four-thousand-line false diff is exactly the kind of thing that wipes out a morning.

I rebuilt that branch-chaining scenario locally and tested three commands that catch it before you ever open a PR:

• git log --oneline --graph --all — view the topology and see that feature A actually sits on feature B, not on main. If you see a chain you did not intend, stop.
• git diff --stat origin/main...HEAD — the three-dot diff shows what a pull request from your branch to main would actually contain. A tiny stat here after you expected a small change is your first red flag.
• git log origin/main..HEAD — lists every commit that would land on main. If commit messages from an unrelated branch show up, the branch is carrying baggage.

Runs of those three commands take seconds and cost nothing; a merged 4,000-line PR costs an afternoon of untangling. Add them to whatever checklist you hand your agent before it touches git, and to your own habit before you approve a merge.

6. Give MCP auth a clean, explicit flow

One of the small-but-frustrating differences he flagged was how the two tools handle Model Context Protocol (MCP) servers. With Codex he liked that the CLI asked him to run codex mcp login and opened the right authentication and authorization flow every time. Claude sometimes tried to run the login automatically inside the turn and could get stuck.

This is a quality-of-life thing that quietly eats your day if it misbehaves. When an agent can just hand you a command to run and wait, you stay in control of the credential step. When it tries to do it invisibly, you get stalls and half-finished auth flows. Prefer the tooling that keeps auth explicit and interactive — it is the difference between a welcome stop and a mystery hang.

The workflow he is settling on

Ghinda also mentioned testing a cleaner flow across the week: code research → design change → review change → implement → verify. Notice there is no “start coding immediately” in there. The research and design phases come first, the review happens before the implementation, and verification is its own explicit step rather than an afterthought.

That sequencing is the harness in miniature, and it is the single biggest lever you can pull. Forcing an agent to research and propose before it writes code prevents most of the “wrong but confident” edits. Making verify a named step keeps it from declaring victory the instant the diff exists. Whether you run this flow inside Codex, Claude, or any other tool, the structure does the heavy lifting — the model largely follows the rails you lay down.

So which one should you use?

I am not going to hand you a verdict like “Codex wins” because the honest answer is that your harness decides more than the model. Ghinda’s own bottom line is that the difference is temperament more than capability. Give me an eager, above-and-beyond assistant and I write looser prompts; give me a contained, stop-when-unsure one and I write tighter scope. Both are usable; they are just not driven the same way.

The practical advice I would actually give: keep your skills in one place so you can move between agents freely, split your work into focused sessions, protect git with the three preview commands above, and run the research-verify cycle no matter which tool is in front of you. That combination — not the model name — is what made my week of Codex a learning experience instead of a migration headache. And when the next coding agent launches, none of that investment goes to waste, because it all lives in your harness, not in the vendor.