Codex CLI : réussir ses premiers pas et configurer l’équipe

Réservez les 15 premières minutes à la prise en main, à condition de disposer déjà d’un projet fonctionnel et d’un compte avec les accès nécessaires. L’installation, la connexion ou une suite de tests lente peuvent prendre davantage de temps. Le premier résultat utile sera une petite modification vérifiée, ou une explication précise de ce qui la bloque. Commandes vérifiées le 11 octobre 2026.

Installer Codex CLI et mener une première tâche à bien

Codex travaille dans votre projet : il peut consulter les fichiers, les modifier et lancer les outils installés sur votre machine. Voyez-le comme un contributeur disposant de son propre poste de travail. Vous lui confiez une tâche et en fixez les limites ; la décision d’intégrer le résultat au produit vous appartient. Guide CLI d’OpenAI

De 0 à 3 minutes : choisir une méthode d’installation

Sur macOS ou Linux, voici la commande de l’installateur autonome :

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

Une autre méthode peut mieux convenir à votre environnement. Choisissez-en une seule pour savoir comment effectuer les mises à jour ensuite.

Sous Windows, la documentation donne cette commande exacte, à exécuter dans une nouvelle fenêtre PowerShell : powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex".

Ces méthodes figurent dans la documentation actuelle du CLI et le dépôt officiel. Placez-vous dans le répertoire de votre projet depuis le terminal avant de lancer Codex.

De 3 à 5 minutes : se connecter avec ChatGPT ou une clé API

Pour une première session interactive, privilégiez la connexion avec ChatGPT si votre abonnement et votre espace de travail vous y donnent accès. Lancez codex login, puis suivez la procédure dans le navigateur. Si vous démarrez codex sans être déjà connecté, l’option Sign in with ChatGPT vous est également proposée.

Choisissez l’authentification par clé API lorsque vous souhaitez utiliser votre compte OpenAI Platform, par exemple pour des workflows pilotés par programme. Si OPENAI_API_KEY est déjà définie dans l’environnement de votre shell, la commande documentée pour macOS/Linux est printenv OPENAI_API_KEY | codex login --with-api-key. Ne placez pas la clé dans les fichiers du dépôt.

Lancez codex login status pour vérifier la méthode active. Ce point compte en équipe : l’authentification ChatGPT applique les contrôles de l’espace de travail ChatGPT, tandis que l’authentification API applique ceux de l’organisation API. Guide d’authentification

Coût : la connexion avec ChatGPT utilise les accès inclus dans votre abonnement éligible ; l’utilisation d’une clé API est facturée séparément par OpenAI Platform, aux tarifs de l’API. Notre guide des tarifs de Codex compare les abonnements. Pour un essai en équipe, comparez le temps nécessaire à une tâche réalisée manuellement au temps consacré aux prompts, à la revue et aux corrections. Déduisez ensuite le coût d’utilisation supplémentaire de la valeur du temps réellement gagné. Obtenir un premier jet plus vite n’est rentable que si l’effort total nécessaire pour le valider diminue. Distinction entre authentification et facturation chez OpenAI

De 5 à 8 minutes : examiner le projet avant de le modifier

Créez d’abord un point de sauvegarde Git. Depuis le shell, dans votre projet, ouvrez une session d’inspection avec la commande documentée codex --sandbox read-only --ask-for-approval on-request.

Confiez-lui une recherche bien délimitée. Vous pouvez par exemple adapter ce prompt à votre projet :

Ce prompt est une suggestion de méthode de travail, pas une commande particulière de Codex. Lisez la réponse et vérifiez que l’outil a repéré la bonne partie de l’application. Le bac à sable en lecture seule autorise l’inspection et l’exécution de commandes dans son périmètre ; les actions qui en sortent peuvent nécessiter une approbation. Guide des approbations et du bac à sable

De 8 à 12 minutes : autoriser une petite modification

Lorsque vous êtes prêt, utilisez /permissions pour autoriser les modifications dans l’espace de travail. Pour une nouvelle session, la combinaison documentée est codex --sandbox workspace-write --ask-for-approval on-request.

Précisez ensuite le critère d’acceptation :

Commencez par une tâche dont vous pouvez évaluer rapidement le résultat. Tester un comportement connu constitue une meilleure première mission qu’une demande ouverte d’amélioration de l’architecture.

De 12 à 15 minutes : vérifier le diff et les résultats

Utilisez /diff pour examiner les modifications et /review pour demander une revue. Vérifiez la sortie réelle des tests, les fichiers touchés et le respect de votre critère d’acceptation. Ne faites de commit qu’après votre propre revue. Ces commandes commençant par une barre oblique s’utilisent dans la session Codex, pas à l’invite du shell. Référence des commandes du CLI

Choisir le modèle après un premier essai de référence

Commencez avec le modèle disponible dans votre session, puis utilisez /model pour en sélectionner un autre ou ajuster l’effort de raisonnement. L’exemple de lancement actuellement donné par OpenAI est codex --model gpt-6.1-sol.

