2026 : comment déployer plus sûrement le bac à sable auto-hébergé d’OpenAI Codex ?

L’architecture officielle distingue deux rôles : OpenAI héberge l’agent harness, tandis que l’executor fonctionne dans l’environnement choisi par l’équipe (documentation d’architecture). La conclusion pratique est claire : le bac à sable auto-hébergé d’OpenAI Codex déplace l’exécution du code, pas le modèle. Avant toute mise en service, séparez les environnements selon les utilisateurs ou les charges de travail, donnez à l’executor des identifiants distincts et gardez les clés API de l’application hors du bac à sable. Si l’objectif est simplement de faire tourner Codex CLI sur une machine distante, vérifiez d’abord qu’il s’agit bien du flux souhaité.

Ce guide s’adresse aux développeurs qui préparent un environnement d’exécution Codex sur un serveur Linux distant et aux petites équipes qui doivent décider où placer code, outils et secrets.
Il convient aussi aux responsables techniques qui comparent un poste local, un conteneur et une machine persistante avant d’autoriser l’accès à des dépôts internes.

Dernière vérification : 2 novembre 2026, à partir de la documentation officielle d’OpenAI sur les environnements autohébergés et la sécurité de Codex.

Distinguer l’executor distant du CLI exécuté sur un serveur

L’Agents API autohébergée et l’exécution de Codex CLI sur une machine distante répondent à des besoins proches, mais ne décrivent pas le même déploiement. Dans le premier cas, l’agent harness orchestre le travail côté service et l’executor reçoit des commandes dans l’environnement de l’équipe. Dans le second, l’équipe lance le CLI dans une session ou un service qu’elle administre. Mélanger ces parcours conduit à appliquer de mauvaises consignes de connexion, de secrets ou de cycle de vie.

Avant de choisir, formulez une phrase qui décrit l’objectif : « l’agent doit envoyer des tâches à un executor dans un environnement contrôlé » ou « un utilisateur veut lancer Codex CLI depuis un serveur distant ». Si l’équipe ne peut pas préciser ce point, elle n’est pas prête à ouvrir un accès de production. Le guide officiel des environnements autohébergés décrit le premier parcours ; il ne faut pas transposer ses paramètres à un lancement autonome du CLI.

Cette distinction change également le périmètre de sécurité. Un serveur distant ne devient pas une frontière d’isolation simplement parce qu’il est éloigné du poste de travail. Les comptes système, les permissions sur les dépôts, les processus voisins, les fichiers temporaires et les secrets accessibles restent à définir.

Avant l’installation, fixer les frontières d’accès

Commencez par inventorier les utilisateurs, les dépôts et les outils que l’executor pourra atteindre. La documentation de sécurité indique qu’un environnement d’exécution partagé peut exposer des fichiers, des identifiants et des ressources à plusieurs agents qui s’y exécutent. Il est donc risqué de regrouper des projets sans rapport dans un même espace, en supposant que leurs contextes resteront séparés.

Pour chaque charge de travail, consignez les réponses à ces questions :

• Le dépôt contient-il du code propriétaire, des données personnelles ou des fichiers de production ?
• L’executor doit-il modifier des fichiers, lancer des tests, installer des dépendances ou accéder à des services internes ?
• Quels outils locaux, y compris les serveurs MCP éventuels, sont indispensables et lesquels sont simplement disponibles sur la machine ?
• Une modification de code peut-elle être appliquée sans revue humaine, ou faut-il soumettre certains changements à une approbation ?
• Les journaux peuvent-ils contenir des extraits de code, des chemins locaux ou des messages révélant des informations sensibles ?

La documentation officielle sur la sécurité des environnements et l’article d’OpenAI sur les pratiques de sécurité de Codex servent de références pour définir les règles d’isolation, d’approbation et d’audit. Ce ne sont pas des garanties automatiques apportées par le simple fait de lancer un executor : l’équipe doit configurer et contrôler son environnement.

