Déplacer ChatGPT et Codex vers un autre lecteur

Nous avons examiné où ChatGPT et Codex stockent leurs fichiers, placé l’application et ses principales données sur le lecteur D, et conservé environ 3.78Go d’environnements d’exécution actifs et d’autres fichiers sur le lecteur C. Les fichiers à examiner se répartissent en trois groupes : application, données enregistrées et environnements d’exécution.

Trois grands groupes de fichiers

« Déplacer tout ce qui concerne ChatGPT sur le lecteur D » recouvrait finalement trop de choses. Les fichiers qui exécutent l’application sont distincts de ceux qui stockent les conversations et les réglages. La CLI, Python, Node et les autres composants appelés par l’application étaient également installés à différents endroits.

La spécification des variables d’environnement d’OpenAI indique que CODEX_HOME définit la racine de la configuration, de l’authentification, des journaux, sessions, skills et états associés. Le répertoire doit déjà exister. Ce réglage ne déplace pas ensemble l’application, AppData de Windows et tous les environnements d’exécution liés.

Conserver les sessions locales de Codex ne revient pas non plus à exporter tout l’historique de conversations d’un compte ChatGPT dans le cloud. Nous ne considérons pas cette sauvegarde comme un export complet de toutes les données ChatGPT.

Ce qui était déjà sur D et ce qui a changé

Au début de l’enquête, les données réelles du répertoire principal de Codex étaient déjà sur D. Sur C, %USERPROFILE%\.codex était une jonction pointant vers CodexHome sur D. Cette opération n’a donc pas initialement transféré environ 65Go de données du répertoire principal de C vers D : elles étaient déjà sur D.

Une jonction fait d’un dossier un point d’entrée vers un autre. Microsoft explique qu’elle peut cibler un autre volume local du même ordinateur. Voir des fichiers par une entrée sur C ne signifie pas nécessairement qu’une seconde copie y est stockée. Explication de Microsoft sur les jonctions

Cette distinction comptait aussi pour le problème de navigateur. Le navigateur intégré et l’intégration Chrome ont refonctionné après l’indication du chemin réel, la fermeture complète de l’application et son redémarrage. Nous n’avons toutefois pas mesuré séparément les effets du chemin et du redémarrage. Notre cas de récupération du navigateur décrit les états avant et après, ainsi que les vérifications réalisées.

Sauvegarde d’environ 68.6Go avec les applications arrêtées

Avant de modifier le démarrage, nous avons sauvegardé les données avec ChatGPT, Codex et les composants Codex de l’IDE arrêtés. Nous avons copié le répertoire principal, la véritable zone de stockage du paquet et le dossier OpenAI de l’emplacement habituel de Local AppData. La sauvegarde a été conservée sur C, pas sur le lecteur de destination.

Le tableau présente la taille logique de la sauvegarde faite sur cet ordinateur. Un Go correspond à un milliard d’octets. Les quelque 68.6Go représentent la sauvegarde conservée sur C, pas l’espace libéré sur C.

Seuls l’utilisateur et SYSTEM peuvent accéder à la sauvegarde. Elle n’est pas jointe à cet article, car elle contient des fichiers d’authentification et des conversations privées.

Essai de CODEX_HOME, puis vérification du démarrage normal

Le répertoire principal étant déjà sur D, nous avons d’abord essayé un seul lancement avec CODEX_HOME=D:\CodexHome défini. Nous avons gardé la même version, fermé complètement l’application et lancé une nouvelle instance.

Seule la variable CODEX_HOME de l’utilisateur a changé. Nous n’avons modifié ni les variables de la machine ni PATH. Windows distingue les portées processus, utilisateur et machine ; nous avons donc vérifié l’application lancée normalement, sans nous arrêter à la valeur affichée dans un shell. Explication de Microsoft sur les variables d’environnement

Commandes en lecture seule pour vérifier l’emplacement

