Running UNDO command deletes a file that was just read #46783

Activity

1. github-actions

   assigned

   jlongster

   on Sep 2, 2026
2. mahirhir commented on Sep 2, 2026

   

   mahirhir

   on Sep 2, 2026

   More actions

   Reproducible for a structural reason, I think. Reading the revert path on main today:

   packages/core/src/session/revert.ts, in plan(), builds the restore map by taking every path a message recorded and pointing it at that message's start tree:

   for (const file of message.snapshot.files ?? [])
     if (!files.has(file)) files.set(file, Snapshot.ID.make(message.snapshot.start))

   stage() then hands that map straight to snapshot.restore({ files: restore }). And restore's documented contract in packages/core/src/snapshot.ts is:

   Restore selected project-relative paths from their associated trees. A path absent from its selected tree is removed; paths outside the map are untouched.

   So the deletion isn't an edge case in the diff logic, it's the specified behaviour: a path in the map that does not exist in its tree gets removed. In this report the path was recorded by the message, the file did not exist at that message's start, and so restoring it means deleting it.

   The part I could not confirm from reading alone is the first link in that chain: whether a failed read is what puts the path into message.snapshot.files. That would explain the reproduction exactly, but someone who knows the tool-result recording path should check it rather than take my word for it.

   Worth noting the blast radius is wider than the title suggests, if the above is right. The rule "reset these paths to their pre-message state" deletes anything now living at a recorded path that wasn't there at start — regardless of who put it there. The reporter created the file by hand between the failed read and the /undo, and it was still removed. Any file a human creates at a path the agent previously touched is exposed to the same thing.

   The distinction that seems to be missing is between this path was mentioned and this path was written by the turn being undone. Only the second is something an undo has any business deleting. A guard along the lines of "only remove a path if the turn actually created it" (rather than "if it is absent from the start tree") would close the reported case without changing legitimate undos, since a path the turn genuinely created is absent from start and was written by that turn, while this one is only the former.
3. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
4. thdxr

   closed this as not plannedon Oct 11, 2026
5. AtomicFS commented on Oct 12, 2026

   

   AtomicFS

   on Oct 12, 2026

   Author

   More actions

   I have done a quick test on version v2.0.26 and it seems to have been fixed.