Le serveur distant est pertinent lorsque l’équipe sait qui l’administre et comment elle révoque un accès. Pour un essai sans exigences de disponibilité, un conteneur ou un poste isolé peut réduire la charge d’exploitation. Pour une tâche qui doit rester disponible, il faut toutefois définir qui met à jour l’environnement et qui intervient en cas de perte de connexion.

Préparer l’environnement et les dépendances

Choisissez d’abord le système dans lequel l’executor va réellement fonctionner. La documentation officielle permet de considérer un poste, un conteneur ou un bac à sable distant, mais ne transforme pas chaque configuration en modèle de production universel. Un conteneur peut faciliter la reproduction des dépendances ; une machine distante peut convenir aux tâches persistantes ; un poste peut suffire à un essai limité. Dans les trois cas, la frontière de sécurité doit être décrite indépendamment du support.

Ensuite, définissez un répertoire de travail dédié. Évitez de donner à l’executor accès à tout le répertoire personnel d’un compte. Montez seulement le dépôt et les ressources nécessaires, avec les droits de lecture ou d’écriture utiles à la tâche. Si les dépendances sont installées à la volée, déterminez si les modifications doivent survivre à la tâche ou être éliminées lors de la reconstruction de l’environnement.

Pour installer Codex CLI et préparer l’executor, vérifiez la procédure, les prérequis et les versions dans les instructions d’installation du CLI et la documentation de configuration au moment du déploiement. Les commandes copiées d’un exemple peuvent évoluer ; elles ne constituent pas, à elles seules, une politique de mise à jour ou une configuration de production. Notez la version installée, l’origine des paquets et la personne responsable des mises à niveau.

La préparation gagne à distinguer trois catégories :

• Code et données de travail : dépôt, artefacts générés, fichiers temporaires et résultats à conserver.
• Outils et dépendances : exécutables, bibliothèques, gestionnaires de paquets et outils autorisés.
• Secrets : identifiants de connexion de l’executor et autres clés éventuelles, qui ne doivent pas être traités comme des fichiers de projet.

La documentation des fichiers et des artefacts permet de vérifier comment les éléments produits ou échangés avec l’environnement sont gérés. Avant de charger un dépôt sensible, vérifiez quels fichiers sont accessibles au processus et où les résultats seront conservés. Une archive générée peut contenir des données qu’un simple journal d’exécution ne révèle pas.

Configurer la connexion sortante et séparer les clés

Le guide de déploiement décrit une connexion WebSocket sortante pour relier l’executor au service. La conséquence pratique est de vérifier les règles de sortie du réseau, puis d’autoriser les destinations et le protocole mentionnés par la documentation officielle en vigueur. N’ouvrez pas un port entrant « au cas où » : un exemple de commande ne suffit pas à justifier une règle de pare-feu, et la configuration peut évoluer.

Avant de lancer l’executor, relevez dans les documents officiels :

• le processus d’enregistrement de l’environnement ;
• les paramètres de connexion exigés par l’executor ;
• les destinations réseau à autoriser ;
• les permissions associées à chaque identifiant ;
• le comportement attendu en cas d’interruption ou de reconnexion.

La clé destinée à l’environnement ne remplace pas la clé API de l’application. La première sert au flux de l’executor tel qu’il est décrit par la documentation ; la seconde peut autoriser des appels ou des opérations propres à l’application. Conservez-les dans des emplacements séparés et ne copiez pas une clé d’application dans une variable ou un fichier simplement parce que l’executor s’exécute sur la même machine.

Pour limiter les conséquences d’une fuite, créez des identifiants distincts par environnement lorsque le flux le permet, choisissez les permissions minimales disponibles et prévoyez leur révocation. Ne placez pas les valeurs dans le dépôt, l’image du conteneur, un script conservé sans protection ou les journaux. Si un secret a été exposé, supprimez ou révoquez-le d’abord ; ne vous contentez pas d’effacer la ligne du fichier où il apparaissait.

Vérifier le déploiement avant d’ouvrir un dépôt sensible

