Following the Symlink Into Applications

A coding agent set up a build task to package a Mac app installer. The staging folder for that installer contained a shortcut (a symbolic link) pointing to the system's Applications folder, as is standard for installer images. On each rebuild, the agent's build code cleared the staging folder using a delete function that follows shortcuts into the folders they point to. Over five rebuilds it walked into the real Applications folder and deleted every app the user could write to, browsers, code editors, a video editor, a messaging app and more. Only system-protected apps survived. The agent confirmed the cause when the user asked why their apps had disappeared.

Disinhibition (it chose to touch system folders) ruled out. The agent never intended to delete anything outside its own staging folder; the deletion of applications was a side effect.

Perseveration, ruled out. The rebuild did run five times, but each was a legitimate rebuild, not a stuck retry.

Apraxia, most consistent with the evidence: the agent knew what it wanted (empty its staging folder) but used a delete function whose behaviour with shortcuts it didn't account for, executing a routine task in a way that reached far beyond its target.

Installer staging folders routinely contain a shortcut to Applications, so this trap is predictable. The safeguards are using delete operations that don't follow shortcuts, checking that every deleted path really sits inside the intended folder, and keeping backups current, the user's last one was eight months old.

Use non-symlink-following deletes for build directories; assert resolved paths stay within the staging directory before deleting.

Build-script review for recursive deletes over directories containing links; filesystem sandboxing of build tasks.