Faire cohabiter ChatGPT Desktop, VS Code, Codex CLI et WSL2 sans gaspiller de tokens

J’utilise de plus en plus les agents IA directement dans mes projets de développement et d’administration système.

Avec le temps, je me suis retrouvé à utiliser trois interfaces différentes, chacune avec son petit intérêt.

Sur le papier, tout ça fonctionne très bien.

Dans la pratique, j’avais un problème assez pénible : mon véritable environnement de développement est dans WSL2 sous Debian, alors que l’application Desktop travaillait encore beaucoup côté Windows.

Résultat, sur certains projets elle pouvait partir dans une petite chorégraphie pas franchement utile :

ChatGPT Desktop
  -> PowerShell
  -> script Python temporaire
  -> wsl.exe
  -> Debian
  -> dépôt Git

Techniquement, ça marchait souvent.

Mais en réalité, je rajoutais une couche d’abstraction entre l’agent et mon dépôt. Et chaque couche en plus veut aussi dire plus de commandes, plus de contexte, plus de tokens consommés et plus d’occasions de se tromper.

Après quelques essais, quelques erreurs et une petite récupération d’historique, voici le montage que j’utilise maintenant.

Le décor

La configuration de base est assez classique :

Windows 11
|
+-- ChatGPT Desktop / Codex
+-- Visual Studio Code
|
+-- WSL2
    |
    +-- Debian
        +-- Git
        +-- Docker
        +-- Node / PHP / Python...
        +-- Mes dépôts Git

Mes vrais projets restent dans Linux :

/home/<user>/projects/

Ce que je veux éviter :

C:\Users\<user>\Documents\mon-projet

avec une deuxième copie ici :

/home/<user>/projects/mon-projet

Un seul dépôt. Un seul Git. Un seul endroit où le code vit vraiment. Un anneau pour les gouverner tous 🧙‍♂️🧙‍♂️🧙‍♂️

Deux mondes Codex à réunifier

Premier point à comprendre : Windows et WSL possèdent naturellement chacun leur environnement Codex.

Sans configuration particulière, on obtient donc quelque chose comme ça :

ChatGPT Desktop Windows
        |
        +-- C:\Users\<user>\.codex

VS Code / Codex sous WSL
        |
        +-- /home/<user>/.codex

Et on se retrouve avec :

• ➡️ deux configurations
• ➡️ deux historiques
• ➡️ deux stockages de sessions
• ➡️ potentiellement deux authentifications
• ➡️ et deux états différents

Codex permet justement de déplacer sa racine de données avec CODEX_HOME. La référence de configuration Codex indique aussi que les bases SQLite peuvent être séparées via CODEX_SQLITE_HOME ou sqlite_home.

C’est la base du montage.

Basculer Desktop côté WSL

C’est probablement le réglage le plus important de tout l’article.

Par défaut, l’agent Windows natif travaille côté Windows et exécute ses commandes avec PowerShell. Dans certains cas, c’est très bien. Dans mon cas, pour des dépôts Linux, c’était surtout une source de détours.

Je voulais surtout supprimer ce détour inutile :

Dans les paramètres de ChatGPT Desktop, je configure donc :

Le choix de l’agent et celui du terminal sont deux choses différentes. L’agent définit où Codex exécute réellement le travail. Le terminal intégré définit surtout ce que l’interface ouvre quand on veut intervenir à la main.

Pointer Desktop vers le vrai dépôt WSL

Dans ChatGPT Desktop, mes projets pointent maintenant directement vers les dépôts Linux.

Depuis Windows, ils sont accessibles avec l’un de ces deux chemins selon les versions et les habitudes :

\\wsl.localhost\Debian\home\<user>\projects\mon-projet

\\wsl$\Debian\home\<user>\projects\mon-projet

Dans le client Desktop, éditez votre projet et ajoutez le dépôt WSL comme dossier primaire :

Le dossier primaire est important : les nouveaux chats démarrent dedans, Codex s’en sert comme point de départ, Git est lu depuis ce dépôt, et les éventuels fichiers AGENTS.md du projet sont retrouvés au bon endroit.

Projet ChatGPT
      |
      +-- \\wsl.localhost\Debian\home\<user>\projects\mon-projet
                                      |
                                      v
                             vrai dépôt Git WSL

Plus besoin de créer un dossier Windows intermédiaire.

Pièces jointes Windows vues depuis WSL

Voici un petit piège sur lequel je suis tombé : quand j’ajoute une capture depuis ChatGPT Desktop, son chemin est transmis au format Windows, par exemple C:\Users\<user>\AppData\Local\Temp\ma-capture.png. Mais l’agent qui travaille dans WSL doit chercher ce fichier sous /mnt/c/Users/<user>/AppData/Local/Temp/ma-capture.png.

Sans cette conversion, Codex peut conclure que la pièce jointe est introuvable alors qu’il regarde simplement le mauvais chemin. Pour rendre ce comportement permanent, j’ajoute donc la consigne dans mon AGENTS.md global :

C:\Users\<windows-user>\.codex\AGENTS.md
/home/<wsl-user>/.codex/AGENTS.md

When the user provides a Windows path such as C:\Users\..., and the agent runs inside WSL,
convert it to the matching /mnt/c/... path before trying to read the file.

If the file is not found there, also check the Codex attachments folders before asking the user
to upload the image again.

Pour que la règle soit prise en compte, lancez une nouvelle conversation ou redémarrez ChatGPT Desktop.

Installer Codex CLI dans Debian

Avant de partager sa configuration et son historique avec Desktop, il faut avoir installé le CLI dans WSL :

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Puis je vérifie que la commande est disponible :

codex --version

On peut ensuite démarrer simplement :

codex

ou reprendre une conversation :

