Five Days with Codex: A Different Harness Is Not Free

I started using Codex for a very practical reason: I had run out of Claude Code tokens while working on Shipwright.

That made it a good opportunity to test Codex properly. For five days, I used it intensively with GPT-5.6 Sol on High. I tried the desktop app first and later moved to the terminal. I expected friction because this was a different tool. I did not expect the gap to my established workflow to feel this large.

My honest first impression is that the experience has been more difficult and more surprising than I expected.

This is not a claim that Codex is a bad product, or that Claude Code is universally better. I normally work with Claude Code using Opus 4.8 and now Opus 5. I also use GitHub Copilot with Claude models inside a large Swiss insurance company. Those environments have shaped how I collaborate with an agent: I expect it to connect related work, challenge the structure of a task and propose a sensible path through ambiguity.

Codex has often felt more literal. I have spent too much time supplying the synthesis I expected the agent to contribute.

Five days are not enough for a definitive verdict. They are enough to see that moving between agent harnesses is not free, even for someone who works deeply with AI coding tools.

I did not start with a controlled comparison

The circumstances matter. This was not a laboratory test with identical prompts, tasks and token budgets. I moved to Codex because my Claude Code allowance was exhausted and I wanted to continue working on Shipwright.

After five days of intensive Codex use, I reached its weekly limit. After seven days with Claude Code and Opus 5, I was at roughly 90% of its weekly limit.

Those figures should not be read as a price-performance benchmark. The tasks, context sizes, tool calls and product limits are not directly comparable. They do, however, describe the practical experience that triggered this article: I invested a meaningful amount of usage in Codex and still did not reach the fluency I already have in Claude Code.

That may partly reflect my own learning curve. I am still learning how Codex expects complex work to be framed. But that is also the point. Capability does not arrive for free simply because the underlying model scores well. A different harness needs onboarding, configuration and a new mental model.

The security pause was about the diff, not the secret

One of my early tasks involved an external code review through OpenRouter. This example came from my personal work on Shipwright, not from my corporate environment. I provided the OpenRouter key intentionally. Codex did not ask whether it should transmit the secret. That would have been a sensible question if the key itself were about to leave the environment.

Instead, it stopped to ask whether it should send the code diff to OpenRouter.

That is an important distinction. A diff can contain proprietary source code, credentials accidentally committed to a file or business logic that should not leave a controlled environment. Codex separates local access from permission to transmit data across a network boundary, and its approval system is designed to detect possible data exfiltration.

The check was therefore technically defensible. In a regulated enterprise, I would rather have an agent pause than silently send source code to an external service.

In this case, however, the purpose of the task was the external code review. Sending the diff was not a side effect. It was the task. The additional confirmation felt less like protection and more like the harness failing to carry clear intent through the workflow.

This is not an argument against security controls or configuration. Codex offers approval policies, sandbox modes and network rules for good reasons. My issue is the onboarding experience around them. During installation of the desktop app, the initial sandbox question confused me more than it helped. I understood the individual words, but I did not yet understand the operational consequences for the work I was about to do.

The configuration is not the problem. The cost of learning what each setting means in practice is simply real.

Mechanical execution where I expected synthesis

The more important frustration was judgment.

I maintain a triage page for open development work. When I asked Codex to clean it up, it processed the items one after another. The result was orderly in the narrow sense, but it missed the larger opportunity. Several items belonged together. A stronger result would have combined them into coherent work packages and produced a cleaner delivery flow.

Codex completed the visible units without reconsidering the structure behind them.

The same pattern appeared when I asked how we could parallelise the work. This was not a request to spawn several agents. It was a request to examine the individual triage items, identify dependencies and overlaps, and combine them into clean work packages that could move forward independently. The proposed plan still handled the items largely in sequence.

Claude Code has trained me to expect more synthesis. Not on every turn and not without mistakes, but often enough that it feels closer to a collaborator than a list processor.

The missing step was structural rather than technical. I expected the agent to recognise that several small items described parts of the same outcome, consolidate them and turn the backlog into a more coherent delivery plan. Instead, it treated the current list structure as given.

Perhaps I needed to state that transformation more explicitly. That is part of learning a new harness too. But it is also a useful example of workflow fit: the level of inference I naturally expect from an agent is not necessarily the level its default behaviour provides.

The model is only one part of the product

This is where the research becomes useful.

A 2026 study called Harness-Bench evaluated 5'194 execution trajectories across 106 practical tasks. Its central finding was not that one base model won. Performance varied substantially across combinations of model and harness. Context management, permissions, tools, state and recovery all shaped the outcome.

That matches my experience more closely than a leaderboard.

GPT-5.6 Sol and Claude Opus 5 both perform strongly in published evaluations. The precise ranking changes with the benchmark, harness, reasoning setting and task category. Another 2026 study of 7'156 pull requests found that task type had a larger effect on acceptance than the typical difference between agents. No agent led every category.

The benchmark I care about is more personal:

• How many corrections do I need before the agent understands the actual goal?
• Does it improve the structure of the work or merely process the list?
• Does it recognise independent workstreams and execute them effectively?
• How often does a safety control interrupt an already clear intention?
• Can I trust the result after the tests pass, or must I reconstruct the reasoning myself?

These measures depend on the repository, the task and the user's working style. They are also what determines whether an agent saves time.

