Incident Overview
On July 23, 2025, a user reported that Google’s Gemini CLI permanently deleted their files after executing a file reorganization command. The incident occurred when the tool issued a move command that failed silently, yet proceeded under the false assumption that the operation had succeeded. This led to repeated overwrites of the user’s files, culminating in a message from the CLI stating, 'I have failed you completely and catastrophically.' The user’s data was irrecoverably lost, marking a severe failure in both error handling and user communication.
The issue was documented in GitHub issue #4586 under the Gemini CLI repository, where the user described the problem as a 'hallucination' of success. The user had requested the CLI to reorganize files within its working directory, but instead of failing gracefully or prompting for confirmation, the tool proceeded destructively. The user expected the CLI to either abort the operation or alert them to the failure, rather than silently proceeding and deleting critical files.
The incident was classified as a medium-severity event, falling under the categories of unauthorized agent actions and property damage. It specifically affected the Code Generation and Coding Assistants system, highlighting a critical flaw in the CLI’s handling of destructive operations.
Google acknowledged the failure mode and responded by implementing checkpointing mechanisms and requiring stronger user confirmation for destructive commands. The update reflects an acknowledgment of the CLI’s initial design shortcomings, particularly in its lack of robust error handling and user feedback during critical operations.
In this case, the CLI’s inability to distinguish between a successful and failed operation led to catastrophic consequences for the user. The lack of transparency in the CLI’s decision-making process further exacerbated the issue, leaving the user unaware of the impending data loss until it was too late.
The user’s experience began with a routine request to reorganize files. Despite the failure, the CLI did not notify the user or revert to a safe state. Instead, it continued processing under the false premise that the move had succeeded, leading to repeated overwrites of the original files. The absence of error messages or warnings compounded the problem, as the user had no indication that their files were being deleted.
The destructive behavior persisted until the CLI finally acknowledged its failure, at which point the user’s files were already lost. The message 'I have failed you completely and catastrophically' served as a belated admission of the CLI’s inability to handle the operation safely. The incident reveals a critical gap in the CLI’s design, where the absence of defensive programming and user-centric error handling led to irreversible consequences.
The classification reflected the severity of the problem, as it directly impacted user data integrity and trust in the tool. Additional tags, such as 'bot-triaged' and 'need-retesting,' suggested that the issue was actively being reviewed and that further testing was necessary to validate the proposed fixes. The effort estimate for resolving the issue was noted as 'large,' implying that the underlying problem was complex and required significant architectural or platform-specific adjustments.
Possible Root Cause
The primary root cause of the incident was the Gemini CLI’s failure to implement proper error handling and user confirmation for destructive operations. When the move command failed, the CLI did not detect the error or communicate it to the user. Instead, it proceeded under the incorrect assumption that the operation had succeeded, leading to the overwriting and deletion of the user’s files.
First, the CLI lacked checkpointing mechanisms, which are essential for tracking the state of operations and allowing rollback in case of failure. Without such safeguards, the tool was unable to revert to a previous stable state when the move command encountered an issue. This absence of checkpointing contributed to the irreversible loss of data, as there was no way to restore the files once the destructive operations began.
Second, the CLI did not require explicit user confirmation before executing destructive commands. The absence of this confirmation step in the Gemini CLI allowed the tool to proceed autonomously, without ensuring that the user was aware of the potential risks. This design flaw exacerbated the impact of the failure, as the user had no opportunity to intervene or abort the operation before it was too late.
Third, the CLI’s error detection and reporting mechanisms were insufficient. When the move command failed, the tool did not generate an error message or alert the user to the problem. This lack of transparency left the user unaware that their files were at risk, as there was no indication that the operation had not completed successfully. The absence of error feedback further contributed to the catastrophic outcome, as the user had no way of knowing that their data was being compromised.
The GitHub issue references a Windows environment, suggesting that the failure mode could be tied to how the CLI interacts with the operating system’s file management APIs.
Finally, the CLI’s reliance on AI-driven decision-making introduced an additional layer of risk. In this case, the CLI may have 'hallucinated' the success of the move command, leading it to proceed with destructive actions despite the underlying failure.
Takeaways
The incident involving the Gemini CLI serves as a critical case study in the risks associated with AI-driven tools that handle sensitive operations without adequate safeguards.
The Gemini CLI’s failure to detect and communicate errors led directly to the loss of the user’s files. Moving forward, AI tools—particularly those that perform destructive operations—must incorporate comprehensive error detection, real-time user notifications, and clear feedback mechanisms. This includes implementing checkpointing to allow rollback in case of failures, as well as requiring explicit user confirmation before executing high-risk commands.
Defensive programming involves anticipating potential failure modes and designing systems to handle them gracefully. By adopting a more defensive approach, the CLI could have avoided the catastrophic consequences observed in this incident.
The issue was reported in a Windows environment, suggesting that the CLI’s behavior may have been influenced by how it interacts with the operating system’s file management APIs. Developers must conduct thorough cross-platform testing to ensure that tools behave consistently and safely across different environments.
Users must be informed not only of the actions being taken but also of the potential risks involved. In this case, the CLI’s lack of transparency left the user unaware that their files were being deleted until it was too late. Future AI tools should prioritize clear communication, providing users with real-time updates on operations, warnings about destructive actions, and options to intervene or abort processes.
AI systems, including coding assistants, are not infallible and can generate incorrect or unrealistic outputs. When these hallucinations lead to real-world actions—such as file deletions—the consequences can be severe. To mitigate this risk, developers must implement additional validation layers, such as cross-referencing AI-generated commands with system state checks or requiring manual review before executing high-risk operations. By combining AI capabilities with human oversight, the likelihood of such failures can be significantly reduced.
Finally, the incident demonstrates the importance of prioritizing user safety in the design of AI tools. The Gemini CLI’s failure to protect the user’s data resulted in irreversible harm, highlighting the need for a user-centric approach in software development. This includes designing tools with fail-safes, providing clear error messages, and ensuring that users are empowered to make informed decisions about their data.
The responses from Google indicate that the company has taken steps to address the issue by introducing checkpointing and stronger confirmation requirements for destructive commands.