Critical bug: Codex ignores file timestamps and can corrupt files.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #5772

Powered by Codex Action

Thanks for the feedback. This is model behavior you're seeing. We'll share the feedback with the team members who are responsible for training our codex models. We're tracking this feedback and similar reports so we can make the model more robust in future iterations.

Thanks for using the /feedback command. That additional information is useful.

@etraut-openai

Thanks for the reply - let me try to clarify what I’m reporting, because I don’t think this is just model behavior in the narrow sense.

I fully understand that the underlying language model doesn’t call stat(2) or track file mtimes by itself. My concern is about the Codex stack as a whole (CLI + agent harness + model):

• The CLI / agent already mediates all file reads and writes for the model.
• The local filesystem has a clear source of truth (mtime / inode / hash) for whether a file has changed since it was last read.
• Today, Codex can still overwrite newer on-disk edits silently, because there is no concurrency / version check before applying the model’s patch.

Other agents (Gemini, Claude, etc.) solve this at the orchestration layer, not in the raw model: they attach version information (timestamp or hash) to each file read, and verify it right before a write. If the version changed, they either re-read and re-prompt the model with the new contents, or they fail fast with an explicit "file changed on disk, please retry" error instead of writing blindly.

So I’m not asking you to teach the model to implement stat(). I’m asking for the Codex agent to enforce a basic safety invariant: "never silently discard newer user edits on disk."

Concretely, something along these lines would already fix the class of bug I’m seeing:

1. When Codex reads a file for the model, record its version (mtime / hash / change counter).
2. Before applying a write/patch suggested by the model, compare the current version on disk with the last-seen version.
3. If they differ, either:

• automatically re-read the file and re-run the step with the updated contents, or
• abort the write and surface a clear conflict message to the user.

Whether you implement this purely in the CLI/app-server, or by passing "file X changed since last read" metadata into the model and letting the model decide to re-read, is an internal design choice. From a user’s point of view the key property is: Codex should not be able to corrupt or overwrite fresher on-disk edits without any warning.

Right now that safety property is not guaranteed, which is why I filed this as a critical bug.

Thanks, I understand your proposal. However, this is a model behavior. We've tried to do what you've proposed — implementing a mechanism in the harness to enforce that the model reads any changes from a file before it applies new patches. What we found is that the model dutifully reads the updates from the file and then chooses to overwrite the modified code anyway. In other words, this needs to be addressed at the model level.

@etraut-openai Thanks a lot for the explanation. I understand now why you are treating this as a model issue as well.

That said, I still think there is a simpler harness level safety mechanism that could protect users from file corruption even before the model is improved.

I am not asking the model to behave more intelligently or to merge changes. What I am asking for is a hard guardrail in the Codex stack: if the on disk file has changed since the version that the model’s patch was based on, the harness should refuse to apply the patch and return an error instead of writing anything.

In other words, Codex does not need to re read or reconcile edits. It should simply fail fast and with a clear error whenever a patch would overwrite a newer version of the file.

One way to do this could be:

When the file is read for the model, record its version (for example mtime or hash). Before applying a patch, compare the current version with the recorded one. If they differ, return a clear “file changed on disk, patch rejected” style error and do not write.

If the model ignores this and keeps proposing patches without re reading, it will just hit the same error again and control effectively returns to the user. The important property is that the user’s newer edits on disk are never silently lost.

This would already be a big improvement in safety. You could even expose it as an option like corruption_protection = true by default, but the key point is that Codex should not be able to overwrite fresher on disk edits without an explicit conflict.

This issue is still reproducible for me.

Repro case: Codex made changes to a file. After that, I opened the same file in my editor and made manual edits. Then I asked Codex to apply another change to that same file. Instead of re-reading the file and incorporating my manual edits, Codex behaved as if the file had not changed and overwrote the file based on its earlier snapshot — effectively wiping my edits.

Because of this, my manual changes were lost and I had to redo the work (about 30 minutes). This is pretty risky behavior: if the file was modified outside Codex after the last read, Codex should detect it (mtime/hash) and re-read before applying a patch, or at least stop and ask for confirmation / show a diff.

@etraut-openai

I instructed Codex to make changes to a file that I was simultaneously editing in another terminal window.
Each time, Codex detected the changes and reloaded the file. It then adjusted its output to incorporate my changes.

Does this mean the problem has been solved?
Could you confirm it?

OpenAI Codex (v0.91.0)
model: gpt-5.2-codex xhigh

Exmaple

Explored
  └ Read counting.md

• I noticed an extra line appeared unexpectedly, ... applying a patch for consistency.