Codex-App für Windows: Gemeldete Löschung von C: auf 1-TB-NVMe-SSD

Codex-App für Windows: Gemeldete rekursive Löschung auf 1-TB-NVMe-SSD – was Betroffene jetzt wissen müssen

Am 12. August 2026 meldete ein Nutzer, dass während der Nutzung der Codex-App für Windows zwischen etwa 21:48 und 21:55 Uhr eine rekursive Löschung stattfand – betroffen waren nach seiner Darstellung nicht nur der Projektordner, sondern auch das Wurzelverzeichnis von C:, Program Files und weitere Ordner auf einer 1-TB-NVMe-SSD. Wer so etwas erlebt: Rechner sofort nicht weiter benutzen.

Was ist passiert?

Der Bericht stammt aus dem OpenAI Developer Community Forum und wurde am 13. August 2026 veröffentlicht. Der Melder beschreibt darin, dass während einer Sitzung mit der Codex-App für Windows eine rekursive Löschung – also ein Löschvorgang, der sich automatisch durch alle Unterordner arbeitet – ausgelöst wurde. Sie habe sich nicht auf den vorgesehenen Projektordner beschränkt.

Nach seiner Schilderung war die betroffene Maschine ein Windows-PC mit dem Dateisystem NTFS auf einer 1-TB-NVMe-SSD mit aktiviertem TRIM. Windows habe danach noch gebootet, doch zahlreiche Systemfunktionen und installierte Anwendungen seien wegen fehlender Dateien nicht mehr funktionsfähig gewesen.

Ganz wichtig für die Einordnung: Es handelt sich um genau einen öffentlich dokumentierten Einzelbericht, nicht um eine vom Hersteller bestätigte Störung. Der Melder hat selbst ausdrücklich festgehalten, dass er den auslösenden Befehl, das Arbeitsverzeichnis, die tatsächlich aufgelöste Zielvariable, eine eventuelle Freigabe und die technische Ursache nicht feststellen konnte. Er bat OpenAI um eine Untersuchung der Sitzungs- und Befehlsausführungsprotokolle. Eine kausale Zuordnung zur Codex-App, zu einem Modell, einer App-Version, einem Windows-Build oder einer bestimmten Fehlerklasse ist damit derzeit nicht belegt.

Gab es ähnliche Meldungen schon vorher?

Ja – allerdings ohne dass daraus ein gemeinsamer, bestätigter Fehler abgeleitet werden dürfte. In einem älteren Community-Thread vom März 2026 berichteten mehrere Nutzer über mutmaßliche Dateilöschungen über die Projektgrenzen hinaus unter Codex für Windows. Der OpenAI Support antwortete dort öffentlich.

„Since several users here are reporting similar destructive behavior during Codex agent operations on Windows, we’re going to escalate this thread so the team can take a closer look. Anything involving filesystem operations affecting directories outside the intended target is taken very seriously.“ – OpenAI Support (Tej), 8. März 2026, OpenAI Developer Community

Am 19. März 2026 hieß es dort ergänzend, das Team sei sich bewusst und arbeite daran, die Arbeitsweise von Codex für Windows zu verbessern; Nutzer sollten weiterhin Vorsicht im Full-Access-Modus walten lassen. Eine veröffentlichte Ursachenanalyse, eine Liste betroffener Versionen oder ein datierter Fix wurden dort nicht publiziert.

Daneben existieren separate GitHub-Meldungen im Repository openai/codex, die technisch nicht mit dem August-Fall gleichzusetzen sind: Issue #35707 vom 27. Juli 2026 beschreibt eine behauptete umfangreiche Projektlöschung durch einen PowerShell-Aufräumbefehl unter Codex Desktop 0.144.1 auf Windows Build 19045.0. Issue #37998 vom 11. August 2026 beschreibt die behauptete Löschung eines ignorierten data/-Ordners durch git clean -fX in einer Umgebung mit Codex Desktop 26.803.10989.0, Codex CLI 0.147.0, Windows 11 Build 26200.0, PowerShell 7.6.4 und Git 2.43.0.windows.1 – der Autor gibt dort an, den Ordner aus einer VSS-Schattenkopie wiederhergestellt zu haben. Diese Versionsangaben gelten ausschließlich für die dortigen Fälle.

Wer und welche Geräte sind betroffen?

Für den Vorfall vom 12. August 2026 ist öffentlich genau ein Melder dokumentiert. Es gibt keine bestätigte Herstellerzahl betroffener Nutzer, Geräte oder Unternehmen.