Le PowerShell ci-dessous lit uniquement des valeurs. La première ligne affiche celle du shell ; les deuxième et troisième, les réglages conservés par Windows ; la dernière, l’entrée du répertoire principal par défaut. Une valeur peut être vide : cela ne prouve pas à lui seul une perte de données.

$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

Aucune commande de déplacement ni de suppression n’est incluse. Les données étaient déjà sur D au début du test : ce n’est pas la même chose que de cibler un dossier vide. Avant d’appliquer cette méthode ailleurs, déterminez quoi copier, quelles applications arrêter et où restaurer les données.

Déplacer l’application avec la fonction de Windows

Après les vérifications du répertoire principal et la récupération du navigateur, l’opérateur a choisi « Déplacer » pour ChatGPT dans la liste des applications Windows, vers D. Les destinations étaient WindowsApps et WpSystem, gérées par Windows. Explication de Microsoft sur le stockage des paquets

Nous avons vérifié l’événement de déplacement réussi, la signature valide de l’exécutable sur D (OpenAI OpCo) et le lien sur C. Les dossiers correspondants des données avaient aussi les mêmes identifiants de périphérique et de fichier.

Un emplacement affiché ne suffit pas à prouver un déplacement réussi ni un stockage en double. Nous avons vérifié ensemble les emplacements réels, les cibles des liens et les opérations de base. Nous n’avons modifié ni les entrées ni les autorisations gérées par Windows.

Pourquoi environ 3.78Go sont restés sur C

Même après le déplacement des principaux composants, des données actives restaient sur C. Le tableau résume les zones identifiées, sans compter deux fois les entrées qui pointent vers D.

Ce total est la taille logique des dossiers identifiés. Il ne recense pas exhaustivement les caches de mise à jour, points de restauration ni tout ce que chaque navigateur et éditeur enregistre sur C.

Les environnements conservés sur C fonctionnent sans copie équivalente sur D, puisque l’application utilise les fichiers actuels sur C. Les supprimer en croyant qu’ils ont été déplacés pourrait empêcher la CLI ou la commande du navigateur de fonctionner. La configuration finale utilise C et D.

Nous avons aussi examiné la variable officielle CODEX_INSTALL_DIR, mais elle change l’emplacement de l’installateur de la CLI autonome. Elle ne déplace pas tous les composants CLI et environnements partagés gérés par l’application. Installer une CLI supplémentaire sur D ne prouve pas que les fichiers existants sur C sont devenus inutiles.

Nous avons également examiné le processus de mise à jour de cette version sans le modifier et testé le remplacement avec de petits dossiers factices. Dans une configuration, transformer le dossier mis à jour en lien vers D entraînait la mise de côté du lien en tant qu’ancienne version, tandis qu’un nouveau dossier ordinaire était créé sur C. Ce test portait uniquement sur le remplacement de fichiers, pas sur la migration de l’application réelle.

Nous avons choisi de ne pas ajouter d’emplacements non officiels et de contrôles après chaque mise à jour seulement pour déplacer environ 3Go d’environnements. Nous avons comparé l’intérêt de placer l’application et ses données sur D à l’espace restant sur C et gardé les composants qui fonctionnaient normalement.

Vérifications après la migration

Nous ne nous sommes pas arrêtés à « l’application démarre ». Les valeurs enregistrées ont été comparées à la sauvegarde. Les éléments vérifiés correspondaient : 2 chats épinglés, 18 projets épinglés, 63 projets locaux, 43 entrées d’ordre des projets et 58 associations de chats à des projets. Nous avons comparé leurs valeurs complètes, pas seulement leurs nombres.

Tous les fichiers correspondants de la sauvegarde étaient présents et lisibles dans l’historique et les éléments liés : 459 dans sessions, 39 dans archived_sessions, 4 dans attachments et 3 dans automations. Il y avait 0 fichier manquant et 0 erreur de lecture. Ce contrôle portait sur la présence des fichiers ; il ne signifie pas que chaque conversation ou le contenu intégral de chaque base a de nouveau été haché.

