The appeal of AI agents is that they execute what you explain on the spot. However, the broader the execution permissions, the more interpretation gaps become real changes. Convenience and impact scope grow with the same switch.
In the attached case collection, Claude Code is recorded as "Windows: stale-worktree cleanup rm -rf traverses NTFS junctions and deletes data OUTSIDE the worktree (~800 GB data loss)". The impact classification is "Source workspace destruction," and the evidence level is "Public Issue/Stakeholder report (unverified independently)". The evidence material can be confirmed at #75275.
The evidence 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 on public information, an incident classified as "source workspace destruction" has been reported and organized. I will not create execution environments not in the attached file, additional damage, vendor judgment, or correction status after reporting. The more limited the information, the more trustworthy it becomes to leave unclear parts unclear.
When AI agents have shell access, targets for operation can extend outside the work folder. When path misunderstandings, links or junctions, and broad OS permissions overlap, impacts spread beyond the requested project. Not just careful instructions, but permission boundaries are necessary.
- Limit the write scope of the AI OS user
- Confirm the connection destinations of symbolic links and junctions
- Make deletions and moves outside the work root subject to approval
- Create generational backups of important folders on separate media
These are general confirmation methods derived from published cases. This report does not mean all countermeasure deficiencies were confirmed as the cause. Confirm whether the same conditions exist in your configuration and implement only what is necessary.
What can be confirmed with Code diagnostic Llama is the risk seen from outside a publicly available web service. It is not certain that Claude Code can directly prevent internal data loss reported. Still, before republishing, you can use a free simple diagnosis of about 1 minute with just a URL as a process to confirm other oversights. Internal environments must be protected with dedicated backups, permissions, and logs.
Before moving forward based only on displays like "it worked" or "processing finished," confirm the change scope, publication scope, and how to revert once. That brief pause becomes the process for confidently continuing to use AI's speed.
Can you specifically explain the stop conditions and recovery points in your current environment to avoid producing the same result as Issue #75275, which reported data loss outside the work scope?
#DataLoss #PermissionManagement #AIAgent #Backup #CodeDiagnosticLlama
Critical file corruption
