ChatGPT und Codex auf ein anderes Laufwerk verschieben

Wir haben untersucht, wo ChatGPT und Codex ihre Dateien speichern, die App selbst und ihre Hauptdaten auf Laufwerk D untergebracht und etwa 3.78GB aktiver Laufzeitumgebungen sowie weiterer Dateien auf Laufwerk C belassen. Die betreffenden Dateien lassen sich in drei Gruppen einteilen: App, gespeicherte Daten und Laufzeitumgebungen.

Drei Hauptgruppen von Dateien

„Alles zu ChatGPT auf Laufwerk D verschieben“ erwies sich als zu pauschal. Die Dateien zum Ausführen der App sind von den Dateien für Gespräche und Einstellungen getrennt. Auch die von der App aufgerufene CLI, Python, Node und weitere Komponenten lagen an unterschiedlichen Orten.

Die Dokumentation der Umgebungsvariablen von OpenAI legt fest, dass CODEX_HOME das Stammverzeichnis für Konfiguration, Authentifizierung, Protokolle, Sitzungen, Skills und zugehörige Zustandsdaten bestimmt. Das Verzeichnis muss bereits existieren. Diese Einstellung verschiebt nicht gleichzeitig die App selbst, Windows-AppData und sämtliche zugehörigen Laufzeitumgebungen.

Lokale Codex-Sitzungen zu erhalten ist außerdem etwas anderes, als den gesamten in der Cloud gespeicherten Gesprächsverlauf eines ChatGPT-Kontos zu exportieren. Diese Sicherung betrachten wir nicht als vollständigen Export aller ChatGPT-Daten.

Was bereits auf Laufwerk D lag und was sich änderte

Zu Beginn der Untersuchung lagen die eigentlichen Codex-Home-Daten bereits auf Laufwerk D. Auf Laufwerk C war %USERPROFILE%\.codex eine Verzeichnisverknüpfung (Junction) zu CodexHome auf Laufwerk D. Bei diesem Vorgang wurden also nicht erst ungefähr 65GB Home-Daten von Laufwerk C nach Laufwerk D übertragen; sie lagen bereits auf Laufwerk D.

Eine Junction macht einen Ordner zum Zugang zu einem anderen Ordner. Microsoft beschreibt, wie sie auf ein anderes lokales Volume desselben Computers verweisen kann. Dateien über einen Zugang auf Laufwerk C zu sehen bedeutet nicht zwangsläufig, dass dort eine zweite Kopie gespeichert ist. Microsofts Erklärung zu Junctions

Diese Unterscheidung war auch bei der Untersuchung des Browserproblems wichtig. Der integrierte Browser und die Chrome-Anbindung funktionierten wieder, nachdem wir den tatsächlichen Home-Pfad angegeben, die App vollständig beendet und neu gestartet hatten. Die Auswirkungen von Pfadeinstellung und Neustart haben wir jedoch nicht getrennt gemessen. Unser Fallbericht zur Browserwiederherstellung beschreibt den Zustand vor und nach der Änderung sowie die durchgeführten Prüfungen.

Etwa 68.6GB sichern, während die Apps beendet sind

Bevor wir den App-Start änderten, haben wir eine Sicherung erstellt, während ChatGPT, Codex und die zugehörigen Codex-Komponenten in der IDE beendet waren. Kopiert wurden das Codex-Home, der tatsächliche Speicherbereich des App-Pakets und der OpenAI-Ordner am gewöhnlichen Local-AppData-Speicherort. Die Sicherung blieb auf Laufwerk C statt auf dem Ziellaufwerk.

Die Tabelle zeigt die logische Größe der auf diesem Computer erstellten Sicherung. Ein GB entspricht hier einer Milliarde Byte. Die ungefähr 68.6GB sind die Größe der auf Laufwerk C aufbewahrten Sicherung, nicht der auf Laufwerk C freigegebene Speicherplatz.

Nur der Benutzer und SYSTEM können auf den Sicherungsort zugreifen. Die Sicherung selbst ist diesem Artikel nicht beigefügt, da sie Authentifizierungsdateien und private Gespräche enthält.

CODEX_HOME testen und anschließend den normalen Start prüfen

Da das Home-Verzeichnis bereits auf Laufwerk D lag, haben wir zunächst einen einzelnen Start mit CODEX_HOME=D:\CodexHome getestet. Dabei blieb die App-Version unverändert; wir haben die App vollständig beendet und eine neue Instanz gestartet.

Geändert wurde nur die benutzerbezogene Variable CODEX_HOME. Systemweite Umgebungsvariablen und PATH blieben unverändert. Windows unterscheidet bei Umgebungsvariablen zwischen Prozess-, Benutzer- und Systemebene. Deshalb haben wir den normalen App-Start geprüft und uns nicht mit dem angezeigten Wert einer einzelnen Shell begnügt. Microsofts Erklärung zu Umgebungsvariablen

Nur lesende Befehle zum Prüfen des Speicherorts

Die folgenden PowerShell-Befehle lesen ausschließlich Werte. Die erste Zeile zeigt den von dieser Shell verwendeten Wert, die zweite und dritte die in Windows gespeicherten Einstellungen, die letzte den Zugang zum Standard-Home. Werte können leer sein; eine leere Ausgabe allein bedeutet daher keinen Datenverlust.

