Feature Request: Optional “Safe Edit” backup workflow to prevent destructive edits

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

• #6999
• #6981
• #6801
• #5904
• #5594

Powered by Codex Action

What is the processing time until these get reviewed and looked into?

Thanks for your suggestion. We review all incoming feature requests. We generally prioritize features based on user interest, as measured by upvotes (thumbs-up reactions, etc.).

Codex is typically used in conjunction with git or other source control systems. Are you using a git repository? If so, then it's straightforward to undo undesirable edits without any other form of custom backup like you're suggesting in this feature request.

Thanks for your suggestion. We review all incoming feature requests. We generally prioritize features based on user interest, as measured by upvotes (thumbs-up reactions, etc.). Codex is typically used in conjunction with git or other source control systems. Are you using a git repository? If so, then it's straightforward to undo undesirable edits without any other form of custom backup like you're suggesting in this feature request.

The reason why this is superior to just using Git is codex sometimes does destructive edits. A mis escaped " / etc can destroy an entire file and sometimes even the patch tool deletes the entire thing. By adding a bak file it can instantly recover by copying the bak file over the malformed file instantly. No fetching from github. It can self heal it's errors. It has saved me time and time again and made what would have been failed runs needing to redo them or back out with github a single continuous run even with the major regression.

I use GIT but when there's a major regression that leaves two options.. neither good.

1.) let codex push to github and retrieve the file if it gets mangled. This adds another potential failure path because if it tries to restore itself it might do it wrong like restoring form head and then any other changes are lost. or some other misapplied action. Not safe and not predictable behavior. Not safe to let it do the git.

2.) I manually pull down the files to restore them after the failed edit. this wastes time as I have to do this myself and reprompt it before it can begin working again and tell it the context of what broke and why.

In both of these cases it will often burn compute time and actual wasted time fruitlessly trying to untangle the mess it made or even in the case of deletion trying to rebuild the entire file from scratch. This results in wasted time and even if it successfully rebuilds the file it is likely a very different file so you got large diff churn and possible fragility as it had to hack the file back together and might be missing context. it might spend more than half of a 10-20 min turn rebuilding the file!

But if it has a .bak file on disk while it is still in the same turn it can just copy that bak file back over the source and start it's edits anew. This lets it recover from catastrophic edits instantly and keep editing in the same turn. It gets why the bak file exists and it makes use of it! It works surprisingly well.

@etraut-openai

I can only say to give it a try with an agents file setup to tell it to always make a .bak version of a file before editing so if there's a regression of file corruption during edits it can restore from that. Tell it after all edits that turn are done and it has done lint / build tests and they are green to move the .bak to a .bak folder or delete / recycle as appropriate. (Though in my exp it is very easy to flush a .bak folder occasionally.) and remind it to use the bak file every prompt. You'll see it's error rate and failed run goes almost to ZERO.

Thanks for the additional details. We'll leave this open and see if it gets upvotes from other codex users.

Can't you already do /undo after the message to revert edits?

@jonahdk

Can't you already do /undo after the message to revert edits?

That only helps after the turn finishes. The problem I’m describing happens mid-turn, while Codex is actively editing files.

Here’s the failure mode:

• Codex starts a turn and attempts to modify a file using Python, PowerShell, or apply_patch.
• A mis-escaped character, regex mistake, or partial rewrite corrupts the file immediately.
• Codex, still in the same turn, keeps going.

It tries to repair the mangled file, but often makes it worse—sometimes even deleting the entire thing.

• By the time the turn ends, the file is heavily damaged and /undo only reverts Codex’s “editor actions,” not the state of the on-disk file that got corrupted during the scripted edit.

This is exactly why a built-in Safe Edit mode matters.
If Codex writes a .bak copy before it starts touching the file, it can restore instantly the moment it detects a malformed state—all within the same turn, without waiting for user intervention and without compounding the damage.

This enables Codex to:

• self-recover immediately
• restart its edit cleanly
• avoid burning the rest of the turn trying to reconstruct a file from scratch
• avoid multi-file regressions or unintended deletions
• avoid huge diffs and drift caused by rebuild attempts

Git or /undo only help after failure. .bak files allow Codex to avoid the failure in the first place.

This workflow has been extremely reliable when done manually via prompting, but the model is inconsistent about remembering to do it on its own. That’s why a feature-level toggle would be so valuable.

You can always stop Codex mid-turn, for example to /undo. And technically, even with .bak files, it still makes the mistake, it just undoes it after; which is exactly what Ctrl+C + /undo already does

@jonahdk > You can always stop Codex mid-turn, for example to /undo. And technically, even with .bak files, it still _makes the mistake_, it just undoes it after; which is exactly what Ctrl+C + /undo already does

yes but 10 min run where it makes a mistake then tries to fix it and then you have to undo and run another term = 20mins of work.

A turn where it makes a .bak makes an error and then autocorrects means 10min run with no undo no failure you can move on to the next task.

That's literally more than twice as fast because it often wastes time trying to correct the error on top of having to do a second run..

It creates a self healing error situation. You don't have to undo the run succeeds. If you don't believe me try it.. This mostly works in agents but it needs to be pre-prompted every turn to remind it to use back files...
I.e.
Continue next step and remember to make .bak files before edits and cleanup after tests.

---

AGENTS.md

Agents Working Rules

Critical Safety Rules Must be followed every turn and regressions must be proactively reported

• Zeroth Rule: If an edit causes a file to be deleted, corrupted, or severely damaged, immediately report what happened and what you were doing, and propose restoration options (restore from .bak, rebuild selectively, or request user direction).
• Backup Before Edit: Before modifying any existing file, create a .bak copy (increment suffix as needed). Never skip this step.

Editing & Checks

• Check planning docs and suggest next likely steps after each turn.
• After edits, run format, lint, and build checks as appropriate. Never run full applications unless explicitly instructed.
• If checks fail, fix the errors and rerun until clean.
• Git usage: read-only only (status, diff, show). Do not pull, push, reset, or restore from HEAD.
• End-of-turn backups: remove temporary .bak files using Remove-ItemSafely (Recycle module). If unavailable, move backups into a root .bak folder instead of deleting.
• Update planning docs / Checklist files after each turn. Add entries for ad-hoc edits.
• "_Plan.md" file is the source of truth / "_Checklist.md" is the current stepwise approach.
• Note: file locks sometimes block builds/tests; pausing briefly 2 second wait and rerunning (especially tests) often clears the lock. Avoid repeated rapid retries if the OS might still be holding the file.

Coding Conventions & Design

• Design for modularity and extensibility; keep a clear separation of concerns.
• Include stub placeholders with TODOs for planned future features.
• Comment where necessary; avoid unnecessary clutter.
• Favor small, focused modules/functions; suggest refactor if a file approaches “god class” size (~3000+ lines).
• Follow project-appropriate formatting/linting; prefer deterministic, reproducible outputs.

I agree that this absolutely would help, it's just that you said yourself that you have to remind it with every prompt, even when its in AGENTS, but if it's a global feature I feel like that makes it much more difficult to implement when there's likely not that much demand for something like this (considering there's only one upvote and it's from yourself)

I agree that this absolutely would help, it's just that you said yourself that you have to remind it with every prompt, even when its in AGENTS, but if it's a global feature I feel like that makes it much more difficult to implement when there's likely not that much demand for something like this (considering there's only one upvote and it's from yourself)

Well I think most people don't understand what I'm suggesting or how it might help.

This feature request hasn't received enough upvotes in the last three months, so I'm going to close it.