I have been using Codex CLI on Windows for about a month, and I have noticed that Codex often has to repeat commands several times, especially when editing files.
For example, it will try one edit, hit an error, then retry the same edit two, three, or more times in sequence. It usually figures it out eventually, but I keep wondering why OpenAI’s top model, GPT-5.5 with medium reasoning, needs so many retries for what seems like basic file-editing work.
The other issue is that the sandbox never really seems to work properly. The agent often has to escalate to bypass the sandbox. These problems waste a lot of time and tokens on retries, which I would much rather see used for productive work.
I do have the latest version installed. Granted, I am on Windows, so maybe the sandbox issue is more prominent there than on Linux. But the struggle with simple C++ file editing still feels strange.
Can anyone give me a hand or point me in the right direction?
That’s the first primary issue I noted - that gpt-5.5 will just not be able to recite a matching context often, getting it wrong over and over. As if they didn’t recognize the need for constrained sampling when coding. It certainly doesn’t help when its view of code is random searches and random cats of ranges.
But then, Windows is indeed a concern to be addressed: that the models simply were not post-trained on well. Windows files end with a CR/LF, and an application where you are the developer instead of the consumer can deal with that, but when it is a Codex AI given a shell and being told “read your own files your own way, search in snippets”, that’s where you don’t have control to intercept the presentation of files, and you get an AI outputting non-matching linefeed-only context… that would be a style from its Macbook homebase.
Then: are you using WIndows Subsystem for Linux, integrating WSL into VSCode, etc. If not, then the AI also gets a surprise, gets to figure out it might be in Powershell of versions 2.0-7.0 with its ambigous knowledge of that environment - again needing to discover it can’t ls or grep from failures. That is an upgrade - but a separate OS to get files in and out of, and a breaker of your own hardware virtualization when Windows tries to be more than an OS.
So the key might be instructions: let AI know how to code, let it know the environment and expected tools to get your work done. Using Codex, that’s the only facility you have, prompting, or someone else’s model-unaware prompting in a bodge of a “skill” file, or prompting that is secrets kept from you.
I run about 2000 prompt tokens into an AI model to simply have improvement for use of OpenAI’s own API tool for coding patches (that is under-described to the model). A long process of refinement to where gpt-5.5 can write 300 line patches with a dozen parts out-of-order and have them all apply successfully - or the error return is that part 10 it wrote is what failed. A happenstance Windows command line can’t give that quality of feedback.
Yes, I agree that better prompting and clearer environment instructions can improve the results. But adding another 2,000 tokens of instructions to an already large prompt stack feels more like compensating for weaknesses in the tool than solving the underlying problem.
I could also patch Codex CLI’s prompts myself, but I am taking a different approach. I am building a small set of purpose-built tools that give the model a simple, deterministic interface for reading, searching, and editing files. That avoids wasting model time on shell syntax, platform quirks, line endings, and fragile text-based patching.
My point is not that Windows has no complications. It is that a coding agent developed by OpenAI, specifically for use with OpenAI’s own models, should provide a more reliable experience on Windows without requiring every user to redesign its prompting and toolchain.
I do not think that is an unreasonable expectation.