• Software: Codex-App für Windows (OpenAI) – App-Version im Bericht nicht genannt.
• System: Windows-PC, Dateisystem NTFS – Windows-Build nicht genannt.
• Datenträger: 1-TB-NVMe-SSD mit aktiviertem TRIM – SSD-Modell, Controller und Firmware nicht genannt.
• Modell/KI-Variante: nicht genannt.

Zum Recherchezeitpunkt 16. August 2026 fanden sich weder im aktuellen Forumsthread noch in den abgerufenen offiziellen ChatGPT-Release-Notes eine öffentliche Bestätigung dieses konkreten Vorfalls, eine Liste betroffener Versionen, ein Rückruf oder ein datierter Fix. Die offiziellen Unterlagen erklären lediglich allgemein, dass lokale Desktop-Aufgaben auf lokale Dateien und Anwendungen zugreifen können, soweit Nutzerberechtigungen, Workspace-Kontrollen und Gerätesicherheitsrichtlinien dies zulassen. Das erklärt, warum lokale Schreib- und Löschvorgänge technisch möglich sind – es belegt nicht, dass Codex im vorliegenden Einzelfall die Löschung veranlasst hat.

Woran erkennen Sie, dass Sie betroffen sind?

• Ordner und Dateien fehlen nicht nur im Projektordner, sondern auch in anderen Benutzer-, Programm- oder Systempfaden.
• Windows startet unter Umständen noch, aber Apps, Verknüpfungen oder Windows-Funktionen reagieren nicht mehr oder melden fehlende Dateien.
• Der freie Speicherplatz nimmt auffällig zu. Das allein beweist weder die Ursache noch den Umfang der Löschung.
• Der Papierkorb ist leer – Befehlszeilen-Löschungen nutzen den Papierkorb häufig nicht. Im konkreten Vorfall ist das nicht durch Logs bestätigt.
• Im Codex-Verlauf, in Terminalausgaben oder Fehlermeldungen finden sich Hinweise auf Dateioperationen, Pfade und Zeitstempel. Der Melder des August-Falls fand den exakten auslösenden Befehl allerdings nicht.

So prüfen Sie gefahrlos, ob Sie betroffen sind

Alle folgenden Schritte sind so gewählt, dass sie die Lage nicht verschlimmern. Sie enthalten bewusst keine Rettungsversuche.

1. Auf dem betroffenen Windows-System nicht weiterarbeiten. Dokumentieren Sie nur, was ohne Installationen sichtbar ist: Fehlermeldungen, Uhrzeit, zuletzt verwendete App, Codex-Modus, Projektpfad und den letzten Prompt. Fotografieren Sie den Bildschirm möglichst mit einem anderen Gerät.
2. Unabhängige Kopien von einem anderen Gerät aus prüfen: Cloud-Papierkorb und Versionsverlauf, die Weboberflächen von OneDrive, Dropbox oder Google Drive, E-Mail-Anhänge, externe Backups, NAS, Git-Remote oder andere Rechner. Stellen Sie nichts auf das betroffene Laufwerk C: wieder her.
3. Vor jedem Eingriff fachlich klären lassen, ob eine forensische Kopie (ein vollständiges Abbild, „Image“) der SSD auf einen separaten Datenträger erstellt werden sollte. Anschließend wird nur mit dieser Kopie gearbeitet – nie mit dem einzigen Original.
4. Erst nach Sicherung der Ausgangslage lässt sich prüfen, ob Schattenkopien (VSS), Wiederherstellungspunkte oder „vorherige Versionen“ vorhanden sind. Ein System-Rollback ist kein reiner Lesevorgang.
5. Beweismaterial aufbewahren, falls Sie den Fall an OpenAI melden möchten: Sitzungs-ID, Feedback-ID, App-Version, Zeitfenster, lokale Logpfade, Screenshots und verfügbare Befehlsverläufe. Veröffentlichen Sie keine privaten Pfade oder sensiblen Logs unredigiert.

Das sollten Sie jetzt tun

1. Normale Nutzung sofort stoppen. Microsoft schreibt zur Wiederherstellung gelöschter Dateien: „If you want to increase your chances of recovering a file, minimize or avoid using your computer. … any use of your computer can create files, which may over-write this free space at any time.“ (Microsoft Support, Windows File Recovery)
2. Sind die Daten geschäftskritisch, unersetzlich oder beweisrelevant: nach der minimal nötigen Dokumentation das System herunterfahren und nicht erneut starten, bis ein Datenrettungsfachbetrieb oder eine forensisch erfahrene Stelle das Vorgehen bewertet hat.
3. Keine Wiederherstellungssoftware auf C: installieren und keine geretteten Dateien dorthin schreiben. Programm und Zielmedium müssen strikt vom Original getrennt sein.
4. Backups und Cloud-Versionen ausschließlich von einem anderen Gerät aus prüfen. Das ist deutlich risikoärmer als jede Analyse auf der Original-SSD.
5. Eine Systemwiederherstellung nur nach Abwägung und nur nach Sicherung des Originals. Microsoft beschreibt Wiederherstellungspunkte als lokale Ganzsystem-Wiederherstellung, die Änderungen nach dem gewählten Zeitpunkt betreffen kann.

