Codex CLI : installation, permissions, AGENTS.md et coûts

Codex CLI est l’agent de code d’OpenAI utilisable depuis un terminal : il peut examiner un projet, modifier ses fichiers et exécuter des vérifications selon les permissions accordées. Pour l’utiliser correctement, il faut distinguer l’installation du logiciel, l’accès au modèle, les limites techniques du bac à sable et les règles d’approbation. Ce guide couvre ces réglages, le fichier AGENTS.md et les coûts, avec des sources officielles consultées le 24 octobre 2026.

Ce que vous installez et ce que vous déléguez

Une session de Codex CLI peut servir à comprendre une fonction, préparer une correction ou rechercher une régression. L’intérêt du terminal est de travailler au contact du projet et de ses outils habituels. Cela suppose cependant de savoir reconnaître une commande adaptée, lire une différence de fichiers et interpréter un résultat de test.

Le logiciel installé et le service qui fournit le modèle sont des éléments distincts. La licence du client ne détermine donc ni votre consommation ni les droits de traitement de vos données. Le dépôt officiel publie le client sous licence Apache-2.0 et documente ses méthodes d’installation.

Pour décider quoi déléguer, partez d’un résultat observable : corriger un comportement décrit, expliquer une dépendance ou ajouter un contrôle précis. Une demande générale d’amélioration laisse davantage de place aux changements inutiles et rend la relecture difficile.

Ce guide convient aux personnes capables de reprendre le travail si une commande échoue. Pour situer cette méthode parmi les autres approches, l’article sur le fonctionnement des agents de code présente leur boucle de travail. Notre annuaire des agents IA permet ensuite de consulter leurs fiches.

Prérequis : préparer le projet avant la session

Préparez un terminal fonctionnel, un accès au service de modèles choisi et une copie de travail dont vous connaissez l’état. Si vous retenez une installation par gestionnaire de paquets, celui-ci doit déjà être disponible. Les commandes ci-dessous sont des options alternatives : choisissez une méthode d’installation.

Avant de démarrer :

identifiez le dossier exact à examiner ;
sauvegardez les modifications existantes et repérez les fichiers non suivis ;
vérifiez comment le projet se construit et se teste ;
retirez les secrets inutiles de l’environnement de travail ;
définissez les opérations qui nécessitent votre accord.

Un état initial propre facilite l’attribution des changements. Si plusieurs personnes ou outils modifient les mêmes fichiers, prévoyez un espace de travail séparé. Vous éviterez de demander ensuite à l’agent de distinguer ses modifications de celles d’un collègue.

Préparez aussi un exemple du résultat attendu. Pour un défaut d’affichage, décrivez le comportement visible ; pour un traitement de données, fournissez un exemple anonymisé. Un critère de réussite concret vaut mieux qu’une longue description d’intention.

Enfin, un test peut lui-même écrire des fichiers, contacter un service ou utiliser des identifiants présents dans l’environnement. Examinez les scripts du projet avant de les confier à un agent, surtout si le dépôt provient d’une source inconnue.

1. Installer Codex CLI avec une méthode officielle

Le démarrage officiel propose un installateur autonome pour macOS et Linux. La commande suivante, vérifiée dans la documentation de Codex CLI, télécharge puis exécute le script d’installation :

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

Sous Windows, le dépôt officiel donne cette commande PowerShell :

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

Si vous utilisez déjà npm ou Homebrew, le même dépôt documente ces alternatives :

npm install -g @openai/codex

brew install --cask codex

Choisissez la méthode compatible avec la politique de votre machine. Sur un poste administré, faites appliquer le circuit de distribution prévu par l’organisation. Évitez de superposer plusieurs installations : un ancien exécutable peut rester prioritaire dans le chemin de recherche du terminal.

Pour mettre à jour une installation autonome sur macOS ou Linux, la documentation indique de relancer le même installateur. Avant une mise à jour collective, conservez la configuration utilisée et vérifiez le comportement sur un projet sans données sensibles.

Il n’est pas nécessaire de figer ici une version pour suivre la démarche. Pour documenter un incident, relevez toutefois la version effectivement installée : une option présente dans la documentation courante peut manquer dans un client ancien.

2. Choisir l’authentification et son budget

Vous pouvez démarrer la connexion interactive avec :

codex login

