• Das Problem. Ein Nutzer berichtete, Claude Code habe unter Windows in 103 Sekunden 48.218 Dateien seines aktiven Projekts gelöscht, nachdem ein Skript beim Durchlaufen in 614 Verzeichnisverbindungen (Junctions) geraten war.
  • Was wir herausgefunden haben. Unter macOS 27 entfernte rm -rf project-link nur den Link. Mit einem Schrägstrich am Ende löschte der Befehl den Ordner und seine vier Dateien, und nichts landete im Papierkorb.
  • Was wir gebaut haben. Mint erfasst jedes Objekt, ohne Links zu folgen, und prüft es vor dem Entfernen noch einmal. Haben ein Link und ein Ordner die Plätze getauscht, behält Mint das Objekt und sagt, warum.

Ohne den Schrägstrich nicht. Auf dem Mac entfernt rm -rf project-link den symbolischen Link und lässt den Ordner, auf den er zeigt, in Ruhe. Mit einem Schrägstrich am Ende löschte rm -rf project-link/ diesen Ordner samt allen vier Dateien darin, und der Link blieb, wo er war. Auch Pythons shutil.rmtree und Apples FileManager löschen den Ordner, sobald der Pfad auf einen Schrägstrich endet. Nichts davon geht über den Papierkorb.

Die Befehle und ihre Ausgaben folgen unten. Am Ende findest du eine einzeilige Prüfung, die nur liest und zeigt, ob dein Mac gelöschte Dateien zurückholen könnte.

Was unter Windows passiert ist

Am 21. September 2026 berichtete Cybersecurity News, Claude Code, ein KI-Coding-Agent, habe in 103 Sekunden 48.218 Dateien des aktiven Projekts gelöscht, von 22:10:31 bis 22:12:14 Uhr US-Ostküstenzeit. Die Zahlen stammen aus dem eigenen Bericht des Nutzers, und der Artikel spricht von einer mutmaßlichen Löschung.

Der Agent räumte mit einem Python-Skript eine alte Spiegelkopie des Projekts aus. Das Skript durchlief die Kopie mit os.walk(..., followlinks=False), damit es keinen Links folgte. Die Kopie enthielt aber 614 Windows-Verzeichnisverbindungen (Junctions), die zurück ins aktive Projekt zeigten, und unter Windows gibt os.path.islink() für eine Junction False zurück. Der Durchlauf hielt jede Junction für einen gewöhnlichen Ordner und ging hinein. Laut dem Bericht wurde dabei auch der Git-Objektspeicher des Projekts geleert.

Den Fall unter Windows haben wir nicht nachgestellt. Wir wollten wissen, wie sich Links auf dem Mac verhalten.

Der Test

Für den Test am 4. Oktober nutzten wir einen Mac mit macOS 27.0.1 (26A434). In zsh 5.9 haben wir in einem Testordner einen Ordner mit vier leeren Dateien und einen symbolischen Link darauf angelegt:

% mkdir my-project
% touch my-project/{app.py,data.csv,notes.md,README.md}
% ln -s my-project project-link

Den Link löschen:

% rm -rf project-link
% ls -F
my-project/
% ls my-project
README.md  app.py  data.csv  notes.md

Nur der Link war weg. my-project und seine Dateien waren noch da. Wir haben den Link neu angelegt und einen Schrägstrich angehängt:

% ln -s my-project project-link
% rm -rf project-link/
% ls -F
project-link@
% ls my-project
ls: my-project: No such file or directory

Diesmal waren my-project und seine vier Dateien weg, und project-link war noch da und zeigte auf einen Ordner, den es nicht mehr gab. rm gab nichts aus und fragte nichts. Ohne -f änderte sich am Ergebnis nichts, und ein zweiter Versuch am 6. Oktober lieferte exakt dieselbe Ausgabe.

Warum ein Schrägstrich das ändert

Der Schrägstrich ändert, worauf der Pfad verweist. Die Pfadauflösung nach POSIX behandelt einen symbolischen Link am Ende eines Pfads nur dann als den Link selbst, wenn kein Schrägstrich folgt. Mit dem Schrägstrich löst das System den Link auf, project-link/ verweist also auf my-project, und rm löscht, was es bekommen hat. Es entfernt die Dateien darin und unter macOS auch den Ordner selbst.

Der Durchlauf selbst verhielt sich auf dem Mac korrekt. Am 6. Oktober listete os.walk('.', followlinks=False) den Eintrag project-link als Ordner auf und ging nicht hinein. Entscheidend war der Pfad, der dem Löschbefehl übergeben wurde.

Python und Swift

Apples /usr/bin/python3 (3.9.6, aus den Entwicklerwerkzeugen), mit einer frischen Kopie des Ordners:

% /usr/bin/python3 -c "import shutil; shutil.rmtree('project-link')"
Traceback (most recent call last):
  ...
OSError: Cannot call rmtree on a symbolic link
% /usr/bin/python3 -c "import shutil; shutil.rmtree('project-link/')"
% ls my-project
ls: my-project: No such file or directory

Ohne Schrägstrich verweigert rmtree den Dienst. Mit Schrägstrich löscht es my-project kommentarlos. Auch Python 3.14.5 von Homebrew löschte den Ordner beim zweiten Aufruf. Sein erster Aufruf scheiterte mit einer anderen Meldung, OSError: [Errno None] None: 'project-link'.