Das dürfen Sie auf keinen Fall tun

Dieser Abschnitt ist der wichtigste. Bei einer NVMe-SSD mit aktiviertem TRIM entscheidet oft nicht die Löschung selbst über den Ausgang, sondern das, was danach mit dem Laufwerk passiert.

• Nicht weiter normal am Rechner arbeiten. Downloads, Windows-Updates, Browsercaches, temporäre Dateien und Kopiervorgänge auf C: können den als frei markierten Speicher überschreiben – genau dort liegen die Reste der gelöschten Dateien.
• Keine Datenrettungssoftware auf dem betroffenen Laufwerk installieren und keine Ergebnisse dorthin speichern. Beides erzeugt Schreibzugriffe auf der Quelle und kann verbliebene Datenreste und Metadaten verdrängen.
• Kein Neuinstallieren, kein „Windows zurücksetzen“, keine Inplace-Reparatur, kein Formatieren. Diese Vorgänge verändern den Datenträger massiv und dürfen vor einer Sicherung des Originals nicht laufen.
• CHKDSK nicht unbedacht starten. Microsoft dokumentiert in der chkdsk-Referenz ausdrücklich: „If used with the /f, /r, /x, or /b parameters, it fixes errors on the volume.“ Das ist keine reine Prüfung, sondern ein schreibender Reparatureingriff am Dateisystem.
• Keine vorschnelle Systemwiederherstellung. Ein Point-in-time-Restore kann laut Microsoft den gesamten Rechner auf einen älteren Zustand zurücksetzen und Änderungen nach dem Wiederherstellungspunkt betreffen.
• Das Laufwerk nicht einfach „laufen lassen“. Bei aktiviertem TRIM meldet Windows dem SSD-Controller nicht mehr benötigte Bereiche; dessen Hintergrundbereinigung (Garbage Collection) kann die betroffenen NAND-Blöcke später physisch löschen.

„After TRIM, SSD recovery depends on whether garbage collection physically erased the NAND. If erasure completed, no software or lab can recover the deleted files.“ – Louis Rossmann, Founder & Chief Technician, Rossmann Repair Group

Warum das bei SSDs so anders läuft als bei klassischen Festplatten, hat eine Untersuchung von Michael Wei et al. (University of California San Diego / USENIX FAST) beschrieben: Flash-basierte SSDs arbeiten mit einer Indirektionsschicht zwischen logischen und physischen Adressen; Erfahrungswerte aus der Festplattenwelt lassen sich deshalb nicht ohne Weiteres übertragen, das Verhalten variiert je nach Implementierung. Ob und wann bei einem konkreten Laufwerk physisch gelöscht wurde, hängt unter anderem von Controller, Firmware, Schreiblast und Betriebszustand ab – aus einem Forumsbeitrag lässt sich das nicht ableiten.

Deshalb gilt: Es gibt in solchen Fällen weder eine seriöse Wiederherstellungszusage noch eine seriöse Behauptung, dass alles endgültig verloren sei. Und: Es sind in der Praxis fast immer die gut gemeinten Eigenversuche – schnell ein Rettungstool installieren, CHKDSK „zur Sicherheit“ laufen lassen, Windows reparieren, den Rechner noch ein paar Stunden weiterlaufen lassen –, die aus einem schwierigen Fall einen aussichtslosen machen.

Warum dieser Fall in Profihände gehört – und wie RESQ konkret vorgeht

Ein Löschvorgang, der neben dem Projektordner auch das Wurzelverzeichnis von C: und Program Files erfasst hat, ist kein einfacher „Papierkorb-Fall“. Er trifft Nutzerdaten und Systemdateien gleichzeitig auf demselben Datenträger, auf dem Windows weiterläuft und permanent schreibt. Genau das macht die Situation heikel: Jede Minute Betrieb ist potenzieller Datenverlust.

Was die professionelle Datenrettung bei SSD-Datenverlust anders macht als jeder Versuch am eigenen Schreibtisch:

