Installer et utiliser Codex, l’agent de code d’OpenAI

Codex est l’agent de développement logiciel d’OpenAI : il lit un dépôt, modifie des fichiers, lance des commandes et observe leurs résultats jusqu’à estimer la tâche terminée. Il se décline en CLI (Command Line Interface, interface en ligne de commande) open source sous licence Apache 2.0, en extension pour éditeurs de code et en service hébergé, Codex cloud, accessible depuis ChatGPT. Ce guide traite surtout de la CLI, qui s’exécute sur le poste, au contact des fichiers, des jetons et du réseau. La position défendue : un agent de code est un collaborateur rapide qui n’a aucune idée de ce qui est précieux sur la machine ; le bac à sable et les approbations ne sont pas des options de confort mais le contrat de travail. Le principe général est exposé dans la définition de l’agentique.

Commandes et options vérifiées dans la documentation officielle en octobre 2026 ; le produit évolue vite, relire la référence avant de scripter.

→ Lire l’explication complète de la marmotte

Prérequis et compromis central

Avant la première commande, il faut réunir :

un poste macOS (Apple Silicon ou x86_64), Linux (x86_64 ou arm64) ou Windows ; sous Windows, la CLI dispose d’un bac à sable natif quand elle tourne dans PowerShell, ou réutilise celui de Linux dans WSL2 (Windows Subsystem for Linux) ;
sous Linux et WSL2, l’outil bubblewrap, sur lequel repose le bac à sable, installé par le gestionnaire de paquets de la distribution ;
soit un compte ChatGPT rattaché à un espace de travail éligible (offres Plus, Pro, Business, Edu ou Enterprise selon le dépôt officiel), soit une clé d’API (Application Programming Interface) OpenAI facturée à l’usage ;
un dépôt sous Git, propre (git status sans modification en attente), pour pouvoir annuler les modifications de l’agent dans le dépôt.

Le compromis : on gagne un exécutant qui enchaîne lecture, modification et test seul ; on paie un programme qui exécute des commandes choisies par un modèle de langage d’après un texte (dépôt, dépendances, pages web) que n’importe qui a pu écrire. Tout ce que l’agent peut lire est une instruction potentielle, et tout ce qu’il peut atteindre est une cible potentielle.

Étapes 1 à 3 : installation et authentification

Étape 1. Installer la CLI. Le dépôt officiel propose un script d’installation, un paquet npm et un paquet Homebrew. Plutôt que curl ... | sh, qui confie son shell à un fichier jamais lu, télécharger le script, le lire, puis l’exécuter.

# Option A : script officiel, téléchargé puis relu avant exécution
curl -fsSL https://chatgpt.com/codex/install.sh -o codex-install.sh
less codex-install.sh
sh codex-install.sh

# Option B : paquet npm officiel (attention au nom exact, un paquet
# au nom voisin est une cible classique de typosquattage)
npm install -g @openai/codex

# Option C : Homebrew sur macOS
brew install --cask codex

# Linux et WSL2 : dépendance du bac à sable (Debian, Ubuntu)
sudo apt install bubblewrap

Sous Windows, le script équivalent est install.ps1, servi à la même adresse que install.sh.

Étape 2. S’authentifier. codex login ouvre le navigateur pour la connexion ChatGPT ; codex login --device-auth affiche un code à saisir sur un autre appareil, utile sur un serveur sans navigateur ; codex login --with-api-key lit une clé d’API sur l’entrée standard.

# Connexion par compte ChatGPT (navigateur)
codex login

# Machine sans navigateur : code d'appareil
codex login --device-auth

# Clé d'API passée par l'entrée standard, jamais en argument :
# un argument apparaît dans l'historique du shell et dans la liste des processus
printenv OPENAI_API_KEY | codex login --with-api-key

Étape 3. Protéger les identifiants. Par défaut, les jetons sont mis en cache dans ~/.codex/auth.json, que la documentation demande de traiter comme un mot de passe. Le réglage cli_auth_credentials_store accepte file, keyring (magasin d’identifiants du système), auto ou ephemeral (mémoire seule). keyring évite qu’un simple cat ou une sauvegarde ne livre le jeton. Pour Codex cloud, la documentation exige l’activation de l’authentification multifacteur sur le compte.

# ~/.codex/config.toml : jetons dans le trousseau du système
cli_auth_credentials_store = "keyring"

Premier usage

Se placer à la racine du dépôt et lancer codex. L’interface interactive accepte une demande en langage naturel et quelques commandes à barre oblique : /init génère un fichier AGENTS.md, /status affiche la configuration de la session, /permissions change le mode d’autonomie sans redémarrer, /model choisit le modèle et l’effort de raisonnement, /review fait relire les modifications en cours.