La documentation d’authentification distingue l’accès par compte ChatGPT de l’accès par clé API. Le premier suit les droits du compte ou de l’espace de travail ; le second suit ceux de l’organisation API.

Pour une clé déjà fournie à la variable d’environnement attendue, la commande officielle est :

printenv OPENAI_API_KEY | codex login --with-api-key

Cet exemple suppose un shell disposant de printenv. Ne remplacez pas la variable par une clé écrite en clair dans une commande partagée. Préférez le mécanisme de gestion des secrets de votre environnement.

Pour contrôler la méthode active :

codex login status

Sur une machine sans navigateur, l’authentification par code d’appareil est documentée en bêta, sous réserve de son activation dans les réglages du compte ou de l’espace :

codex login --device-auth

Les identifiants peuvent être conservés dans un fichier local ou dans le coffre du système. Traitez tout cache d’authentification comme un secret.

Avant une tâche coûteuse, vérifiez donc le compte actif et l’enveloppe utilisée. Une connexion réussie ne prouve pas que vous consommez le budget prévu par votre équipe.

3. Séparer approbation et bac à sable

Le bac à sable définit une limite technique : fichiers accessibles, écritures possibles et accès réseau des commandes. L’approbation détermine quand une action doit être soumise à validation. Une consigne rédigée dans la conversation constitue encore une autre couche.

Au 24 octobre 2026, la documentation du sandbox décrit les modes historiques suivants et précise que la politique untrusted n’est plus sélectionnable.

Réglage historique	Inspection	Écriture	Usage conseillé
`read-only`	Consultation du projet	Pas d’édition dans le périmètre ordinaire	Diagnostic initial
`workspace-write`	Lecture des fichiers accessibles	Dans l’espace autorisé	Correction circonscrite
`danger-full-access`	Accès sans restriction du sandbox	Sans frontière du sandbox	Environnement isolé et préparé

Les politiques courantes d’approbation sont on-request et never. Cette dernière supprime les demandes de validation ; elle ne doit pas être interprétée comme un accord éditorial ou métier pour toutes les actions.

Sous Linux et WSL2, la documentation recommande l’installation de bubblewrap. Pour Ubuntu ou Debian :

sudo apt install bubblewrap

Pour Fedora :

sudo dnf install bubblewrap

Appliquez la procédure correspondant à votre système. Si l’isolation échoue, cherchez la cause technique avant d’élargir les permissions.

En pratique, commencez par le moindre privilège : donnez accès au projet utile et augmentez le périmètre seulement lorsqu’une étape identifiée l’exige. La vitesse de travail ne justifie pas à elle seule l’accès à des dossiers personnels ou à des identifiants de production.

4. Démarrer avec des permissions explicites

Les options ci-dessous figurent dans la référence officielle des commandes, consultée le 24 octobre 2026. Depuis le dossier du projet, ce lancement associe inspection et absence de demandes d’escalade :

codex --sandbox read-only --ask-for-approval never

Pour travailler sur une correction dans l’espace autorisé, avec demandes d’approbation lorsque nécessaire :

codex --sandbox workspace-write --ask-for-approval on-request

La référence propose également un examen automatique des approbations éligibles :

codex --approve-for-me

Cette option utilise un sandbox d’écriture dans l’espace de travail. Elle entre en conflit avec certaines options manuelles de sandbox et d’approbation ; ne les empilez pas.

Choisissez le mode selon le travail demandé. Une analyse de code ne nécessite généralement pas les mêmes droits qu’une migration de dépendances. Une publication, un envoi de données ou une modification d’infrastructure mérite une décision distincte de l’autorisation de corriger des fichiers.

L’approbation humaine exige de lire la commande et son contexte. Avant de valider, identifiez le dossier concerné, les destinations réseau et les effets persistants. Si la demande ne permet pas de comprendre ces éléments, faites préciser l’action.

Évitez enfin de transformer une autorisation ponctuelle en permission générale par commodité. Le guide pour sécuriser un agent IA développe cette méthode au-delà du terminal.

Les profils de permissions : une configuration distincte

La documentation actuelle propose aussi des profils de permissions en bêta. Ils comprennent notamment :read-only, :workspace et :danger-full-access, avec une syntaxe différente des anciens modes.

Un choix minimal dans la configuration peut prendre cette forme :

default_permissions = ":read-only"

