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

[awronski]

What version of Codex is running?

codex-cli 0.50.0

What subscription do you have?

PRO

Which model were you using?

codex-high

What platform is your computer?

Darwin 25.0.0 arm64 arm

What issue are you seeing?

I’ve observed that Codex doesn’t check file timestamps.

If Codex is working on a file, and I modify that file in an external editor, Codex can later overwrite my changes. It does this because it doesn’t verify the file’s current state. For example, it doesn’t check the timestamp.

This issue does not occur with Gemini or Claude.

What steps can reproduce the bug?

Uploaded thread: 019a24f0-62c2-7802-971c-797d3e2d77e6

What is the expected behavior?

The expected behavior is to check the file’s timestamp before editing it, as Gemini and Claude do. If the timestamp has changed, Codex should re-read the file to avoid corrupting it.

Additional information

No response

[github-actions]

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

• Codex CLI is not rereading agents.md after auto /compact #5772

Powered by Codex Action

[etraut-openai]

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.

[awronski]

@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.

[etraut-openai]

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.

[awronski]

@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.