Dann Foundation, aus einem kleinen Swift-Programm. FileManager.default.removeItem(atPath:) entfernte mit project-link nur den Link und mit project-link/ den Ordner samt Dateien. Der Link blieb erhalten.

Kein Papierkorb, kein Zurücklegen

rm, shutil.rmtree und removeItem löschen Dateien sofort. Der Papierkorb bleibt außen vor, es gibt also kein „Zurücklegen“, und APFS kennt keine Funktion, um Gelöschtes wiederherzustellen. Es gibt Apps zur Datenrettung, aber wir haben keine getestet. Was Dateien verlässlich zurückbringt, ist ein Backup.

Der Test-Mac hatte kein Backup

Unser Test-Mac am 4. Oktober:

% tmutil listlocalsnapshots /
Snapshots for disk /:
% tmutil destinationinfo
tmutil: No destinations configured.

Keine lokalen Schnappschüsse und kein Backup-Volume, und bis zum 6. Oktober hatte sich daran nichts geändert.

Laut Apples Artikel zu lokalen Schnappschüssen legt Time Machine auch auf dem Mac selbst Backups ab. Time Machine erstellt etwa stündlich einen Schnappschuss des Startvolumes und behält jeden 24 Stunden lang, dazu einen Schnappschuss des letzten erfolgreichen Backups, bis der Platz gebraucht wird. Ohne eingerichtetes Backup-Volume hatte dieser Mac keinen davon. Unsere Anleitung zu Time-Machine-Schnappschüssen erklärt, was sie sind und warum sie zu den Systemdaten zählen.

Wenn ein Agent auf deinem Mac Befehle ausführt

Ein Agent mit Terminalzugriff kann rm -rf eintippen wie jeder andere auch, und in diesem Test entschied ein einziges Zeichen darüber, ob ein Link oder ein Ordner gelöscht wurde. Wie oft Agenten einen Pfad mit einem Schrägstrich abschließen, wissen wir nicht. In deiner Hand liegt das Backup, und das richtest du einmal ein: Systemeinstellungen > Allgemein > Time Machine > Backup-Volume hinzufügen. Das lohnt sich, bevor ein Agent auf deinem Mac Zugriff aufs Terminal bekommt.

Prüf deinen Mac

Die Zeile unten liest nur und fragt nicht nach einem Passwort. Füge sie als eine Zeile ins Terminal ein:

d=$(tmutil destinationinfo 2>&1); n=$(tmutil listlocalsnapshots / 2>/dev/null | grep -c 'com.apple'); l=$(tmutil latestbackup 2>/dev/null | sed 's#.*/##'); echo "Backup disk: $(echo "$d" | grep -q 'No destinations' && echo none || echo "$d" | awk -F' *: ' '/^Name/{print $2; exit}')"; echo "Local snapshots: $n"; echo "Latest backup: ${l:-none}"

Bei uns lautete die Ausgabe:

Backup disk: none
Local snapshots: 0
Latest backup: none

Wir haben sie in zsh 5.9 und in der Bash 3.2 ausgeführt, die macOS mitbringt. Mit eingerichtetem Time-Machine-Volume sollte die erste Zeile das Volume nennen und die letzte das neueste Backup zeigen, aber diese Ausgabe haben wir selbst nicht gesehen. Die Zahl in der Mitte zählt die Schnappschüsse, die tmutil listlocalsnapshots / auflistet; führ den Befehl allein aus, um ihre Namen zu sehen.

Was Mint macht

Mint ist eine Mac-App für den Speicherplatz und löscht deshalb auch Dateien. Wenn Mint etwas auflistet, hält es dieses Objekt selbst fest, ohne Links zu folgen, und prüft es unmittelbar vor dem Entfernen noch einmal. Liegt inzwischen ein Link, wo ein Ordner war, oder ein Ordner, wo ein Link war, behält Mint das Objekt und sagt dir, warum. Dateien, die du unter Yours auswählst, können in den Papierkorb gehen, wo „Undo“ in Mint sie zurücklegen kann. Caches und Build-Artefakte unter Safe to clean werden direkt gelöscht. Mint erstellt keine Backups und ersetzt Time Machine nicht.

Fragen

Kann rm -rf den Ordner auch ohne Schrägstrich löschen? In keinem unserer Versuche. Ohne Schrägstrich war nur der Link weg.

Spielt der Schrägstrich bei einem normalen Ordner eine Rolle? Nein. rm -rf my-project und rm -rf my-project/ löschen beide einen echten Ordner. Der Schrägstrich spielt nur eine Rolle, wenn der letzte Teil des Pfads ein Link ist.

Wie sehe ich die Links in einem Ordner, bevor ich ihn lösche? Führ find my-project -type l aus. Der Befehl listet jeden symbolischen Link darin auf und ändert nichts. In unserem Testordner gab find . -type l die Zeile ./project-link aus.

Hätte ein lokaler Schnappschuss die Dateien gerettet? Laut Apple kann Time Machine Dateien aus lokalen Schnappschüssen wiederherstellen, wenn das Backup-Volume nicht verbunden ist. Eine Wiederherstellung haben wir nicht ausprobiert, und unser Test-Mac hatte keine Schnappschüsse, mit denen wir es hätten versuchen können.

Ist das ein Fehler in macOS? Dass der Link aufgelöst wird, wenn der Pfad auf einen Schrägstrich endet, schreibt POSIX so vor. Ob am Ende auch der Ordner selbst verschwindet, kann sich je nach System unterscheiden; unter macOS war es so.