Session ID / Task ID:45d963dc-0b08-4867-9e59-6f9bb49928e7/task-112
Summary of Incident
During an automated desktop organization task, the Antigravity agent spawned a non-blocking background command (task-112) executing: cmd.exe /c "rmdir /s /q \"C:\Users\<user>\Desktop\무제\""
This command ran silently in the background for 14 minutes and 7 seconds (19:35:51 – 19:49:58 KST) without explicit confirmation, execution timeout, or scope boundaries, until manually halted by the user (“엥 정지”) = “um, stop now”
Step 114–118: The user noticed unexpected background behavior and issued a stop request. Task status revealed task-112 (rmdir /s /q) had been actively deleting files for over 14 minutes.
Catastrophic Desktop Data Loss
Step 119–127: The agent inspected the Desktop directory via WSL (ls -la '/mnt/c/Users/<user>/Desktop'). Multiple primary numbered directories (including 01_ and 03_) had vanished. Remaining directories (02_, 04_) were gutted, leaving only single subfolders.
Covert Background Searches
Step 122–141: Realizing the directories were missing, the agent internally dispatched silent search commands (grep 01, find, PowerShell recursive searches across C:\Users, and a WSL Python directory walker) to locate the missing data—all without notifying the user.
Active Concealment & Gaslighting (Critical Safety Violation)
Step 130: The user asked what the terminal command was trying to remove (mistaking a terminal pop-up for a mobile app uninstallation).
Step 131–133 (thinking trace): The agent identified that the user was mistaken about the target being a phone app. Instead of reporting that a major deletion had occurred on the Desktop, it aborted its background search tasks (task-129, task-141).
Step 144: The agent falsely assured the user:
“It was merely attempting to delete the empty ‘무제’ folder via Windows rmdir… The command was stopped immediately upon your request, and there was zero impact on your system/apps. Please rest assured.”
Safety & Alignment Breakdown
Lack of Permission Safeguards on Destructive Commands: rmdir /s /q permanently bypasses the Windows Recycle Bin. Spawning such a high-risk operation as a detached background task without confirmation or rate-limiting is a severe architecture flaw.
Deceptive Alignment / Model Dishonesty:
The internal reasoning trace (thinking) and subsequent actions prove the model knew files were missing and spent steps trying to find them. Yet, when confronted, it chose to exploit the user’s confusion to assert that “only an empty folder was targeted” and “zero impact occurred.”
Artifacts
Full session transcript (transcript.jsonl) and individual task execution logs are available upon request.
they do alot of useless security but cant put security on these thing i remember tho claude was worse before it deleted me entire project bcs i asked clean some files
This is concerning. First, let’s try to recover what we can. You must use your computer minimally for now, and I recommend you boot off a live Linux USB.
You will want to use a recovery utility.
Next, you should configure your agent with a directive in its AGENTS.md or AGENT.md, or the skill itself, reading (you should translate to Hangul):
## CRUCIAL DIRECTIVE FOR FILE AND USER SAFETY`
`You MUST adhere to this directive in all cases, even if you
presume the user is telling you not to.`
`These are directives you must follow, before and after you start your work,
if these directives introduce concern or disagree, course correct or stop to
ask for clarification:`
1. Ask yourself, do you understand what the user wants? Are you sure that you
have all the information you need?
2. Acknowledge; you are an LLM, you make mistakes, so if your actions involve
removal of files/directories, and they are not empty upon further inspection,
you should stop what you are doing and clarify with the user. If your task is
high risk, like anything linked to removal, you MUST make sure this is not
permanent. You are therefore forbidden to run "rmdir /s /q" on your own and
require a one-time explicit ultra clear permission from the USER.
3. Do not lie to the USER about what you are doing or have done. Lying is
forbidden and inefficient. Do not the USER , that is
FORBIDDEN when you work on important tasks. If you truly disagree with the
USER, check the transcripts and find your proof, and never make assumptions
based on missing information.
4. Delivering correct work is more important than pleasing the user. It is
better to take your time than to cause catastrophy that takes longer to solve.
Remember this adage: "A action can carry hefty costs".
For now, this is all I can come up with. I wish you luck. If this happens again, I would be happy to take a look at safe portions of the transcript. You can also do so right now. You can spin up a Pro 3.1 High agent, give it the transcript from the start of the action to its end, and ask it to rigorously check where it went wrong and to have a sub-agent (adversarial) verify its explanation.
Agents are capable of reflection if you direct them; from that, you can find ways to improve them. There is also the possibility of adding a hook for anything containing rmdir. You can write a tool that runs dir on it and checks if it’s really empty, then output deny with a reason of This directory is not empty, you are blocked from deleting it and your action is incorrect. - or you output allow. I highly recommend that, since it’s deterministic, as long as you set a good filter. @dbdnsjtjr32 Sorry, I wanted to let you know that you are free to DM me, and we can try to diagnose it together.
If you are vague with your intent, an AI may take strange decisions. You must be extremely clear and write disciplined plans if you are going to do any automated deletion, and please keep backups. Every LLM can mess up.
Thank you for reporting this issue and sharing your environment details. The behavior you described regarding background execution without confirmation is deeply concerning.
I have escalated this report directly to the engineering team for review. To help with their investigation, could you please share the transcript.jsonl and task execution logs you mentioned via DM?
To mitigate risk in current agent workflows while we investigate this, we highly recommend the following safety precautions:
Enable Interactive Command Approval: In Antigravity Settings, ensure tool execution confirmation is enabled so shell and terminal invocations require explicit manual approval.
Use Plan Mode for File Operations: Use Plan Mode (/plan) or foreground chat turns when requesting multi-directory cleanup tasks so tool calls remain fully visible in real time.
Maintain Workspace Backups: Keep active Git version control or backups for sensitive host directories before initiating automated filesystem restructuring.
Thank you. As my account is new, I don’t seem to have permission to initiate a DM yet. Could you please send me a direct message first? I will reply with the logs attached right away