$env:CODEX_HOME
[Environment]::GetEnvironmentVariable('CODEX_HOME', 'User')
[Environment]::GetEnvironmentVariable('CODEX_HOME', 'Machine')
Get-Item -LiteralPath (Join-Path $env:USERPROFILE '.codex') -Force |
  Select-Object FullName, Attributes, LinkType, Target

Hier sind keine Befehle zum Verschieben oder Löschen enthalten. Bei diesem Test lagen die Daten bereits auf Laufwerk D; das unterscheidet sich davon, die Einstellung einfach auf einen leeren Ordner zu setzen. Klären Sie vor der Anwendung auf einem anderen Computer, was kopiert werden muss, welche Apps zu beenden sind und wohin Sie Daten wiederherstellen würden.

Die App mit der integrierten Windows-Funktion verschieben

Nach der Prüfung von Home-Einstellung und Browserwiederherstellung wählte der Betreiber in der Windows-App-Liste für ChatGPT „Verschieben“ und verschob die App auf Laufwerk D. Ziel waren die von Windows verwalteten Bereiche WindowsApps und WpSystem. Microsofts Erklärung zu Paketspeicherorten

Wir haben das Ereignis über das erfolgreiche Verschieben, die gültige Signatur der ausführbaren Datei auf Laufwerk D (OpenAI OpCo) und die Verknüpfung auf Laufwerk C geprüft. Bei den App-Daten stimmten außerdem Geräte-IDs und Datei-IDs der entsprechenden Ordner überein.

Ein angezeigter Speicherort allein belegt weder einen erfolgreichen Umzug noch eine doppelte Speicherung. Wir haben tatsächliche Speicherorte, Verknüpfungsziele und Grundfunktionen gemeinsam geprüft. Von Windows verwaltete Zugänge und Berechtigungen haben wir nicht verändert.

Warum etwa 3.78GB auf Laufwerk C blieben

Auch nach dem Verschieben der Hauptkomponenten blieben aktiv genutzte Daten auf Laufwerk C. Die folgende Tabelle fasst bekannte zugehörige Speicherbereiche zusammen, ohne Zugänge zu Laufwerk D doppelt zu zählen.

Diese Summe ist die logische Größe bekannter Ordner. Sie erfasst nicht vollständig Update-Caches, Wiederherstellungspunkte oder sämtliche von allen Browsern und Editoren auf Laufwerk C gespeicherten Daten.

Die auf Laufwerk C belassenen Laufzeitumgebungen funktionieren auch ohne entsprechende Kopien auf Laufwerk D, weil die App die aktuellen Dateien auf Laufwerk C verwendet. Werden sie in der Annahme gelöscht, sie seien bereits umgezogen, können CLI oder Browsersteuerung ausfallen. Die endgültige Konfiguration dieses Falls nutzt beide Laufwerke, C und D.

Wir haben auch die offizielle Variable CODEX_INSTALL_DIR untersucht. Sie ändert jedoch den Installationsort des eigenständigen CLI-Installers und verschiebt nicht sämtliche App-verwalteten CLI-Komponenten und gemeinsamen Laufzeitumgebungen. Eine zusätzliche CLI-Installation auf Laufwerk D belegt nicht, dass die vorhandenen Dateien auf Laufwerk C überflüssig sind.

Außerdem haben wir den Update-Ablauf dieser Version unverändert untersucht und das Ersetzen mit kleinen Testordnern erprobt. In einer Konfiguration wurde der zu aktualisierende Ordner als Verknüpfung zu Laufwerk D angelegt. Diese Verknüpfung wurde dann als alte Version beiseite verschoben, während auf Laufwerk C ein neuer regulärer Ordner entstand. Dieser Test prüfte nur den Dateiaustausch; er war kein Migrationstest der echten App.

Nur um ungefähr 3GB Laufzeitumgebungen zu verschieben, wollten wir keine inoffiziellen Speicherorte und zusätzlichen Prüfungen nach Updates einführen. Wir haben den Nutzen des Umzugs von App und Hauptdaten auf Laufwerk D gegen den verbleibenden Platzbedarf auf Laufwerk C abgewogen und die normal funktionierenden Komponenten beibehalten.

Prüfungen nach der Migration

Wir haben nicht nur geprüft, ob die App startet. Die aktuell gespeicherten Werte wurden mit der Sicherung verglichen. Die geprüften Einträge stimmten überein, darunter 2 angeheftete Chats, 18 angeheftete Projekte, 63 lokale Projekte, 43 Einträge zur Projektreihenfolge und 58 Chat-Projekt-Zuordnungen. Verglichen wurden die vollständigen Werte der ausgewählten Einträge, nicht nur ihre Anzahl.

Bei Verlauf und zugehörigen Dateien waren alle entsprechenden Dateien der Sicherung vorhanden und lesbar: 459 Dateien in sessions, 39 in archived_sessions, 4 in attachments und 3 in automations. Es gab 0 fehlende Dateien und 0 Lesefehler. Dies war eine Prüfung des Dateivorhandenseins; nicht jeder Gesprächsinhalt und nicht der gesamte Inhalt jeder Datenbank wurde erneut gehasht.