Le test doit confirmer le chemin d’exécution, pas seulement le démarrage du processus. Utilisez un dépôt non sensible, sans identifiants de production, et vérifiez que l’environnement apparaît comme connecté selon les événements d’état prévus par le flux officiel. La documentation du cycle de vie des environnements aide à interpréter les états et les transitions attendus.

• [ ] Confirmer que l’executor a été enregistré avec les paramètres de l’environnement concerné.
• [ ] Vérifier l’état de connexion dans le flux officiel, puis conserver le résultat du contrôle sans y inclure de secret.
• [ ] Lancer une tâche inoffensive dans un dépôt de test et vérifier le répertoire de travail utilisé.
• [ ] Contrôler les droits effectifs : fichiers visibles, possibilité d’écriture et commandes autorisées.
• [ ] Tester le comportement réseau avec une règle limitée, puis confirmer que l’accès inutile est refusé.
• [ ] Observer les journaux et supprimer toute trace contenant une valeur confidentielle.
• [ ] Simuler une interruption et vérifier la procédure de reconnexion avant un usage régulier.

Si la connexion échoue, vérifiez dans cet ordre l’état d’enregistrement, les paramètres de l’executor, les règles de sortie du pare-feu et les journaux locaux. Comparez les valeurs avec la documentation actuelle ; évitez d’ouvrir largement le réseau pour faire disparaître une erreur sans en identifier la cause. Une connexion réussie prouve que le chemin de déploiement fonctionne. Elle ne prouve ni que le code est sûr, ni que les permissions sont adaptées, ni que les secrets sont hors de portée.

Le contrôle des fichiers mérite une vérification distincte : examinez ce que l’agent peut lire et écrire, ce qui est renvoyé comme artefact et ce qui reste sur disque après la tâche. Pour les changements importants, définissez une revue avant fusion ou déploiement. Les mécanismes d’approbation et d’audit doivent correspondre au risque du dépôt, plutôt que d’être laissés à la valeur par défaut.

Évaluer la charge et organiser la maintenance

Ne dimensionnez pas le serveur à partir d’une promesse générique de « configuration minimale ». La charge dépend du volume du dépôt, de la compilation des dépendances, des outils exécutés, du nombre de tâches simultanées et de la conservation des journaux. Relevez ces éléments lors d’un essai contrôlé, puis mesurez l’usage réel du processeur, de la mémoire, du stockage et du réseau. Les résultats d’un dépôt léger ne prédisent pas ceux d’un projet qui reconstruit fréquemment ses dépendances.

Un environnement persistant demande aussi une routine d’exploitation. Désignez la personne qui suit les mises à jour de l’executor et des dépendances, vérifie les permissions, renouvelle ou révoque les clés et retire les environnements devenus inutiles. Consultez la documentation de cycle de vie avant d’automatiser la création et la suppression : un environnement oublié peut conserver des fichiers, des accès ou des journaux au-delà de la durée prévue.

Avant d’héberger le processus sur une machine louée, comparez les besoins observés avec les systèmes, le stockage, la bande passante et les modalités d’accès effectivement indiqués sur la page de l’offre. Les caractéristiques d’un serveur ne garantissent pas la compatibilité avec Codex, ni une vitesse d’exécution donnée. Pour un test bref, une machine déjà disponible ou un conteneur local peut être plus simple ; pour des exécutions persistantes et des ressources dédiées, un serveur physique indépendant peut mériter l’évaluation.

FAQ sur le déploiement distant de Codex

Le bac à sable auto-hébergé d’OpenAI Codex est-il la même chose que Codex CLI sur un serveur distant ?

Non. Avec le bac à sable de l’Agents API, l’agent harness est géré par OpenAI et l’executor s’exécute dans l’environnement choisi par l’équipe. Lancer Codex CLI sur une machine distante est une autre manière d’utiliser Codex : elle ne reprend pas automatiquement l’architecture, le cycle de vie ou les contrôles de cet environnement autohébergé.