Why the terminal currently feels better

After struggling with the desktop app, I moved to the Codex CLI. My early impression is that the terminal works better for me.

This does not mean it contains a better model. OpenAI says the app, CLI, IDE extension and web surface use the same underlying Codex harness. They also share core configuration.

There is a real presentation difference, though. In the underlying App Server protocol, agent messages can be marked as intermediate commentary or as the final_answer. Plans, commands, diffs and reasoning are separate events. Both the app and terminal can consume this information, but they render the working process differently. The desktop app turns more of it into interface state; the terminal presents a tighter, more direct execution transcript.

So the desktop app does not appear to have an exclusive reasoning channel that the CLI lacks. What changes is how the interaction is surfaced and how I respond to it.

The CLI makes the current directory, commands, permissions and session state more explicit to me. It encourages a compact loop between instruction, execution and evidence. The desktop app adds project navigation, visual review, worktrees, browser tools and parallel task management. Those are meaningful capabilities, but they also introduced more state at the exact moment I was still learning the permission model.

Other users may experience the opposite. The right conclusion is not that the CLI is better. It is that the surface is part of the harness experience.

Not Claude Code versus Codex

Community discussions about Codex and Claude Code are almost perfectly contradictory. Some developers prefer Claude's coding taste. Others find Codex stronger at debugging, refactoring or end-to-end execution. The disagreement is credible because people are not evaluating a model in isolation. They are evaluating a model, a harness, a repository and a working style together.

That reframes my own result.

Perhaps I would get substantially better outcomes after creating a mature AGENTS.md, adjusting sandbox and approval settings, and learning how Codex expects complex work to be framed. I expect I would.

But this value does not appear automatically. It requires time and experimentation. That is worth saying because I am not new to AI coding. If an experienced user can still spend five intensive days feeling that the tool is working against his habits, then teams should budget for adoption rather than assuming an immediate productivity gain.

This is not a criticism of configurability. Mature tools should be configurable. It is a reminder that a new agent harness is closer to adopting a new development environment than switching a model in a dropdown.

The useful question is not, "Is Claude Code better than Codex?"

It is, "Which harness fits the way I work, and what would it cost to change?"

Shipwright already uses multiple models

Shipwright is not tied to a single model. The workflow already combines models where their roles are useful. I use GPT-5.6 Terra and Gemini for external planning and code review. I have also made Codex plugins available inside Claude Code for adversarial review.

So the problem is not that mixing models creates too much conceptual complexity. The combination already exists.

Porting Shipwright to Codex would be different. It would mean moving substantial parts of the operating workflow into another harness and then using that harness often enough to understand it properly. I would need to revalidate permission boundaries, planning behaviour, context files and CI interactions. More importantly, I would need to rebuild the intuition I currently have with Claude Code.

I do not currently have the time to make that transition a priority.

That will change over time. I want to integrate both Codex and Cursor into my workflow properly, in roles where they genuinely improve the result. Doing that responsibly means understanding each harness, configuring it deliberately and evaluating it on real work rather than forcing a quick migration.

Right now, most of my available time is flowing into Shipwright. So this is not a conclusion about which model is better, and it is not a Codex-versus-Claude-Code verdict. It is a practical decision about what currently fits the way I think and where I am most productive with AI.

→ Explore Shipwright

 

---

Sources:

• GPT-5.6: Frontier intelligence that scales with your ambition - OpenAI - 15 July 2026 - https://openai.com/index/gpt-5-6/
• GPT-5.6 benchmarks across Intelligence, Speed and Cost - Artificial Analysis - 9 July 2026 - https://artificialanalysis.ai/articles/gpt-5-6-has-landed/
• Introducing the Codex app - OpenAI - 2 February 2026, updated 4 March 2026 - https://openai.com/index/introducing-the-codex-app/
• Unlocking the Codex harness: how we built the App Server - OpenAI - 4 February 2026 - https://openai.com/index/unlocking-the-codex-harness/
• Codex App Server protocol - OpenAI documentation - accessed 4 August 2026 - https://learn.chatgpt.com/docs/app-server
• Agent approvals and security - OpenAI Learn - accessed 4 August 2026 - https://learn.chatgpt.com/docs/agent-approvals-security
• Best practices - OpenAI Learn - accessed 4 August 2026 - https://learn.chatgpt.com/guides/best-practices
• Introducing Claude Opus 5 - Anthropic - 24 July 2026 - https://www.anthropic.com/news/claude-opus-5
• Claude Opus 5 is now available in GitHub Copilot - GitHub - 24 July 2026 - https://github.blog/changelog/2026-07-24-claude-opus-5-is-now-available-in-github-copilot/
• Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows - arXiv - 27 May 2026 - https://arxiv.org/abs/2605.27922
• Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance - arXiv - 9 February 2026 - https://arxiv.org/abs/2602.08915
• Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa? - arXiv - 28 July 2026 - https://arxiv.org/abs/2607.21656
• Codex vs Claude Code: my current take after watching both mature - Reddit r/codex - 9 May 2026 - https://www.reddit.com/r/codex/comments/1t8n9rs/codex_vs_claude_code_my_current_take_after/
• Codex CLI vs App - Reddit r/codex - 13 April 2026 - https://www.reddit.com/r/codex/comments/1sk7xbu/codex_cli_vs_app/