La recommandation actuelle est GPT-6.1 Sol pour les tâches de programmation complexes, lorsque votre compte et votre client y ont accès, et GPT-6 Luna pour les tâches ciblées et répétables. Un effort de raisonnement supérieur peut aider lors d’analyses difficiles, mais prend aussi plus de temps et consomme davantage de tokens. Pour comparer les résultats, conservez la même tâche initiale et le même réglage d’effort. Guide des modèles Codex

Lors de la prise en main en équipe, consignez le modèle utilisé avec la tâche et le résultat des tests. Sélectionner un nom de modèle ne suffit pas à donner à un compte le droit de l’utiliser.

Régler séparément le bac à sable et les approbations

Le bac à sable définit ce à quoi les commandes peuvent accéder. La politique d’approbation précise quand Codex doit demander votre accord avant d’agir. Imaginez que le bac à sable représente les murs d’un atelier, et la politique d’approbation l’autorisation d’en ouvrir une porte.

Pour le travail interactif, utilisez on-request : les actions autorisées dans le bac à sable peuvent s’exécuter, tandis que celles qui demandent un accès plus large peuvent déclencher une demande d’accord. Avec never, Codex ne peut pas demander d’approbation ; cela ne supprime pas le bac à sable. Une action bloquée peut donc le rester.

Définir un périmètre d’écriture ne garantit pas une demande d’accord avant chaque modification. Avec workspace-write et on-request, Codex peut modifier les fichiers de l’espace de travail et exécuter les commandes autorisées automatiquement. Consultez les réglages actifs avec /permissions. Fonctionnement du bac à sable et des approbations selon OpenAI

Si un ancien modèle de configuration de votre équipe contient approval_policy = "untrusted", mettez-le à jour : OpenAI a retiré ce réglage explicite et indique qu’il peut empêcher le démarrage. L’ancienne option codex exec --full-auto est elle aussi obsolète. Utilisez les réglages documentés du bac à sable et des approbations. Consignes de migration actuelles

Consigner les règles de travail dans AGENTS.md

Utilisez AGENTS.md pour ne plus avoir à répéter le fonctionnement de votre dépôt. Codex lit ces consignes au démarrage d’une exécution. /init peut générer une trame, qu’un mainteneur doit adapter avant que l’équipe ne s’y fie.

Un fichier utile à l’échelle du dépôt répond à quatre questions :

• Comment installer les dépendances et lancer le projet ?
• Quels tests et contrôles effectuer selon la modification ?
• Quels répertoires contiennent des fichiers générés ou demandent une attention particulière ?
• Que doit contenir le compte rendu final : changements de comportement, tests exécutés, échecs non résolus, par exemple ?

Indiquez vos vraies commandes et conventions, plutôt qu’une liste de souhaits génériques. Conservez vos préférences personnelles dans ~/.codex/AGENTS.md et versionnez les consignes communes à la racine du projet.

Codex charge les consignes globales, puis parcourt les répertoires de la racine du projet jusqu’au répertoire courant. Les instructions les plus locales priment sur celles chargées auparavant ; dans un même répertoire, AGENTS.override.md l’emporte sur AGENTS.md. Redémarrez la session après une modification des consignes et demandez à Codex de résumer celles qu’il a chargées. Règles de découverte des fichiers AGENTS.md

Considérez ce fichier comme un guide destiné aux contributeurs. Pour imposer des restrictions techniques, utilisez la configuration et les règles administrées par l’organisation.

Garder un config.toml court et facile à relire

Enregistrez vos réglages personnels par défaut dans ~/.codex/config.toml. Placez les réglages communs au projet dans .codex/config.toml, que Codex ne charge que pour les projets de confiance. Ces fichiers utilisent TOML, un format texte qui associe des valeurs à des paramètres nommés.

Ce point de départ rassemble les valeurs présentées dans le guide de configuration d’OpenAI. N’utilisez la ligne du modèle que si votre compte y a accès :

model = "gpt-6.1-sol"
model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

Les options du CLI et les valeurs passées avec --config priment sur la configuration du projet. Les réglages d’un projet de confiance priment sur les profils sélectionnés et vos réglages utilisateur par défaut. Les exigences de l’organisation peuvent limiter les possibilités, quels que soient ces réglages. Principes de configuration

web_search = "cached" sélectionne les résultats de recherche web mis en cache. Ce réglage est indépendant de l’accès réseau des commandes shell. Le téléchargement d’une dépendance peut nécessiter une approbation même si Codex dispose d’un outil de recherche web. Expliquez cette distinction dans le guide de prise en main, au lieu d’élargir les permissions à chaque échec de commande.

Ajouter un serveur MCP à Codex pour répondre à un besoin précis

MCP, ou Model Context Protocol, relie Codex à des outils et à du contexte externes. Un serveur local s’exécute sous forme de processus ; un serveur distant est accessible à une adresse HTTP. Ajoutez-en un lorsqu’une tâche exige des informations ou une action que votre dépôt ne peut pas fournir.

