Clicking "Undo" on file changes should absolutely not be staging changes into git #5082
Description
What version of the VS Code extension are you using?
0.4.19
Which IDE are you using?
VSCode
What platform is your computer?
macOS 15.5
What steps can reproduce the bug?
Write a prompt, have Codex make changes to one or more files. Click "Undo".
What is the expected behavior?
The changes are reverted. If no unstaged changes in git, the revert is shown there.
What do you see instead?
The reverted file gets instantly staged in git (?????????????????????????!!!!!!?)
Additional information
Clicking "Undo" for file changes will not just undo the code changes, it will then also stage that change into git.
This is a serious violation, you don't know what changes I have staged already, what I'm experimenting with that will show up in unstaged changes that I can then safely discard etc.
The VSCode extension stages the whole file after undoing the changes, which is highly problematic if there are changes in these files currently staged.
It should not stage the file, especially not in such a hidden way. Any git stuff beyond reading should be strictly approval-only
Working on a file:
- making progress, staging changes as they're made if they work
- codex makes some changes, some stuff works, some doesn't
- I prompt more, get another set of changes which now seriously break stuff.
- want to revert the second set of changes, click undo, but the first set of changes that i wasn't happy with is now staged, mixed with my progress.
Undo should undo the lines, but not stage the file. Making it unstaged in git is my way to verify that things have been reverted properly.
If you want a proper checkpoint system, take a look at Augment Code. After Codex finishes making changes to one or more files, make a codebase snapshot (or a diff). Instead of Undo, have a Revert button. Clicking on that button should revert the whole codebase to that point, BUT DEFINITELY NOT STAGE ANYTHING.
No matter how long ago the conversation was (if undeleted), if we come back to it and click Revert, the codebase is changed to that state. We can then see the relative changes in git's unstaged changes (including the removal of all the files that were added after that snapshot etc.). Deleting the conversation should delete this snapshots, if storage is a potential issue, that way the upkeep is on us.
This way you can quickly zip through different attempts and see what was working without making a mess in your git repo, cherry pick different things into git's staged changes and discard the stuff that's not working.