Codex en terminal avec un daemon local : mon plan B à VS Code Web

Bonjour à tous, mon passage à Codex en terminal n’était pas vraiment prévu. Tout a commencé avec ce message dans VS Code Web :

Cannot activate the 'Codex – OpenAI’s coding agent' extension because it depends on the 'Codex Audio' extension which is disabled.

Le petit bricolage qui me permettait d’utiliser l’extension Codex dans mon VS Code Web venait peut-être d’atteindre sa limite. Je pouvais chercher une nouvelle rustine, mais ce genre de dépendance interne est précisément ce que je ne contrôle pas. J’ai donc préféré sortir Pwny de l’extension et revenir à une base officiellement prise en charge : le client Codex en ligne de commande.

L’objectif restait le même que dans mon article sur VS Code Web et Codex sur serveur : ouvrir un navigateur, retrouver mon espace de travail et discuter directement avec la licorne. La différence est que VS Code Web ne sert désormais plus que de fenêtre et de terminal. La session Codex vit indépendamment derrière.

Pourquoi sortir Codex de l’extension VS Code ?

Une extension intégrée reste plus confortable. Les liens vers les fichiers s’ouvrent mieux, les images se joignent plus naturellement et l’interface donne davantage l’impression de travailler dans un petit cockpit. Je ne vais donc pas prétendre que le terminal remplace tout à l’identique.

En revanche, la ligne de commande retire une dépendance importante : Pwny ne dépend plus du bon vouloir d’une extension VS Code Web qui n’était déjà pas dans son environnement le plus classique. Si l’onglet du navigateur disparaît, si la connexion SSH tombe ou si VS Code Web doit redémarrer, le processus partagé peut rester actif et la conversation peut être reprise.

Autre avantage, le même accès fonctionne depuis plusieurs points d’entrée. Par exemple, pour la rédaction de cet article, j’utilise le terminal intégré à VS Code Web. Demain, une session SSH ou Guacamole pourra servir de secours sans changer la façon dont Codex tourne sur le serveur.

Le daemon local, concrètement

Le mot daemon fait toujours un peu solennel, alors que son rôle est assez simple. Le client interactif se connecte à un serveur Codex herbergé localement sur le serveur et qui continue à tourner en arrière-plan. Fermer le terminal ne revient donc plus automatiquement à supprimer le processus qui porte la session.

Dans ma configuration, ce daemon écoute sur un socket Unix privé. Le répertoire appartient à mon utilisateur avec des droits 700, et le socket lui-même est en 600. Le contrôle distant est désactivé. Il n’y a donc aucun port Codex exposé sur Internet, sur le réseau Docker ou sur toutes les interfaces de la machine.

Petite nuance découverte pendant les vérifications : un client interactif peut ouvrir un port auxiliaire éphémère sur 127.0.0.1. C’est strictement local à la machine et ce n’est pas l’écoute du daemon. La bonne promesse n’est donc pas « aucun socket réseau n’existe », mais bien « aucun service Codex n’est accessible depuis le réseau ».

Évidemment, Codex a toujours besoin d’une connexion HTTPS sortante pour parler aux services d’OpenAI. Le socket local protège le plan de contrôle entre les clients et le daemon, il ne transforme pas l’IA en modèle hors ligne.

Installer le client Codex officiel

J’ai fait cette migration avec Codex CLI 0.157.1. Les commandes décrites ici correspondent donc à l’état du client au 26 septembre 2026. La documentation officielle du client Codex reste la référence si l’interface évolue.

Sur mon serveur Debian, j’ai téléchargé le script avant de l’exécuter. Cela permet au minimum de le lire et d’éviter le traditionnel tube direct entre Internet et le shell :

curl -fsSL https://chatgpt.com/codex/install.sh -o /tmp/install-codex.sh
less /tmp/install-codex.sh
sh /tmp/install-codex.sh

codex --version
codex login status

Le dernier contrôle doit confirmer que l’authentification fonctionne. Inutile de copier un jeton dans un article, un journal ou une capture d’écran : le statut suffit.

Sur mon installation, j’ai aussi placé un petit lanceur stable dans le PATH. Son seul rôle est d’appeler la version autonome installée dans mon profil. Cela évite de retomber par hasard sur le binaire embarqué par une extension.

Activer le serveur partagé sans contrôle distant