La documentation d’OpenAI donne l’exemple codex mcp add context7 -- npx -y @upstash/context7-mcp. Cette commande démarre un serveur de documentation via npx, qui doit donc être disponible. Lancez codex mcp list pour afficher les serveurs configurés, puis /mcp dans une session pour examiner les connexions actives. Pour un serveur compatible OAuth, utilisez codex mcp login <server-name> en remplaçant le paramètre fictif par le nom défini dans la configuration.

La configuration du serveur se place sous [mcp_servers.<server-name>], dans le même système de configuration TOML. Une équipe peut limiter les outils exposés avec enabled_tools et disabled_tools ; la liste d’exclusion est appliquée après la liste d’autorisation. Commencez par le plus petit ensemble d’outils utile. Configuration et réglages MCP

Pour la question distincte des réponses d’outils volumineuses, consultez notre article sur les limites de sortie MCP dans Codex CLI. Connecter un serveur et maîtriser le volume de ses réponses relèvent de réglages différents.

Utiliser les worktrees pour travailler dans des copies séparées

Un worktree Git donne à une tâche sa propre copie de travail du dépôt. C’est utile pour séparer les modifications d’une expérimentation des fichiers sur lesquels vous travaillez déjà.

La version 0.154.0 d’OpenAI a introduit les worktrees gérés pour les tâches du CLI, les sessions interactives et leurs bifurcations. Leur implémentation dépend de la fonctionnalité expérimentale worktrees et les réserve aux sessions locales. Activez cette fonctionnalité avec codex features enable worktrees, en utilisant la commande documentée d’activation des fonctionnalités, puis lancez codex --worktree. Notes de version, implémentation des worktrees interactifs, commandes de gestion des fonctionnalités

Dans une session compatible, /worktree propose de démarrer une nouvelle conversation ou de bifurquer vers une copie de travail gérée. Une bifurcation conserve l’historique de la conversation ; une nouvelle conversation repart de zéro. Ces options exigent que la fonctionnalité soit activée et qu’un dépôt Git local soit présent. Commandes de session pour les worktrees

Prévoyez d’assurer vous-même la revue, l’intégration et le nettoyage. Dans l’implémentation du CLI, le nettoyage automatique reste désactivé pour les copies de travail qu’il gère. Disposer d’une copie séparée ne remplace ni les réglages du bac à sable ni la revue avant fusion. Cycle de vie des copies de travail gérées

Consultez notre guide des worktrees dans Codex CLI lorsque vous serez prêt à mener des tâches en parallèle. Pour une première mission d’écriture de test, une seule copie de travail suffit.

Six tâches utiles, par ordre de priorité pour une petite équipe

Ce sont des suggestions de missions, pas des gains de productivité mesurés. Commencez par celle dont le critère d’acceptation sera le plus simple à vérifier.

Codex ne tranche pas les décisions produit manquantes et ne prouve pas qu’une suite de tests réussie couvre tous les risques. Vos critères d’acceptation et votre revue restent indispensables. Pour une évaluation plus large, consultez notre avis sur Codex ; pour éclairer un choix d’achat, lisez Codex face à Claude Code.

Deux outils ciblés qu’un fondateur technique pourrait créer

La piste la plus solide est un service de tests de non-régression dédié à une stack. Proposez aux petites équipes qui ont des bugs connus et une couverture insuffisante un correctif de tests déjà relu. La plus petite version utile part d’un cas reproductible, exécute une tâche Codex délimitée dans une copie de travail séparée et renvoie le correctif avec les résultats des tests. L’estimation de mots-clés DataForSEO pour les États-Unis, relevée le 11 octobre 2026, indique 880 recherches mensuelles pour « automated software testing services ». Ce chiffre mesure l’intérêt pour le besoin, pas la volonté d’acheter ce produit. La difficulté consiste à disposer de fixtures fiables et d’assertions pertinentes ; un test qui se contente de répéter l’implémentation apporte peu de valeur.

Un assistant de revue propre à un dépôt constitue la seconde piste. Un responsable technique pourrait payer pour des revues qui appliquent les conventions documentées de l’équipe et renvoient une liste courte de problèmes vérifiables. Commencez par un dépôt, son AGENTS.md et une procédure de revue répétable. La même étude de la demande estime à 1 300 le nombre de recherches mensuelles aux États-Unis pour « ai code review ». Le point délicat est la différenciation : Codex sait déjà relire du code, le produit doit donc améliorer la pertinence des retours et réduire les fausses alertes. La génération de tests offre un premier livrable plus clair, car l’acheteur peut examiner et exécuter ce que vous lui fournissez.

Questions fréquentes lors de la prise en main

Lundi, demandez à un mainteneur de réaliser la même petite tâche avec deux collègues. Consignez l’effort de revue et de correction, puis ajustez les consignes communes là où le passage de relais se grippe. Élargissez le périmètre seulement lorsque l’équipe saura répéter ce cycle avec confiance.

Pour mettre en place un workflow de dépôt fondé sur ces contrôles, nous concevons des systèmes d’IA en production.