Codex has recently started ignoring instructions and making unsafe patches

Hello,

In the last few days I have noticed a serious change in Codex behavior.

Until recently, Codex was working well on my project. It followed instructions, made small targeted patches, and the workflow was stable.

Recently, however, it has started behaving unpredictably:

  • It changes files I did not ask it to change.
  • It adds its own implementations instead of doing the requested task.
  • It touches tests or smoke-test wiring unnecessarily.
  • It reports PASS or PARTIAL without real live verification.
  • It causes regressions in unrelated parts of the UI.
  • It sometimes continues patching even when the requested task was only diagnostic.
  • It does not reliably respect instructions such as “do not touch anything else” or “wait for approval before patching”.

My project is a Windows desktop/web UI project using HTML/CSS/JS and Python. I ask Codex for small isolated patches, usually one issue at a time, but recently it behaves much more like an uncontrolled agent.

Has anyone else noticed degraded instruction-following or more aggressive/uncontrolled patching behavior in Codex recently?

Is there a recommended way to force Codex to:

  1. stop before patching,
  2. list the exact files it plans to change,
  3. wait for user approval,
  4. avoid touching unrelated files,
  5. avoid modifying tests just to make them pass?

Thank you.

Welcome to the community, @LEFTERIS1 .

GPT 5.3 and other models were removed from ChatGPT Codex, but they’re still available via the API. Have you tried changing your prompts to get them to work better with 5.5?

Remove write permission on your file system to tests that work.

I only joined these forums because in the last week or so I’ve been experiencing the exact same thing, I’ve seen others say it too.

For me the decline in codex’s output in the last week has been huge, I almost don’t understand how it isn’t being discussed more. It seems to want to do anything other than what you ask it to do.

Used it for months now daily, there is a huge difference in the last week in controlling it. It’s like it’s been programmed to burn tokens, do anything other thsn what you ask 10 times before finally getting it.

Never had that issue before.

Small update:

I switched to GPT-5.5 in Codex and, so far, its behavior is back to normal.

With the same project and the same workflow, GPT-5.5 follows instructions much better than GPT-5.4 did during the last few days.

I am now using Codex with a very strict workflow:

backup → one change → list files → approval → patch

This seems to work well again with GPT-5.5.

Of course I cannot know what exactly happened with GPT-5.4. It may have been a regression, a routing issue, or some change in model behavior.

However, from a user’s point of view, the experience is quite clear: GPT-5.4 suddenly became much harder to control, while GPT-5.5 works properly again. This inevitably creates the impression that users are being pushed, indirectly, toward the newer and more expensive model.

I am not stating this as a fact, only as an observation from real usage.

Στις Σάβ 6 Ιουν 2026 στις 1:16 π.μ., ο/η Paul <notifications@openai1.discoursemail.com> έγραψε:

Completely agree - we’ve observed night and day difference in the comprehension level. It misses intent now across most queries and implementations have quickly become very superficial.

I’ve now verified this across Codex app, VS Codex extension and across many disciplines such as engineering, science, finance, firmware and software dev, across clean and existing repos, with and without defined instructions and workflows and across Med to Extra High reasoning on gpt-5.5. The Extra High feels like a Low/Med did a few weeks ago - possibly worse.

I posted about it recently - whatever changes have taken place have truly diminished the capabilities of the product with the exception of speed. I would say the outputs are generating faster, which is what led me to think right away about the reasoning level.

Just posting for additional confirmation, but this is extremely infuriating and has been causing all sort of problems with our development and automation.

I could not agree more.

I have been working with it on porting over a benchmarking function and it completely disregards instructions even after multiple times of me mentioning the same thing. Codex 5.5 seems to do a lot worse with staying on track and following to-do files or checklists that it makes when claude seems to do very well.

A few examples I have literally told codex 5 times and it keeps floundering.

  1. I need you to update this benchmark to have the same knobs/feature parity of XYZ it does the architecture, no knobs

  2. I ask it to fill in the missing piece time is it add like 1-2 knobs and stubs the rest as “planned”

  3. I tell it that commiting “planned” features with stubs is unacceptable and it needs to fix the features to have parity, if flounders for a few more minutes before basically adding one more knob and making the readme more clear that the features are planned

  4. I tell it that updating the readme to say a feature is planned, all the planned features in the readme need to have parity in the work flow and saying “planned” in the readme is unacceptable - codex just deletes all the “planned” from the readme and doesn’t implement any features

  5. I make it 100% clear, citing what it has said and done and make it even more clear with a hand holding prompt what it needs to do and what it is doing wrong and it backtracks some of its work but still gets only 50% closer to feature parity

This is a major regression, this is basic instruction following that this is failing on. I am about to give up on 5.5 at this rate, this is totally unacceptable

Hi, personally I suspect some contradiction in instructions:

  1. How does your codex track what is “planned”?
  2. Does it have a clear definition of “planned feature”?
  3. Does it have a clear procedure description (or cli commands) to move a planned feature forward?

I’m some of my repos I have a work/ folder and a convention for planning files docs/work/plans/{the-feature-DDD}/plan.yaml

And a cli commands that allow codex to parse feature plan state with a single tool call:

npm run plans:status

Plus all the docs how to move features from planned to shipped.

i’ve been pointing this out for a month now

there has been ZERO changes or addressing of the issue

if you read various social media, you will see that this is a real issue

im thinking that before the IPO there is significant cuts to costs/capacity

I think it is just /goal .. it just doesn’t work well.. you should ignore it and split the work into managable chunks of max 3 small tasks and tell it to do one of them and then wait for your manual review. I think for most complex stuff the whole idea behind “let AI build the whole thing” is just a fairytale.

Instead you really have to use your own brain and devide the task as small as needed for you to understand the whole task fully.

The more you understand it the better you can explain it. Don’t expect the AI to do stuff that you couldn#t do without it. That does not work!

So the workflow to build stuff should be like this:

  1. Learn the topic in general!
  2. do some small experiments and make sure they do exactly what you need
  3. automate the small task by building a deterministic workflow .. so the next time you have to do the same task you can point your model to that code and tell it to run it

This speeds up your work over time. And this is how humans have evolved. Human brains are not very smart. The system, the cultural environment a human brain interacts with is.

The more tools you give your AI the faster you get good results not just demo and mock.