Die Prüfung des CLI-Anmeldestatus war erfolgreich. Der integrierte Browser konnte eine öffentliche Seite lesen, einen Link anklicken und zurückgehen. Lesen und Navigation haben wir außerdem in einem eigenen Chrome-Testtab geprüft und diesen anschließend geschlossen. Inhalte bestehender privater Tabs wurden für den Artikel nicht erhoben.

Einen normalen App-Neustart haben wir geprüft. Ob die Konfiguration nach einem Neustart des PCs oder einem künftigen App-Update weiter funktioniert, wurde noch nicht geprüft. Diese beiden Prüfungen wurden auf einen für den Benutzer passenden Zeitpunkt verschoben. Nur zum Abschluss dieses Artikels haben wir keinen weiteren Neustart vorgenommen.

Die beibehaltene Konfiguration

Innerhalb dieses Umfangs betrachteten wir die Migration als abgeschlossen: den tatsächlichen Home-Pfad auf Laufwerk D direkt angeben, App und Hauptdaten auf Laufwerk D unterbringen und Laufzeitumgebungen auf Laufwerk C belassen. Die ungefähr 68.6GB große Sicherung vor der Migration bleibt auf Laufwerk C; über ihren Löschzeitpunkt entscheidet der Benutzer gesondert.

Entscheidend beim Wechsel auf ein anderes Laufwerk war zu verstehen, welche Daten wo liegen, welche App sie verwendet und was zur Wiederherstellung aufbewahrt wird, statt die Belegung von Laufwerk C auf null zu senken. Insbesondere bei der ersten Registrierung eines Ziels als Windows-App-Speicherort muss der Plan zum Beenden von Anwendungen auch virtuelle Datenträger und aktive Projekte auf demselben Laufwerk berücksichtigen.

Reihenfolge bei einer ähnlichen Migration

1. Teilen Sie die zu verschiebenden Teile in drei Gruppen ein, nämlich Codex-Home, App-Programm sowie Hauptdaten und Laufzeitumgebungen der CLI, und prüfen Sie jeweils den aktuellen Speicherort.
2. Beenden Sie nicht nur ChatGPT und Codex, sondern auch Apps, die das Ziellaufwerk nutzen (etwa die virtuellen Datenträger von Docker), sowie laufende Projekte.
3. Erstellen Sie bei beendeten Apps eine Sicherung und vergleichen Sie Anzahl und Größe. Bei wichtigen Dateien wie Einstellungen und Authentifizierungsdaten vergleichen Sie zusätzlich die Hashwerte. Bewahren Sie die Sicherung auf einem anderen Laufwerk als dem Ziel auf.
4. Testen Sie CODEX_HOME zunächst mit einem einzelnen Start und prüfen Sie die Grundfunktionen, bevor Sie die Benutzerumgebungsvariable setzen.
5. Verschieben Sie das App-Programm mit der Windows-Funktion „Verschieben“. Den auf Laufwerk C verbleibenden Zugang (Junction) löschen Sie nicht.
6. Löschen Sie die auf Laufwerk C verbliebenen Laufzeitumgebungen nicht, solange die App sie verwendet.
7. Beenden Sie die Prüfung nicht mit „Die App startet“, sondern prüfen Sie gespeicherte Einträge, Verlaufsdateien und Browserfunktionen. Prüfen Sie außerdem nach einem Neustart des PCs und nach einem App-Update erneut, bevor Sie über das Löschen der Sicherung entscheiden.

Häufige Fragen

Verschiebt CODEX_HOME auf Laufwerk D alles, was zu ChatGPT gehört?

Nein. Es legt das Stammverzeichnis für die Zustandsdaten von Codex fest. Auf diesem Computer wurde die App selbst separat verschoben; CLI, gemeinsame Laufzeitumgebungen und VS-Code-Erweiterung blieben auf Laufwerk C.

Kann ich die auf Laufwerk C sichtbaren .codex- oder App-Ordner löschen?

In diesem Fall enthält Laufwerk C Zugänge zu Laufwerk D. Auch wenn sie Platz zu belegen scheinen, sind sie nicht zwangsläufig eigenständige Kopien. Das Löschen eines Zugangs unterbricht den Verweis. Auch die von Windows erstellten Verwaltungsverknüpfungen haben wir unverändert belassen.

Kann ich die Sicherung vor der Migration sofort löschen?

Wir haben sie auf diesem Computer aufbewahrt. Geplant ist, mit der neuen Anordnung weiterzuarbeiten, zu passender Gelegenheit nach einem PC-Neustart oder Update zu prüfen und den Benutzer über den Löschzeitpunkt entscheiden zu lassen.

Muss ich die App selbst verschieben, um den Browser zu reparieren?

In diesem Fall funktionierte der Browser wieder, bevor die App selbst auf Laufwerk D verschoben wurde. Es gibt hier keine Grundlage, einen App-Umzug als notwendigen Schritt zur Browserreparatur zu empfehlen.