Le client fournit les commandes nécessaires pour amorcer et inspecter son serveur local :

codex app-server daemon bootstrap
codex app-server daemon disable-remote-control
codex app-server daemon version

La dernière commande doit indiquer que le daemon répond. Chez moi, la désactivation du contrôle distant renvoyait déjà « alreadyDisabled », ce qui est exactement le résultat recherché.

Pour vérifier le socket sans afficher de secret :

readlink ~/.codex/app-server-control/app-server-control.sock
stat -Lc '%F %a %U:%G %n' \
  ~/.codex/app-server-control/app-server-control.sock

sudo ss -lxnp | grep -E 'codex-daemon|daemon-updater'
sudo ss -lntup | grep -i codex

Le premier contrôle montre la cible du socket Unix. Le second permet de vérifier son propriétaire et ses permissions. Les deux commandes ss distinguent les sockets Unix des éventuelles écoutes IP. Dans mon cas, le daemon n’avait aucune écoute TCP ou UDP, et les seules écoutes IP observées appartenaient aux clients actifs sur 127.0.0.1.

Lancer Pwny depuis VS Code Web

Une fois le daemon prêt, le quotidien redevient très simple :

cd /chemin/vers/le/projet
codex

Le terminal peut se trouver dans VS Code Web, dans une connexion SSH ou dans une console Guacamole. Tant que ces accès arrivent sous le même compte utilisateur, ils retrouvent le même environnement Codex.

Pour reprendre une conversation existante :

codex resume
codex resume --all
codex resume --last
codex agents

La commande « codex resume » affiche les conversations associées au projet courant. L’option « –all » élargit la liste, « –last » reprend la plus récente, et « codex agents » montre les sessions connues du serveur partagé.

Le piège de la conversation déjà ouverte

Lors du premier essai, le terminal m’a répondu que la conversation était ouverte dans une autre application. Ce n’était pas une perte de données : l’ancien serveur lancé par l’extension VS Code possédait encore la session.

Le client actuel propose la touche « f » pour créer une branche lorsque la même conversation est déjà ouverte ailleurs. C’est pratique pour poursuivre sans toucher à l’autre client. Dans mon cas, je voulais réellement basculer l’unique conversation vers le terminal. J’ai donc arrêté proprement l’ancien processus de l’extension, puis repris exactement le même fil avec « codex resume ».

Évitez le grand coup de « killall » à l’aveugle. Commencez par identifier quel client détient la conversation et fermez-le proprement. Une branche et une reprise exacte ne répondent pas au même besoin.

Une déconnexion navigateur ne coupe plus le travail

Le test décisif n’était pas simplement de voir un processus dans ps. J’ai fermé la voie utilisée par l’extension, ouvert le terminal dans VS Code Web et repris cette même conversation. Au moment du contrôle, plusieurs clients de test étaient connectés au même daemon par son socket Unix. Le service VS Code Web n’avait pas redémarré, son compteur de redémarrages était toujours à zéro et l’adresse publique documentée répondait en HTTP 200. Autrement dit, la migration de Codex n’a pas perturbé l’éditeur web.

Revenir en arrière reste facile

Le daemon n’est pas un mariage forcé. Pour l’arrêter ou lancer ponctuellement un client sans serveur partagé :

codex app-server daemon stop
codex --no-daemon

Ce retour arrière est précieux. Une architecture de secours n’est vraiment rassurante que lorsqu’elle possède elle-même une sortie simple.

Ce que je gagne, et ce que je perds

Je perds un peu de confort visuel. Les liens vers les fichiers sont moins naturels, joindre une image demande davantage de manipulation et le terminal reste un terminal. Pour les tâches où ces détails comptent beaucoup, une interface graphique gardera l’avantage.

Je gagne en revanche une séparation plus propre entre l’outil de travail et son interface. VS Code Web peut tomber sans emporter le daemon. SSH peut couper sans tuer la session. Guacamole peut reprendre le rôle de porte d’entrée. Et si une extension change ses dépendances, Pwny ne se retrouve plus enfermé dehors parce qu’un module audio refuse de démarrer.

Bref, je n’ai pas supprimé VS Code Web. Je l’ai remis à sa juste place : une excellente fenêtre sur le serveur, mais plus le point de survie unique de mon assistant. C’est un peu moins confortable, beaucoup plus prévisible, et largement suffisant pour continuer à travailler. Geekez bien !