Ces profils ne se composent pas avec les anciens réglages sandbox_mode et sandbox_workspace_write. La présence de l’ancien réglage ou de l’option de lancement correspondante peut faire utiliser l’ancien système ; une liste de profils imposée par l’administration constitue une exception documentée.

Pour préparer une migration, choisissez explicitement le système retenu. Examinez toutes les couches de configuration chargées, puis vérifiez séparément la lecture, l’écriture et le réseau. Dans un environnement administré, les profils disponibles peuvent être restreints.

La conséquence pratique est simple : recopier un exemple de configuration sans examiner l’existant peut produire un comportement différent de celui attendu. Conservez une configuration courte et expliquez la raison de chaque exception.

Préparez également des vérifications négatives sur des données factices : une tentative d’écriture hors périmètre doit échouer si cette frontière est requise. Ne réalisez pas ce contrôle en demandant une opération dangereuse sur des fichiers réels.

Gardez un relevé des permissions effectives avec vos procédures d’équipe. Ce relevé aide davantage au diagnostic qu’une simple copie des préférences personnelles de la personne qui a installé l’outil.

5. Écrire un AGENTS.md court et vérifiable

AGENTS.md sert à transmettre les conventions de travail du projet. D’après la documentation officielle sur AGENTS.md, Codex combine des instructions globales et celles découvertes entre la racine du projet et le répertoire courant.

Dans chaque dossier, AGENTS.override.md est prioritaire sur AGENTS.md. Les instructions plus proches du répertoire courant viennent après les instructions générales. Après modification, redémarrez la session pour reconstruire la chaîne.

Voici un exemple éditorial à adapter, sans commande de test présumée :

# Règles du projet

## Périmètre
- Limiter les changements à la demande formulée.
- Signaler toute modification nécessaire hors du périmètre prévu.
- Ne pas publier ni déployer sans accord explicite.

## Vérifications
- Lire les scripts du projet avant de lancer les contrôles.
- Exécuter les vérifications pertinentes pour les fichiers modifiés.
- Distinguer les contrôles réussis, échoués et non exécutés.

## Livraison
- Expliquer le comportement corrigé.
- Signaler les limites et les décisions restant à prendre.

Pour examiner les instructions prises en compte, la documentation fournit :

codex --ask-for-approval never "Summarize the current instructions."

Relisez la réponse en la comparant aux fichiers attendus. Cette inspection aide à détecter une surcharge oubliée.

Évitez les règles vagues et les obligations impossibles à appliquer. Indiquez où trouver les procédures plutôt que de recopier toute la documentation. Surtout, une interdiction écrite ne constitue pas une permission technique : protégez aussi les ressources qui ne doivent pas être accessibles.

6. Réaliser une tâche, puis contrôler le résultat

Commencez par une demande dont le périmètre est visible. Par exemple : examiner un échec de validation, proposer une correction limitée et indiquer les contrôles nécessaires. Cette formulation est un exemple de travail, pas un résultat observé.

Procédez ensuite dans cet ordre :

Faire établir le diagnostic. Demandez les fichiers concernés, l’hypothèse retenue et les éléments qui la soutiennent.
Vérifier le périmètre. Confirmez que la correction proposée répond au défaut sans réécriture périphérique.
Autoriser l’édition adaptée. Utilisez les droits nécessaires au changement envisagé.
Examiner les vérifications. Cherchez un contrôle qui aurait détecté le défaut initial.
Relire la différence complète. Incluez les dépendances, configurations et fichiers générés.
Décider de l’intégration. Conservez cette décision après la relecture.

Un contrôle réussi apporte une preuve limitée à ce qu’il couvre. Une suite de tests peut ignorer un problème d’accessibilité, une donnée mal migrée ou une exposition d’informations. Faites correspondre les preuves au risque du changement.

Demandez aussi un compte rendu honnête des vérifications non exécutées. Une installation de dépendances bloquée, un service absent ou un environnement incomplet doit rester visible dans la livraison.

La méthode détaillée pour travailler avec un agent de code aide à découper les demandes. Elle reste applicable lorsque le modèle ou l’interface change.

Coûts : distinguer abonnement, API et travail humain

La tarification officielle, consultée le 24 octobre 2026, affiche notamment l’offre Plus à environ 20 dollars par mois et Pro à partir d’environ 100 dollars par mois. Vérifiez l’éligibilité de votre compte et les fonctionnalités accessibles dans le CLI avant de choisir une formule.

