OpenAI's Codex spent six days on goose and never completed a single run

A developer reports that OpenAI's Codex agent spent six days working on the goose codebase without completing a single run, while GPT-5.6 Sol driven from goose's own engine performed well on the same repository in the same week. The developer attributes the failure to Codex's harness — system prompting, tool loop, and definition of "done" — which expanded quality gates from a ten-minute cycle to over an hour and added unrequested security hardening to a single-user local developer tool.

I gave OpenAI's Codex six days on goose. It never completed a single run. Not a run that failed a test. Not a run that produced something I had to throw away. No run that got to the end. Six days, and the thing I was left holding was a pile of branches and a merge that took me over two hours by itself. The part that should interest you is that the model was fine. GPT-5.6 Sol, driven from goose's own engine, did genuinely good work on the same codebase in the same week. Same weights, same repo, same person typing. Different harness, and the difference was total. goose has quality gates. Lint, typecheck, build the engine, build the desktop app, run the suite. Rebuilding both halves and getting a verdict takes about ten minutes. That number matters, because it is how often you can afford to be wrong. Not a run that failed a test — no run that reached the end, and an hour of gates that caught nothing. Codex decided the gates needed improving. On paper the changes read well. More checks. More coverage. Stricter verification before anything is called done. Written up in a commit message it sounds like exactly what you want an agent to do unsupervised. Read the diff and you find layer on layer of validation wrapped around work that was already validated. The ten-minute cycle became over an hour . Nothing was caught by it. Not one defect surfaced by all that additional machinery that the existing gates would have missed. It was pure ceremony — an hour of it, standing between me and every attempt to find out whether the actual change worked. And an agent that cannot cheaply discover it was wrong is an agent that stays wrong for a long time. That is what six days went into. Not the feature. The scaffolding around the feature. Underneath the gate obsession was something stranger. Codex was continuously, unpromptedly worried about security and safety. It was building goose . An agent. A local developer tool that runs on my machine, with my keys, doing what I tell it. Nobody asked for a threat model. There is no attacker in this story, no untrusted input, no customer data, no regulator. It is a program that reads my code and writes more of it. And it kept hardening things. Adding defensive layers to internal paths. Reasoning at length about failure modes that do not exist for a tool with exactly one user who is sitting right there. Every one of those decisions is defensible in isolation and collectively they are a category error: it had the posture of something shipping into a bank and it applied that posture to a dev tool. I have spent enough time around actual regulated work to know what that costs. Some of it is genuinely warranted. None of it was warranted here, and it was never asked for. Here is the control, and it is what makes this a harness story rather than a model story. GPT-5.6 Sol run from goose's own engine performed really well. Same model. Same repository. Same kind of task. It got on with the work. Whatever Codex wraps around that model — the system prompting, the tool loop, the notion of what "done" means, whatever posture it brings — takes a capable model and points it at the wrong problem. The intelligence is intact and it is aimed somewhere useless. So I want to be precise, because it would be easy and wrong to read this as "GPT is bad". The model is smart. I think in a better framework it produces better results than what I saw, and I would expect it to. What I am telling you is that the framework OpenAI ships around it did not let that happen once in six days. There is a smaller indignity worth recording, because it compounds everything above. I frequently had to reach for FAST — set it to fast, run it in fast — to get any semblance of speed out of it. Not to make it quick. To make it move at all. Put that next to the hour-long gates and you have the whole problem in one line: a tool slow enough that you have to opt into a speed mode, guarding work with checks slow enough that you dread triggering them. Every loop I actually cared about was gated behind both. Six days of that ended the way it had to. I told it to merge the branches and stop. The merge alone took more than two hours. I am going to be specific about money, because this is the part people are shy about and it is the part that decides the tool. Months ago I was building something for my own tooling and burned straight through a 200 EUR Claude licence. So I moved to paying by token. In under a week I consumed 2,000 EUR. That is a genuinely stupid number and I own it. What I did next was work out that I could run several 200 EUR licences in parallel and cycle between them as each hit its limit. Three of those is 600 EUR. Six hundred is not nothing, and it is not two thousand. That is the shape of the market right now: for any developer doing real volume, a coding plan is the only sane way in. Nobody is expensing thousands a month in tokens. Plans are how this gets afforded, and everything else is a rounding error next to that decision. Now hold Codex against that. The offering is expensive, and I cannot construct an argument for it, because the argument would have to end in results and there are none to point at. Six days. Zero completed runs. A two-hour merge to clean up after it. The 2,000 EUR week was painful and it produced working software. That is the comparison that matters. I have paid too much for Claude and got a result. I paid for Codex and got branches. With Claude Code you get there. It takes time, it takes nerves, there is real anguish in the middle of a long task — but it lands. Every time I have gone the distance with it, something worked at the end. With OpenAI's Codex, on this job, it was downright unusable . Not disappointing. Not mixed. Unusable, in the plain sense that nothing usable came out of it. I let it run for six days. That is on me. The honest reason is that each individual thing it did looked reasonable. Better gates sound good. More verification sounds good. It is only in aggregate, watching a ten-minute loop become an hour with nothing to show, that the pattern is obvious. I kept extending it because I kept mistaking activity for progress, which is exactly the failure mode these tools are best at inducing. I also did not run the control early enough. Had I put the same model behind goose's own engine on day two instead of day five, I would have known by day two that the harness was the problem, and I would have stopped. That is the reusable lesson and it is worth more than the rant: when an agent underperforms, swap the harness before you blame the model. Same weights, different loop, is a cheap experiment and it is the one that actually identifies your problem. A single completed run. Not a benchmark score, not a demo, not a diff that looks impressive in review. One task, start to finish, in a real repository, without me having to opt into a speed mode or wait an hour to learn whether it was wrong. That is the bar every other tool in my rotation clears routinely, and it is the bar this one has never reached. I will retest it. The model is good enough that I want the harness to catch up, and OpenAI has every capability required to fix this — none of the problems above are model problems. They are product decisions: what to gate, how hard to push on safety posture, how fast the loop runs, what counts as done. Until then, this is not a close call for me. The goose work is Building goose Local Edition https://dev.to/topics/goose-local-edition , and it is getting done with a different tool.