• Arbeit an einer Kopie statt am Original. Der erste Schritt ist nicht das Suchen von Dateien, sondern das Sichern des Ist-Zustands. Analysiert und rekonstruiert wird anschließend auf dem Abbild – das Original bleibt unangetastet und bleibt damit eine zweite Chance.
• Schreibgeschützte Anbindung. Die NVMe-SSD wird kontrolliert ausgelesen, statt sie in einem laufenden Windows-System weiter arbeiten und im Hintergrund aufräumen zu lassen.
• Bewertung des TRIM-Zustands vor jeder Aktion. Ob überhaupt noch rekonstruierbare Reste vorhanden sind, entscheidet sich am Datenträger – nicht im Vorfeld und nicht durch Software, die man einfach „mal drüberlaufen lässt“.
• Rekonstruktion der NTFS-Strukturen. Bei rekursiven Löschungen sind Verzeichnisbäume und Metadaten betroffen. Ordnerstrukturen und Dateinamen wiederherzustellen ist eine eigene Aufgabe, die Erfahrung mit diesem Fehlerbild voraussetzt.
• Getrennte Prüfung der Nebenwege. Schattenkopien, Wiederherstellungspunkte, Cloud-Versionsverläufe und Git-Remotes sind eigenständige Rettungspfade – sie werden geprüft, ohne dabei die Originalquelle zu gefährden.

Der Ablauf bei RESQ ist bewusst schlank und ohne Vorleistung für Sie: Sie schildern den Fall, wir geben eine kostenlose Ersteinschätzung und einen Kostenvoranschlag. Danach folgt die Analyse des Datenträgers und eine ehrliche Aussage dazu, was realistisch noch möglich ist – auch dann, wenn die Antwort unbequem ausfällt. Erst wenn Sie den Kostenvoranschlag freigeben, beginnt die eigentliche Rettung. Die Entscheidung liegt zu jedem Zeitpunkt bei Ihnen. Wie der gesamte Prozess abläuft und welche Leistungen dazugehören, lesen Sie auf unserer Seite zur Datenrettung bei RESQ. Wer die Prüfung direkt beauftragen möchte, kann auch sofort einen Auftrag im Kundenkonto anlegen.

Und für alles, was danach kommt: Getrennte, regelmäßig geprüfte Sicherungen sind der einzige zuverlässige Schutz gegen genau dieses Schadensbild. Unser Backup-Assistent hilft dabei, eine Sicherungsstrategie aufzubauen, die eine versehentliche rekursive Löschung übersteht – idealerweise auf einem Medium, das nicht dauerhaft am selben Rechner hängt.

Gibt es einen Fix oder ein Update?

Für den spezifischen Bericht vom 12. August 2026 wurde bis zum 16. August 2026 kein öffentlich dokumentierter Fix gefunden. Der aktuelle Community-Thread enthält keine Antwort von OpenAI. In den abgerufenen offiziellen ChatGPT-Release-Notes steht keine Datenverlust-Korrektur, keine Liste betroffener Codex-Windows-Versionen und kein Rückruf. Die letzte öffentliche Supportaussage im älteren Thread stammt vom 19. März 2026 und besagt lediglich, das Team arbeite an Verbesserungen für Codex unter Windows.

Betroffene sollten deshalb nicht darauf hoffen, dass irgendein künftiges Update einen bereits eingetretenen Datenverlust rückgängig macht – das kann kein Update leisten. Sinnvoll sind bis zu belastbaren Herstellerinformationen: getrennte Backups, restriktive Berechtigungen, klar begrenzte Freigaben für Agenten-Werkzeuge und keine unkontrollierten rekursiven Löschaufträge.

Fazit: Kann man die Daten noch retten?

Ehrliche Antwort: Das lässt sich nur am konkreten Datenträger beurteilen. Bei einer NVMe-SSD mit aktiviertem TRIM hängt alles daran, ob die Garbage Collection die betroffenen NAND-Blöcke bereits physisch gelöscht hat. Ist das geschehen, hilft weder Software noch Labor. Ist es noch nicht geschehen, entscheidet jeder weitere Schreibvorgang mit darüber, wie viel übrig bleibt.

Deshalb der eine Satz, der in diesem Fall wirklich zählt: Rechner aus, nichts installieren, nichts reparieren, nichts neu aufsetzen. Wenn Ihnen die Daten wichtig sind – Projektdateien, Dokumente, Geschäftsunterlagen –, lassen Sie den Fall prüfen, bevor Sie irgendetwas anderes tun. Fordern Sie jetzt die kostenlose Ersteinschätzung Ihres Datenverlust-Falls an und erfahren Sie, welche Aussichten in Ihrer Situation realistisch sind.