codex resume

Le CLI devient surtout très utile comme outil de diagnostic global quand les interfaces Desktop ou VS Code appliquent leurs propres filtres.

codex doctor --all

Déclarer les variables CODEX

L’étape suivante consiste à faire utiliser le même stockage à ChatGPT Desktop, VS Code et Codex CLI. Deux variables complémentaires entrent en jeu :

CODEX_HOME        -> fichiers de sessions et configuration partagés
CODEX_SQLITE_HOME -> index utilisé pour retrouver et classer les conversations

Je place CODEX_HOME dans le .codex Windows afin que les trois interfaces accèdent aux mêmes fichiers. Par contre, je garde l’index SQLite dans le système de fichiers Linux pour que tous les outils exécutés sous WSL utilisent la même base, sans ralentissement lié au montage Windows.

Je rends ces deux réglages permanents dans ~/.profile, après avoir adapté le chemin bien sûr :

cat >> ~/.profile <<'EOF'

# Shared Codex data with Windows ChatGPT Desktop.
export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex

# Shared SQLite index for Desktop WSL, VS Code and CLI.
export CODEX_SQLITE_HOME="$HOME/.codex/sqlite"
EOF

mkdir -p "$HOME/.codex/sqlite"

On ferme tout — ChatGPT Desktop et VS Code — puis petit redémarrage de WSL depuis PowerShell :

wsl --shutdown

Après ces modifications, on lance une vérification de principe :

echo "$CODEX_HOME"
echo "$CODEX_SQLITE_HOME"
codex resume --all

Voilà, à ce stade, le résultat doit ressembler à ça :

CODEX_HOME commun
C:\Users\<user>\.codex

CODEX_SQLITE_HOME commun
/home/<user>/.codex/sqlite

        Desktop + VS Code + CLI WSL

Fusionner sans écraser l’existant

Voilà, les variables pour organiser la cohabitation sont en place. Maintenant, on va commencer à réfléchir à la fusion. Dans mon cas, j’avais utilisé les deux environnements pendant plusieurs mois, donc avant de toucher quoi que ce soit, première règle : sauvegarder WSL + Windows.

mkdir -p ~/backup-codex
cp -a ~/.codex ~/backup-codex/codex-wsl
cp -a /mnt/c/Users/<windows-user>/.codex \
      ~/backup-codex/codex-windows

Le .codex Windows peut facilement dépasser le Go avec les logs, pièces jointes, visualisations, caches et sessions. N’interrompez pas la commande si elle est un peu longue.

Après sauvegarde, j’ai choisi le .codex Windows comme stockage commun. Avant de réellement copier, je conseille de faire un dry-run.

rsync -rtvn --ignore-existing \
  ~/backup-codex/codex-wsl/sessions/ \
  /mnt/c/Users/<windows-user>/.codex/sessions/

Et seulement ensuite on ajoute les anciennes sessions WSL sans écraser les sessions existantes :

rsync -rtv --ignore-existing \
  ~/backup-codex/codex-wsl/sessions/ \
  /mnt/c/Users/<windows-user>/.codex/sessions/

Reconstruire proprement l’index SQLite

On a bien copié les fichiers de sessions, mais il reste à reconstruire l’index SQLite, qui n’est pas mis à jour automatiquement. Pour le constater, vous pouvez lancer :

codex doctor --all

Cette commande va clairement afficher l’état actuel. Voici mon exemple :

rollout DB active files        108
rollout DB active rows          66
rollout DB missing active rows  42

Traduction : les 42 fichiers copiés existaient physiquement, mais ils ne sont tout simplement pas indexés dans la base SQLite WSL.

Avant de lancer la reconstruction, on ferme bien tous les clients possibles : Desktop, VS Code et Codex CLI.

Ensuite, sauvegardez l’ancien SQLite et préparez un répertoire vierge pour la reconstruction :

mv ~/.codex/sqlite ~/.codex/sqlite.before-reindex
mkdir -p ~/.codex/sqlite

On commence par une première vérification :

codex doctor --all

Il nous indique alors logiquement que la base est absente ou incomplète. On lance donc une première fois :

codex

Codex peut alors recréer son état à partir des fichiers de sessions disponibles fraîchement copiés.

Une nouvelle vérification :

codex doctor --all

Et là, on doit arriver à quelque chose du genre :

rollout DB active files         108
rollout DB active rows          108
rollout DB missing active rows    0

Là, c’est bon.

Tester réellement la synchronisation

Pour vérifier la configuration, pas besoin d’un script compliqué :

Donc, dans VS Code, on crée une nouvelle conversation avec, par exemple :

TEST SYNC VSCODE

Puis dans WSL :

codex resume --all

La conversation doit apparaître.

Faites ensuite l’inverse depuis ChatGPT Desktop :

TEST SYNC DESKTOP

Puis vérifiez depuis le CLI et VS Code.

C’est beaucoup plus parlant qu’une dizaine de commandes de diagnostic.

Ce que je retiens

Le plus gros changement n’est finalement pas technique.

Il consiste simplement à décider où se trouve la source de vérité.

Dans mon cas :

WSL Debian = environnement de développement
VS Code    = éditeur
Desktop    = interface confortable et organisation
CLI        = accès direct et dépannage

Une fois cette règle posée, tout devient plus logique.

L’application Desktop n’a aucune raison de recréer un environnement Windows, de générer des scripts PowerShell intermédiaires ou de manipuler des copies du dépôt.

Elle peut garder son interface Windows tout en faisant travailler son agent directement dans WSL.

Et c’était exactement ce que je cherchais.

Je conserve donc les trois interfaces parce qu’elles ne répondent pas exactement au même besoin.

Mais derrière, il n’y a désormais qu’un seul environnement de travail réel.