Critère	Connexion ChatGPT	Clé API
Enveloppe	Droits et limites de l’offre	Consommation facturée côté API
Suivi	Tableau d’usage du compte	Suivi de l’organisation API
Vigilance	Crédits et usages partagés	Consommation des tâches automatisées

Les limites dépendent notamment du modèle, de la taille du contexte et de la complexité des tâches. Un message utilisateur ne correspond donc pas à un coût fixe. La commande de session suivante permet de consulter les limites restantes lorsqu’elles sont disponibles :

/status

Pour votre budget, distinguez la facture du service, l’exécution des outils et le temps de relecture. Mesurez le coût d’une tâche acceptée, avec ses reprises, plutôt que celui d’une première réponse.

Fixez un périmètre avant le lancement et interrompez les explorations qui n’apportent plus de preuve utile. Une demande concise peut toutefois nécessiter beaucoup de travail : surveillez le résultat et la consommation ensemble.

L’article sur le coût réel d’un agent IA élargit cette analyse. Pour une estimation fondée sur des volumes de tokens identifiés, utilisez le calculateur de prix LLM.

Problèmes fréquents

Le terminal ne trouve pas Codex. Vérifiez la méthode d’installation et le chemin des exécutables. Rouvrez le terminal après une modification de cet environnement. Une réinstallation par une autre méthode risque de compliquer le diagnostic.

La connexion fonctionne, mais l’accès attendu manque. Contrôlez la méthode d’authentification, le compte et l’espace actifs. Vérifiez ensuite les droits administratifs et l’offre associée. Ne concluez pas immédiatement à un défaut d’installation.

L’agent peut lire, mais pas corriger. Examinez les permissions effectives et le répertoire de travail. Si l’objectif est seulement d’inspecter, ce comportement peut être conforme. Sinon, accordez l’écriture au périmètre nécessaire.

Les règles semblent ignorées. Recherchez un fichier de surcharge et vérifiez le dossier de lancement. Comparez les instructions effectivement résumées à celles attendues, puis reprenez une session neuve.

Les tests échouent après la correction. Distinguez un défaut introduit d’un problème préexistant ou d’une dépendance absente. Conservez les messages d’erreur utiles et évitez les modifications successives sans hypothèse explicite.

La tâche s’étend sans produire de résultat relisible. Demandez un point d’arrêt : fichiers modifiés, diagnostic acquis, incertitudes restantes. Reprenez avec une demande plus étroite.

Dans chaque cas, changez un réglage à la fois. Vous pourrez ainsi comprendre ce qui a résolu le problème et éviter de conserver des permissions superflues.

Checklist avant de confier un projet réel

Pages liées

Questions fréquentes

Codex CLI fonctionne-t-il sans abonnement ChatGPT ?

Vous pouvez utiliser une clé API OpenAI et payer la consommation correspondante. Cette authentification ne reprend pas les crédits inclus dans un abonnement ChatGPT ; les accès aux fonctionnalités liées au cloud peuvent aussi différer.

Codex CLI est-il entièrement local ?

L’exécution locale des commandes ne signifie pas que le modèle fonctionne sur votre ordinateur. Avec un modèle hébergé, les éléments nécessaires au traitement de la tâche sont transmis au service ; vérifiez les règles applicables à votre compte avant de soumettre du code confidentiel.

AGENTS.md peut-il empêcher une suppression de fichiers ?

Il peut donner une consigne explicite, mais ce fichier ne remplace pas une restriction technique. Pour protéger un dossier, utilisez les permissions adaptées et conservez une sauvegarde indépendante.

Faut-il autoriser toutes les commandes pour éviter les interruptions ?

Un périmètre de travail correctement défini permet déjà de nombreuses actions sans interruption. Élargir tous les droits pour résoudre un blocage ponctuel expose aussi des fichiers et services sans rapport avec la tâche.

Peut-on utiliser Codex CLI dans une chaîne d’intégration continue ?

Oui, la documentation prévoit des usages programmatiques et recommande l’authentification API pour l’automatisation générale. Préparez un environnement isolé, des secrets limités et une validation indépendante avant toute publication.

Codex CLI, guide de référence : installation, modes d'approbation et bac à sable, AGENTS.md, coûts