cd ~/projets/facturation
git status                       # point de départ propre, sinon rien à comparer
codex "Explique l'architecture de ce dépôt, sans rien modifier"

# Session précédente
codex resume

# Mode non interactif, pour un script : lecture seule par défaut
codex exec "Liste les fonctions sans test unitaire dans src/"

# Autoriser l'écriture dans le dépôt pour une exécution non interactive
codex exec --sandbox workspace-write "Ajoute les tests manquants pour src/tva.py"

codex exec --json émet chaque événement en JSON Lines (JavaScript Object Notation, une ligne par objet), codex exec -o <fichier> n’écrit que le message final. L’extension pour éditeurs (Visual Studio Code, Cursor, Windsurf, et des intégrations JetBrains et Xcode) offre la même boucle.

Modes d’autonomie et permissions

Deux réglages indépendants gouvernent ce que l’agent peut faire seul.

Le bac à sable (--sandbox, -s, ou sandbox_mode dans la configuration) fixe la frontière technique, appliquée par le système d’exploitation (Seatbelt sous macOS, bubblewrap sous Linux) :

read-only : lecture et commandes sans écriture ;
workspace-write : lecture et écriture dans le répertoire de travail, mode par défaut en session interactive ;
danger-full-access : aucune restriction, réservé à un environnement jetable.

La politique d’approbation (--ask-for-approval, -a, ou approval_policy) fixe quand l’agent doit demander : on-request le fait s’arrêter avant toute action hors du bac à sable ou tout accès réseau ; never supprime toute demande. Un mode granular permet de ne solliciter l’humain que pour certaines catégories, comme les sorties du bac à sable ou les appels d’outils MCP (Model Context Protocol). En octobre 2026, l’ancienne valeur untrusted n’est plus prise en charge, et l’option --full-auto est dépréciée au profit de --sandbox workspace-write.

Par défaut, le réseau est coupé dans le bac à sable, et les répertoires .git, .codex et .agents restent en lecture seule même en workspace-write. L’option --add-dir ajoute un répertoire inscriptible sans lever le bac à sable, et codex sandbox permet de tester une commande sous la politique choisie.

# ~/.codex/config.toml : réglage recommandé pour un usage interactif
approval_policy = "on-request"
sandbox_mode = "workspace-write"

L’option --dangerously-bypass-approvals-and-sandbox, alias --yolo, supprime à la fois le bac à sable et les approbations. Son nom fait le travail de mise en garde ; la documentation la réserve aux environnements durcis, c’est-à-dire un conteneur ou une machine virtuelle jetable, sans identifiant de valeur ni accès au réseau interne.

Instructions de projet : AGENTS.md

Codex lit des instructions en Markdown dans des fichiers AGENTS.md. Il cherche d’abord ~/.codex/AGENTS.override.md puis ~/.codex/AGENTS.md, ensuite, de la racine Git jusqu’au répertoire courant, AGENTS.override.md puis AGENTS.md à chaque niveau. Les fichiers sont concaténés de la racine vers le bas : le plus proche du répertoire courant l’emporte. La taille totale lue est plafonnée par project_doc_max_bytes, 32 Kio par défaut ; au-delà, la suite des consignes n’est pas lue.

On y met les commandes de test, les conventions, et surtout les interdits : ne jamais lire .env, ne jamais modifier infra/, ne jamais ajouter de dépendance sans la nommer dans le résumé. Ces consignes orientent le modèle sans le contraindre : AGENTS.md n’est pas un contrôle d’accès, et une instruction contraire glissée dans un fichier lu peut l’emporter. Les interdits réels passent par le bac à sable. Versionné, il mérite dans une contribution externe la même attention qu’un script d’intégration continue.

Bonnes pratiques de sécurité

Secrets. Aucun secret de production dans le répertoire de travail ni dans l’environnement du shell : ce que le processus lit, le modèle peut le recopier ailleurs. En intégration continue, la documentation demande de ne jamais exposer la clé au niveau du job, de la passer seulement à l’invocation (CODEX_API_KEY=... codex exec ...) ou d’utiliser l’action GitHub officielle, et de réserver auth.json aux exécuteurs de confiance. Les clés elles-mêmes se gèrent comme décrit dans la sécurisation des clés d’API des fournisseurs d’IA et, à terme, dans un coffre-fort de secrets.

Moindre privilège. Commencer en read-only sur un dépôt inconnu, passer en workspace-write pour travailler, ne jamais lancer l’agent depuis le répertoire personnel ni avec sudo. Un compte utilisateur dédié, sans clé SSH (Secure Shell) de production ni session cloud ouverte, borne les dégâts.

