Late-night development: asking AI to "just fix one more thing and publish." If the screen works as expected, you want to move forward immediately. However, a screen that appears normal and backend safety are separate deliverables.
In the attached case collection, Claude Code is recorded as "Desktop app worktree mechanism wiped gitignored directories from MAIN working tree (data loss; only .gitignore literal-path entries deleted)." The impact classification is "source workspace destruction," and the evidence level is "public issue/firsthand report (unverified independently)." The source material can be confirmed at #75490.
The basis is a public issue posted to the product's official GitHub repository. However, the existence of an issue does not mean vendor acknowledgment of facts or confirmation of root cause. Since reproducibility, environment, and impact scope may be unconfirmed, this article treats it as "reported content."
What can be said with certainty from this entry is that, in publicly available information, an incident classified as "source workspace destruction" has been reported and documented. I will not fabricate execution environments, additional damage, vendor judgment, or post-report fix status that are not in the attached file. The more limited the information, the more trustworthy it becomes to leave unclear parts unclear.
Words like "restore," "organize," and "rebuild" have clear targets for humans, but commands need a scope. Git cannot distinguish whether uncommitted changes or untracked files were created by AI or existed beforehand. The save point before execution and diff confirmation determine safety.
- Before starting work, save existing diffs via commit, stash, or patch
- Display absolute paths and a list of items scheduled for deletion before execution
- For commands with dry-run, confirm the target first
- Do not auto-approve destructive Git operations involving untracked files
These are general verification methods derived from public cases. This does not mean all countermeasure gaps have been confirmed as the cause in this report. Verify whether the same conditions exist in your configuration and implement only what is necessary.
Terminal-level deletions and session loss like in this case are outside the scope of URL diagnostics. On the other hand, whether the service you restore and publish has other configuration defects remaining can be checked starting with Code Diagnostic Llama. URL only, about 1 minute, free, no GitHub integration or card registration required. Use it to layer verifications that protect different targets.
Before moving forward based only on "it works" or "processing finished" displays, verify the change scope, publication scope, and rollback method once. That brief pause becomes the process that lets you confidently continue using AI's speed.
Can you specifically explain the stop conditions and recovery points in your current environment to avoid producing the same result as "source file deletion reported in Issue #75490"?
#Git #DataLoss #AIAgent #PairCoding #CodeDiagnosticLlama
Automation of unauthorized access