La vérification du statut de connexion de la CLI a réussi. Le navigateur intégré pouvait lire une page publique, cliquer sur un lien et revenir en arrière. Nous avons aussi vérifié lecture et navigation dans un onglet de test Chrome, puis l’avons fermé. Aucun contenu des onglets privés existants n’a été collecté pour l’article.

Nous avons vérifié un redémarrage normal de l’application, mais pas la continuité après le redémarrage du PC lui-même ou une future mise à jour. Ces deux contrôles ont été reportés à un moment convenant à l’utilisateur. Nous n’avons pas ajouté de redémarrage juste pour terminer l’article.

La configuration conservée

La migration a été considérée comme terminée dans ce périmètre : cibler directement le répertoire principal réel sur D, y placer l’application et ses données principales, et garder les environnements sur C. La sauvegarde préalable d’environ 68.6Go reste sur C ; l’utilisateur décidera séparément quand la supprimer.

L’essentiel était de comprendre où se trouve chaque élément, quelle application l’utilise et ce qui reste disponible pour la récupération, plutôt que de réduire à zéro l’usage de C. En particulier, le premier enregistrement d’un lecteur comme stockage d’applications Windows impose un plan d’arrêt couvrant les disques virtuels et projets actifs de ce même lecteur.

Ordre à suivre pour une migration identique

1. Répartissez les éléments à déplacer en trois groupes : le répertoire principal de Codex, l’application et ses principales données, puis les environnements d’exécution comme la CLI. Vérifiez où se trouve actuellement chacun.
2. Arrêtez non seulement ChatGPT et Codex, mais aussi les autres applications qui utilisent le lecteur de destination (par exemple les disques virtuels de Docker) ainsi que les projets en cours.
3. Une fois tout arrêté, faites une sauvegarde, comparez le nombre et la taille des fichiers, et comparez aussi les empreintes des fichiers importants comme les réglages et les fichiers d’authentification. Conservez la sauvegarde sur un autre lecteur que la destination.
4. Testez d’abord CODEX_HOME avec un seul lancement, vérifiez les opérations de base, puis définissez-le dans les variables d’environnement de l’utilisateur.
5. Déplacez l’application elle-même avec la fonction « Déplacer » de Windows. Ne supprimez pas l’entrée (jonction) qui reste sur le lecteur C.
6. Ne supprimez pas les environnements d’exécution restés sur le lecteur C tant que l’application les utilise.
7. Ne vous arrêtez pas à « l’application démarre ». Vérifiez les données enregistrées, les fichiers d’historique et le fonctionnement du navigateur. Refaites ces contrôles après un redémarrage du PC et une mise à jour de l’application, puis décidez si vous supprimez la sauvegarde.

Questions fréquentes

Définir CODEX_HOME sur D y déplace-t-il tout ce qui concerne ChatGPT ?

Non. Il définit la racine où Codex stocke son état. Sur cet ordinateur, l’application a été déplacée séparément, tandis que la CLI, les environnements partagés et l’extension VS Code sont restés sur C.

Puis-je supprimer les dossiers .codex ou de l’application visibles sur C ?

Ici, C contient des points d’entrée vers D. Même s’ils semblent occuper de l’espace, ce ne sont pas nécessairement des copies indépendantes. Supprimer une entrée casse la référence. Nous avons aussi conservé les liens de gestion créés par Windows.

Puis-je supprimer immédiatement la sauvegarde préalable ?

Nous l’avons conservée sur cet ordinateur. Le plan consiste à poursuivre le travail avec la nouvelle organisation, vérifier après un redémarrage ou une mise à jour au moment opportun et laisser l’utilisateur décider quand supprimer la sauvegarde.

Faut-il déplacer l’application uniquement pour réparer le navigateur ?

Ici, le navigateur a refonctionné avant le déplacement de l’application sur D. Ce cas ne justifie pas de recommander ce déplacement comme étape obligatoire de réparation.