Faut-il installer Codex exec-server dans un conteneur ou directement sur un serveur distant ?

Les deux approches peuvent convenir : la documentation officielle prévoit un environnement sur un ordinateur, dans un conteneur ou dans un bac à sable distant. Un conteneur aide à formaliser les dépendances et la remise à zéro ; une machine distante peut mieux correspondre à une exécution persistante. Le choix dépend des limites d’isolation, de la maintenance et des accès requis.

Quelles connexions sortantes faut-il autoriser pour l’executor Codex ?

Le guide officiel décrit une connexion WebSocket sortante entre l’executor et le service concerné. Il faut reprendre les destinations et exigences de transport indiquées par la documentation au moment du déploiement, puis les autoriser explicitement dans le pare-feu de sortie. N’ouvrez pas un port entrant par supposition : vérifiez d’abord le flux réellement demandé.

Comment distinguer la clé de l’environnement de la clé API utilisée par l’application ?

La clé nécessaire à l’enregistrement ou à la connexion de l’executor ne doit pas être confondue avec une clé API d’application. Créez et stockez séparément les secrets prévus pour ces usages, limitez leurs permissions lorsque l’interface le permet et gardez la clé applicative hors de l’environnement d’exécution. Évitez de l’inscrire dans le dépôt, l’image ou les journaux.

Pour un environnement éphémère ou une charge légère, un poste ou un conteneur peut rester le choix le plus simple. À l’inverse, un VPS partagé peut exposer l’équipe à la concurrence sur les ressources, à un processeur suralloué ou à des règles de facturation réseau difficiles à prévoir ; il n’offre pas toujours la même liberté de choisir le système et les disques. Un serveur physique indépendant de NodeKVM peut mieux convenir lorsque l’executor doit rester disponible et disposer de ressources dédiées, sans que cela garantisse une compatibilité particulière ni une performance Codex déterminée. Avant de décider, consultez les offres et configurations NodeKVM, puis vérifiez les informations d’assistance et d’accès pour confirmer que le système et le mode de connexion correspondent à votre plan de déploiement.

Questions

1. Q
   Le bac à sable auto-hébergé d’OpenAI Codex est-il la même chose que Codex CLI sur un serveur distant ?

   Non. Avec le bac à sable de l’Agents API, l’agent harness est géré par OpenAI et l’executor s’exécute dans l’environnement choisi par l’équipe. Lancer Codex CLI sur une machine distante est une autre manière d’utiliser Codex : elle ne reprend pas automatiquement l’architecture, le cycle de vie ou les contrôles de cet environnement autohébergé.

2. Q
   Faut-il installer Codex exec-server dans un conteneur ou directement sur un serveur distant ?

   Les deux approches peuvent convenir : la documentation officielle prévoit un environnement sur un ordinateur, dans un conteneur ou dans un bac à sable distant. Un conteneur aide à formaliser les dépendances et la remise à zéro ; une machine distante peut mieux correspondre à une exécution persistante. Le choix dépend des limites d’isolation, de la maintenance et des accès requis.

3. Q
   Quelles connexions sortantes faut-il autoriser pour l’executor Codex ?

   Le guide officiel décrit une connexion WebSocket sortante entre l’executor et le service concerné. Il faut reprendre les destinations et exigences de transport indiquées par la documentation au moment du déploiement, puis les autoriser explicitement dans le pare-feu de sortie. N’ouvrez pas un port entrant par supposition : vérifiez d’abord le flux réellement demandé.

4. Q
   Comment distinguer la clé de l’environnement de la clé API utilisée par l’application ?

   La clé nécessaire à l’enregistrement ou à la connexion de l’executor ne doit pas être confondue avec une clé API d’application. Créez et stockez séparément les secrets prévus pour ces usages, limitez leurs permissions lorsque l’interface le permet et gardez la clé applicative hors de l’environnement d’exécution. Évitez de l’inscrire dans le dépôt, l’image ou les journaux.