Revue des diffs. Tout changement passe par git diff avant commit, surtout les fichiers de dépendances, les scripts de construction et la configuration d’intégration continue. Les assistants de code proposent parfois des paquets qui n’existent pas, et que des attaquants s’empressent d’enregistrer ; voir le slopsquatting et la revue de sécurité du code généré.

Réseau. Laisser le réseau coupé par défaut et l’ouvrir ponctuellement, par approbation. Un agent qui lit une page web et dispose du réseau réunit les deux ingrédients d’une exfiltration par injection de prompt. Côté Codex cloud, l’accès Internet pendant la tâche est désactivé par défaut et peut être restreint à une liste de domaines (préréglage « gestionnaires de paquets » ou domaines personnalisés). Les risques d’actions irréversibles sont détaillés dans la sécurisation des actions des agents.

Utilité : quand l’agent apporte vraiment, quand s’en passer

L’agent rapporte quand la tâche est bornée et vérifiable par une machine :

explorer un dépôt inconnu et en résumer l’architecture, en lecture seule ;
écrire les tests manquants d’un module, la suite de tests jugeant le résultat ;
migrations mécaniques : renommage d’API, montée de version d’une bibliothèque, correction en masse d’avertissements du linter ;
relecture préalable d’une branche avec /review ou codex review, en complément d’une revue humaine ;
tâches parallèles dans Codex cloud, chacune dans son conteneur, livrées en pull request.

Il vaut mieux s’en passer :

sur du code de sécurité critique (cryptographie, authentification, contrôle d’accès) sans expertise humaine pour juger le résultat : un code qui passe les tests n’est pas un code sûr ;
sur une machine qui détient des identifiants de production, ou directement sur un serveur ;
quand le dépôt contient des données personnelles ou couvertes par un secret contractuel : le contenu lu part chez le fournisseur du modèle ;
quand la spécification est floue : l’agent répondra avec aplomb à la question qu’il a cru comprendre ;
pour des opérations irréversibles (suppression de données, déploiement, migration de base de production).

Le gain réel se mesure au temps de relecture : si vérifier le travail de l’agent coûte plus que le faire soi-même, l’agent est un coût.

🐝 Ce qui arrive si on s’en passe

Installé sans précautions, avec --yolo sur un poste de développeur ordinaire, l’agent exécute avec les droits complets de l’utilisateur toute commande que lui suggère le texte qu’il lit. Un fichier README piégé, un commentaire de ticket ou une page de documentation suffit alors à lui faire lire ~/.ssh, ~/.aws ou ~/.codex/auth.json et à les envoyer vers un serveur externe, puisque le réseau est ouvert. Une dépendance hallucinée et installée sans relecture introduit du code malveillant dans la chaîne de construction, qui le signe et le distribue ensuite fidèlement. Un rm mal ciblé hors du dépôt ne se rattrape par aucun git checkout. Et faute de diff relu, la porte dérobée ou la vérification d’autorisation supprimée part en production avec la mention « tests au vert ».

🦫 Explication de la marmotte 🍫

Codex est un programme d’OpenAI qui écrit du code à la place du développeur. On l’installe sur son ordinateur, on lui ouvre un projet et on lui demande, en français, par exemple d’ajouter des tests ou de corriger une erreur. Il lit alors les fichiers, en modifie certains et lance lui-même des commandes pour vérifier que tout fonctionne. Une version en ligne, dans ChatGPT, travaille sur une copie du projet dans un ordinateur distant.

Le danger est qu’un programme qui tape des commandes tout seul peut aussi taper de mauvaises commandes : effacer des fichiers, lire des mots de passe ou les envoyer sur Internet, surtout si quelqu’un a caché une fausse consigne dans un fichier qu’il lit. C’est pourquoi Codex fonctionne dans un bac à sable : une zone fermée où il ne peut modifier que le dossier du projet et n’a pas accès à Internet. Pour sortir de cette zone, il doit demander la permission, et c’est à l’humain de dire oui ou non.

Les bonnes habitudes : aucun mot de passe important là où l’agent travaille, bac à sable toujours activé, chaque modification relue comme une copie corrigée. Et ne pas lui confier ce qu’on serait incapable de vérifier soi-même : un travail rapide qu’on ne sait pas relire n’est pas un gain de temps, c’est un pari.

Pages voisines

La citent

Installer et utiliser Codex, l'agent de code d'OpenAI

Elle cite

: les deux pages se citent l’une l’autre.