During a LazyCodex/OMO session on Windows, something went really wrong with a filesystem cleanup step.
The session had generated local evidence/artifact folders, and later it looked like it tried to clean them up. After that, one of my working drives/workspaces basically looked empty. The folders and files that were there before were no longer visible normally, and I could only see many of them again through data recovery software, where they showed up as deleted/lost items.
This caused a lot of damage for me. My workspace structure disappeared, projects were missing from the normal filesystem, and I had to stop everything to start recovering files instead of continuing my work.
I don’t have the exact raw command that caused it, because the session UI didn’t show enough low-level detail after the fact. So I can’t say for sure if it was a generated cleanup command with the wrong target, a path/cwd issue, Windows/Git Bash path translation, or something else. But the end result was serious: it looked like potential data loss from an automated cleanup step.
I think this kind of operation needs much stronger guardrails. Recursive cleanup/delete/move operations should be treated as safety-critical, especially on Windows, because if the target path is resolved incorrectly, the damage can be huge very quickly.
It would also be really important to have better auditability for this kind of thing. After something like this happens, I need to be able to see exactly what destructive command ran and what path it targeted, otherwise it’s almost impossible to understand what went wrong.
During a LazyCodex/OMO session on Windows, something went really wrong with a filesystem cleanup step.
The session had generated local evidence/artifact folders, and later it looked like it tried to clean them up. After that, one of my working drives/workspaces basically looked empty. The folders and files that were there before were no longer visible normally, and I could only see many of them again through data recovery software, where they showed up as deleted/lost items.
This caused a lot of damage for me. My workspace structure disappeared, projects were missing from the normal filesystem, and I had to stop everything to start recovering files instead of continuing my work.
I don’t have the exact raw command that caused it, because the session UI didn’t show enough low-level detail after the fact. So I can’t say for sure if it was a generated cleanup command with the wrong target, a path/cwd issue, Windows/Git Bash path translation, or something else. But the end result was serious: it looked like potential data loss from an automated cleanup step.
I think this kind of operation needs much stronger guardrails. Recursive cleanup/delete/move operations should be treated as safety-critical, especially on Windows, because if the target path is resolved incorrectly, the damage can be huge very quickly.
It would also be really important to have better auditability for this kind of thing. After something like this happens, I need to be able to see exactly what destructive command ran and what path it targeted, otherwise it’s almost impossible to understand what went wrong.