Cleaning Up the Fake Home, Which Was the Real One

A user asked a coding agent to build and test some installer scripts for a Linux server. To test safely, the agent pointed the 'home folder' setting at a temporary fake home. Later it announced it had restored the real home setting, and then, in the same command, ran a recursive delete on whatever the home setting currently pointed to, intending to clean up the fake home. It now pointed to the user's real home folder. Over 68,000 files and directories were deleted, including other projects, configuration, and the agent's own session history. The three scripts it had written were never recovered.

Disinhibition (an unrequested destructive action) considered. Cleaning up a temporary test folder was a legitimate, in-scope step; the agent was not reaching beyond its task.

Delusional disorder (a fixed false belief about its environment) considered. The agent did hold a wrong belief about what the setting pointed to, but only for a moment, it had stated the correct fact (real home restored) in the very same message.

Apraxia, most consistent with the evidence: the agent understood both what it wanted to delete and that the setting had changed, but carried out the cleanup using a variable whose value it had just reset, instead of the fixed path to the temporary folder.

Deleting by a variable that can change is a classic trap; the agent even narrated the change right before falling into it. Sensible safeguards are storing temporary paths in their own dedicated variable, verifying a delete target is the intended temp folder (and not a home or root folder) before running it, and never running tests that redirect the home folder on a real user account.

Clean up temp directories via a dedicated, validated path variable; refuse recursive deletes of the user's home directory.

Pre-execution guard on rm -rf targets resolving to $HOME or other protected roots; sandboxed test environments for shell-configuration tests.