Undoing code changes is not possible on a per-file basis

Sometimes Codex will change multiple files, but the changes in one file will destroy everything, even though all the other changes were perfect. There is no “easy” way to cherry pick which files to “Undo”. This is predatory token grubbing practice, as lazy people are going to just ask the model to roll it back with natural language input, which will easily cost thousands of tokens for even the simplest changes.

This is a practical concern without magic solution, because there is no way to cleanly “undo” one file, and also undo just part of the AI model’s understanding of the internal thinking and reasoning it did, and the memory of the sequence of patches that it emitted and shell file reads it made where it assumes the current state of the files.

You change a workspace file to an unknown, you are going to have follow-up failures.

I would recommend communication
“I have gone into the workspace and reverted the changes you made to the specific file “my_library.py” because that was not a productive patch. However, I kept the improved file “my_helper.py” because I like the way that now works…”

In a UI, a developer tool could automate the messaging of a “reject”.

You can also just set up the workspace files the way you want to continue and start a new chat. Prompt with the corrections needed, inclusive of the clarification of the misunderstanding, that will this time around avoid the fault in AI assumption and output. Instant reduction in the count of “tokens”.

You don’t say how and where you are using “codex, the AI model” to understand where the workflow could be improved.

Thank you @_j for your helpful feedback on my issue. The use case popped up when I had asked Codex in the code extension ( code package from arch repos) to do some stuff that was vaguely related. It ended up changing two files which happened to be completely independent from each other aside from the fact that one of them was a javascript that needs to work to load the other file.

Well the changes borked the javascript, but I still wanted to test the changes to the other file. I had to choose: discard everything, spend tokens on communicating with LLM (even though I was done with the session and didn’t care about the LLM’s future context) or painstakingly editing one of the two files by hand.

Like most good engineers I’m lazy by nature and always want to find the easiest/best way to do things long-term. This time it means spending a bunch of time documenting the problem for my future self (carrying the can), but at the time I just told the LLM exactly what I wanted to do instead (I kicked the can, spending tokens for “nothing”) because I couldn’t gauge how accurate the changes I did want to test were. Not that the end result matters, but I ended up discarding all of the changes anyway… but I could have been discarding something useful, if I hadn’t checked first!


For reference, I attach a screenshot of a two-file edit in the extension and the right-click context, which could do with a “selectively undo only this patch” option.

Sure, if it’s dangerous hold my hand a bit and give me a warning… but don’t glue my hand to yours and prevent me from letting go. (Ironic that giving agency here actually means sacrificing a lot of individual abilities that you wouldn’t normally when delegating)

I also noticed that “Request changes” doesn’t seem to do anything, but since I didn’t test it thoroughly it is not a part of this “issue”.