Aperçu des concepts clés de Codex

📚 Navigation de la série : Le chapitre précédent 01 · Présentation de Codex et de ses quatre interfaces d'accès a passé en revue les différentes déclinaisons de Codex — application de bureau, ligne de commande, extension IDE et cloud. Ce chapitre approfondit le sujet en présentant les concepts clés indispensables pour la suite. L'installation pratique est abordée au chapitre 03 · Installation et connexion.

Pour illustrer l'importance de ces concepts, voici une erreur classique. À mes débuts sur Codex, j'ai demandé à l'outil de « renommer ces trois fichiers par lots ». Il s'est exécuté rapidement, mais je me suis aperçu qu'il n'avait modifié que les fichiers du dossier de projet actif, jokerisant totalement les deux fichiers stockés sur mon bureau. Je me suis d'abord demandé pourquoi un outil censé lancer des commandes présentait de telles restrictions. C'est en consultant la documentation que j'ai compris : le bac à sable (Sandbox) limitait ses actions au seul espace de travail configuré. Toute action extérieure exigeait une confirmation manuelle.

C'est là que j'ai réalisé : sans une bonne compréhension de ces concepts, le comportement de Codex peut sembler imprévisible. Pourtant, l'outil obéit simplement aux règles de sécurité qui lui sont imposées.

Ce chapitre détaille ces mécanismes de sécurité et de configuration.

À la fin de ce chapitre, vous obtiendrez :

• La définition synthétique du concept d'« agent » de Codex et sa différence avec un chatbot classique
• Le fonctionnement conjoint du bac à sable (Sandbox) et de l'approbation pour gérer les droits d'écriture
• L'usage du fichier AGENTS.md pour fixer les règles permanentes de votre projet
• La présentation de la mémoire (Memory) et de Chronicle, leurs configurations et limites
• Un exercice pratique pour observer l'interception d'une action par la sandbox

⚠️ Note : Les commandes, paramètres et comportements décrits ci-dessous font référence à la documentation officielle de Codex ; les noms des modèles et les formules tarifaires sont susceptibles d'évoluer.

---

01 Concept d'Agent : agir de manière autonome au-delà de la discussion

En synthèse : Codex est l'agent de programmation (coding agent) d'OpenAI, capable d'accéder aux fichiers, d'éditer le code et d'exécuter des commandes de manière autonome, par opposition aux modèles se limitant à générer du texte. La documentation officielle le définit ainsi : « OpenAI's coding agent that can read, edit, and run code ».

Le terme « Agent » désigne un programme d'IA capable de planifier des tâches, de manipuler des outils et d'évaluer les résultats pour adapter son action, à la différence d'une interface de chat passive basée sur des questions-réponses.

Le mode de fonctionnement est ainsi décrit : « l'agent exécute des commandes de terminal au sein d'une boucle. Il édite le code, lance des vérifications et valide son propre travail » (« The agent runs terminal commands in a loop. It edits code, runs checks, and tries to validate its work »).

Il s'appuie sur le cycle classique : concevoir → agir → vérifier :

• Concevoir : Analyser les fichiers, lire les rapports d'erreurs et identifier la situation
• Agir : Modifier le code, créer des fichiers, exécuter des commandes shell
• Vérifier : Lancer des tests, analyser les retours et itérer en cas d'échec

Analogie : La différence entre un conseiller clientèle et un acheteur personnel. Un chatbot traditionnel fonctionne comme un conseiller qui répond à une question de prix (« combien coûte cet article ? »). Codex s'apparente à un acheteur personnel : vous lui demandez d'acquérir un vêtement noir de taille standard, il recherche l'article, compare les prix, passe commande, valide la conformité à la réception et gère l'éventuel retour en cas d'erreur. Cette capacité à exécuter un processus complet en autonomie distingue l'agent de l'interface de discussion.

Voici quelques exemples concrets :

• Face à un test en échec, Codex lance le test → lit le rapport d'erreur → localise le bug → applique la correction → relance la vérification, le tout sous votre supervision.
• Face à un projet existant sans documentation, Codex liste les fichiers du répertoire, effectue des recherches par mots-clés, analyse les documents nécessaires et génère un schéma d'architecture — sans que vous ayez à lui spécifier les fichiers à ouvrir.
• Si vous demandez d'ajouter un cache sur une fonction, Codex applique la modification et met à jour les appels associés à travers l'ensemble des fichiers du projet.

💡 En résumé : Codex fonctionne comme un agent et non comme une simple interface de chat — il résout les tâches au sein d'un cycle « concevoir → agir → vérifier », un mécanisme identique à celui de Claude Code.

---

02 Le bac à sable (Sandbox) : délimiter le périmètre d'action

C'est le mécanisme de sécurité qui a causé l'échec de renommage décrit en introduction.

Le bac à sable (Sandbox) : Défini officiellement comme la limite (boundary) permettant à Codex d'agir de manière autonome sans pour autant disposer de droits illimités sur votre machine. Il s'agit d'un périmètre d'exécution : libre dans son enceinte, toute sortie exige votre validation.

Analogie : L'aire de jeux pour enfants. Vous laissez un enfant jouer au sein de l'espace délimité (toboggan, piscine à balles) sans avoir à surveiller chaque geste. S'il tente de franchir la barrière pour rejoindre le parking, une alerte retentit et exige votre intervention. La sandbox est cette barrière : autonomie complète au sein du périmètre, contrôle systématique lors des tentatives de sortie — vous évitant des validations répétitives tout en sécurisant votre système.

Ce périmètre contrôle deux aspects : les droits de modification des fichiers et l'accès réseau. La documentation officielle propose trois modes de sandbox :

Mode de sandbox	Modifications de fichiers	Accès réseau	Cas d'usage
read-only (Lecture seule)	❌ Non (exige une approbation)	❌	Analyse de code, revues ou propositions sans altération des fichiers
workspace-write (Écriture dans l'espace de travail)	✅ Limité au répertoire du projet	❌ Désactivé par défaut	Mode de développement standard ; sélectionné par défaut sous contrôle de version, sinon bascule en read-only
danger-full-access (Accès complet)	✅ Illimité sur la machine	✅	Environnements de confiance absolue. L'intitulé contient le terme « danger » à dessein, à utiliser avec prudence

La mention « Limité au répertoire du projet » du mode workspace-write explique l'anomalie de renommage décrite en introduction — les fichiers stockés sur le bureau se situaient en dehors du projet actif, donc hors du périmètre d'action. Codex n'a pas ignoré la consigne, il n'avait pas les droits d'accès requis.

La documentation officielle précise que la sandbox s'applique également aux processus enfants lancés par Codex. Qu'il appelle git, des gestionnaires de paquets ou des scripts de tests, ces commandes s'exécutent au sein du même périmètre sécurisé — évitant qu'un sous-processus ne contourne les restrictions appliquées au processus principal.

Les technologies sous-jacentes dépendent du système d'exploitation (voir chapitre 03 · Installation et connexion) :

• macOS : s'appuie sur le framework Seatbelt natif, fonctionnel sans configuration supplémentaire.
• Windows : s'exécute dans l'environnement Windows natif via la sandbox système (déclinée en modes elevated et unelevated) ; sous WSL2, le système utilise l'implémentation Linux.
• Linux / WSL2 : requiert l'installation préalable de l'utilitaire bubblewrap pour activer la sandbox (contrainte documentée officiellement).

💡 En résumé : La sandbox est la première sécurité de Codex — par défaut (workspace-write), elle limite les modifications de fichiers au répertoire du projet et bloque l'accès réseau ; étendre ses capacités exige une configuration explicite.

---

03 L'approbation (Approval) : valider les franchissements de limites

La délimitation du périmètre d'action (sandbox) est complétée par la gestion des alertes de sortie, désignée sous le terme d'approbation (Approval).

Ces deux notions sont souvent confondues. La documentation officielle le précise : la sandbox définit la limite technique d'accès, la politique d'approbation détermine à quel moment Codex doit s'interrompre pour solliciter votre accord avant de franchir cette limite.

Analogie : Le lecteur de badges et l'agent de sécurité. La sandbox est le lecteur physique qui verrouille la porte. L'approbation est la consigne donnée à l'agent de sécurité posté à l'entrée — certains laissent passer tout le monde (never), d'autres contrôlent uniquement les visiteurs inconnus (untrusted), et d'autres encore vous interrogent à chaque passage (on-request). Le verrou est fixe, la rigueur du contrôle est paramétrable.

Trois politiques d'approbation sont proposées :

Politique d'approbation	Comportement de Codex	Description
untrusted	Interrogation avant d'exécuter une commande non répertoriée dans la liste de confiance	Contrôle des processus inconnus
on-request	Exécution autonome au sein de la sandbox, interruption pour validation en cas de sortie	Niveau intermédiaire recommandé
never	Aucune demande de confirmation	Utile pour l'automatisation ; l'accès reste soumis aux limites de la sandbox, ce mode n'ayant de sens qu'avec un accès complet

Note : ces politiques untrusted / on-request / never constituent des paramètres d'approbation distincts des modes de sandbox. Ils se configurent indépendamment.

Deux combinaisons types sont recommandées par la documentation officielle :

• Développement local sécurisé (recommandé) : sandbox_mode = "workspace-write" associé à approval_policy = "on-request". Les accès sont sécurisés, l'outil ne vous sollicitant qu'en cas de besoin extérieur.
• Accès illimité (à éviter) : sandbox_mode = "danger-full-access" associé à approval_policy = "never". Les verrous et contrôles sont désactivés — à réserver exclusivement aux environnements sécurisés et de confiance absolue.

En pratique, je conseille d'activer le mode read-only sur les dépôts inconnus ou projets récents pour laisser Codex analyser le code sans l'altérer. Une fois la proposition technique validée, vous pouvez basculer sur workspace-write. Évitez d'activer le mode danger-full-access par commodité sur des scripts de traitement, au risque de voir l'outil accéder à vos répertoires personnels.

Ces options sont accessibles via la commande /permissions au sein de la CLI (ou via le sélecteur d'interface de l'application de bureau et des IDE). Pour figer ces choix au démarrage, modifiez le fichier de configuration (voir chapitre 18 · Configuration détaillée de config.toml).

Voici le schéma décisionnel associant la sandbox et l'approbation :

Le processus se résume ainsi : pour chaque action, Codex vérifie si l'accès s'effectue dans le périmètre de la sandbox ; si ce n'est pas le cas, la politique d'approbation définit s'il convient de solliciter l'utilisateur.

💡 En résumé : La sandbox gère les accès techniques, l'approbation définit le niveau d'alerte. Le couple workspace-write et on-request offre le meilleur compromis entre sécurité et autonomie.

---

04 Le fichier AGENTS.md : le livret d'accueil du projet

Après la gestion des accès, abordons la persistance des règles : comment consigner les contraintes spécifiques d'un projet pour éviter d'avoir à les répéter à chaque session.

La solution s'appuie sur le fichier AGENTS.md.

Analogie : Le livret d'accueil du nouveau collaborateur. Face à un nouveau développeur, vous n'allez pas lui répéter quotidiennement d'utiliser pnpm au lieu de npm, ou de rédiger ses messages de commit dans une langue spécifique — vous lui transmettez un manuel de conventions. Le fichier AGENTS.md remplit cet office pour Codex : placé dans le projet, il est analysé avant chaque session pour en guider les choix.

La documentation le qualifie de directive de projet durable (« durable project guidance ») — des règles persistantes partagées au sein du dépôt et chargées avant toute tâche. Conseil de rédaction : restez synthétique (Keep it small) pour éviter d'encombrer le contexte.

Les thématiques courantes incluent (exemples officiels) :

• Les commandes de build et de test (ex. pytest -q)
• Les exigences de qualité de code (ex. validation systématique par un linter)
• Les conventions de nommage et d'architecture propres au dépôt

Deux niveaux d'emplacement sont possibles, le fichier le plus proche du répertoire de travail étant prioritaire :

Périmètre	Emplacement	Cible
Global	~/.codex/AGENTS.md	Préférences personnelles (ex. concision des réponses), actif pour l'ensemble des projets
Projet	Racine du dépôt ou sous-dossier	Règles spécifiques du projet partagées via le contrôle de version (git)

La documentation souligne une méthode efficace : l'utiliser comme boucle de rétroaction (feedback loop). Si Codex formule une hypothèse erronée sur votre code, ne vous contentez pas de le corriger dans le chat (l'oubli survenant à la session suivante). Demandez-lui d'inscrire cette contrainte directement dans le fichier AGENTS.md. Les sessions ultérieures en hériteront automatiquement. C'est un moyen d'enrichir le fichier au fil de la résolution des anomalies pour éviter les régressions.

Le rôle de AGENTS.md dans Codex est identique à celui de CLAUDE.md dans Claude Code.

💡 En résumé : Le fichier AGENTS.md est le guide de conventions de Codex — consignez-y les contraintes à charger avant chaque tâche ; l'enrichir au fil des erreurs permet de stabiliser les comportements.

---

05 La mémoire (Memory) et Chronicle : la persistance des préférences

Ces concepts récents concernent la capacité de Codex à mémoriser des informations d'une session à l'autre.

Distinguez ces deux fonctionnalités :

La mémoire (Memory) : Permet à Codex de conserver des informations structurées issues des sessions précédentes (stack technique, conventions, résolutions de bugs) pour les appliquer aux tâches futures sans récurrence d'explications.

Analogie : Collaborer avec un binôme historique. Face à un nouveau collaborateur, vous devez préciser les règles élémentaires (usage de TypeScript, absence de points-virgules). Un partenaire habitué à vos méthodes intègre ces choix automatiquement. La mémoire vise à installer ce niveau de complicité avec l'outil.

Voici quelques contraintes de fonctionnement à retenir :

• Désactivée par défaut (off by default). La fonction doit être active dans les préférences de l'application ou en déclarant memories = true sous la section [features] du fichier ~/.codex/config.toml.
• Restrictions géographiques. Non disponible pour l'Espace Économique Européen (EEE), le Royaume-Uni et la Suisse.
• Traitement asynchrone. La consolidation des données s'effectue en arrière-plan lorsque la session est inactive, le contenu d'une tâche récente n'étant pas disponible immédiatement.
• Stockage local : Enregistré au format markdown dans le sous-dossier ~/.codex/memories/.
• Gestion par session : Contrôle de l'activation et de l'apprentissage de la mémoire pour la session active via la commande /memories.

La documentation officielle souligne que les contraintes critiques du projet doivent obligatoirement figurer dans le fichier AGENTS.md et non s'appuyer sur la mémoire. Cette dernière constitue une surcouche de confort statistique et local, insuffisante pour garantir la conformité aux normes du projet.

💡 En résumé : La mémoire améliore le confort d'usage en conservant vos préférences, mais reste désactivée par défaut et géographiquement restreinte — confiez les règles de développement à AGENTS.md.

Chronicle présente également des contraintes spécifiques :

⚠️ Fonctionnalité expérimentale. Proposée en version d'évaluation (opt-in research preview) pour les comptes ChatGPT Pro sous macOS uniquement ; non disponible en Europe, au Royaume-Uni et en Suisse.

Chronicle enrichit la mémoire avec le contenu de l'écran. Contrairement à la mémoire classique limitée à l'historique du chat, Chronicle analyse l'affichage de votre écran (code actif, pull requests ou documentations ouvertes) pour aligner les réponses sur votre tâche en cours.

Analogie : Un collaborateur observant votre écran. Au lieu de lui décrire verbalement votre situation, il constate l'affichage (« d'accord, tu analyses cette erreur ») et adapte ses retours. Cette commodité s'accompagne de contraintes identifiées officiellement : consommation de quota élevée, risques d'injections de requêtes accrus (prompt injection) et stockage local non chiffré. Utilisez le bouton « Pause Chronicle » lors de la saisie de données confidentielles (identifiants, communications, informations clients).

Critère	Mémoire (Memory)	Chronicle
Origine des données	Historique des échanges	Contenu affiché à l'écran
Statut	Fonctionnalité standard (désactivée)	Version d'évaluation (expérimentale)
Compatibilité	CLI / Application de bureau	macOS et comptes Pro uniquement
Recommandation	À activer pour le confort d'usage	À réserver aux tests, suspendre lors des tâches sensibles

💡 En résumé : La mémoire affine le comportement de l'outil dans le temps, mais reste désactivée par défaut, soumise à des restrictions régionales et ne se substitue pas à AGENTS.md ; Chronicle propose une intégration contextuelle par analyse d'écran en version expérimentale, avec des risques de sécurité associés.

Voici le schéma d'intégration de ces cinq concepts clés :

Ce schéma résume l'architecture : l'agent d'exécution est au centre, opérant au sein du périmètre de la sandbox. Ses interactions extérieures sont validées par la politique d'approbation. Le fichier AGENTS.md lui transmet les conventions du projet en amont, tandis que le couple Memory / Chronicle assure la continuité contextuelle entre les tâches.

---

06 Pratique : observer l'interception d'une action par la sandbox

Un court exercice pratique permet d'observer l'effet d'une restriction de sandbox sur une commande d'écriture. Il s'exécute dans un répertoire temporaire vide.

Étape 1 : Créer le répertoire et démarrer Codex

Saisissez dans votre console (sous Windows, remplacez mkdir -p par mkdir) :

mkdir -p ~/codex-demo && cd ~/codex-demo
codex

Si Codex n'est pas encore installé sur votre système, poursuivez la lecture ; l'installation est détaillée au chapitre 03 · Installation et connexion.

Étape 2 : Configurer le mode lecture seule

Saisissez la commande suivante dans Codex :

/permissions

Résultat attendu : La console confirme le passage en lecture seule :

Permissions updated: read-only

⚠️ Note sur les versions récentes : Depuis la version 0.142 du CLI, l'application s'appuie sur des profils de permissions (permission profiles, en version bêta expérimentale) remplaçant les anciens préréglages. Le menu de /permissions peut ainsi présenter les options Ask for approval / Approval for me / Full access associées aux politiques d'approbation.

Si l'option Read Only n'est pas proposée, fermez la session et relancez l'outil avec la commande codex --sandbox read-only pour assurer le comportement recherché pour ce test.

Étape 3 : Lancer une action d'écriture pour déclencher l'alerte

Saisissez la consigne suivante :

帮我新建一个文件 hello.txt，里面写一行字 "hello codex"。

Résultat attendu : Codex interrompt son exécution et sollicite votre approbation. L'action d'écriture sortant des limites de la sandbox active, le système demande confirmation :

我需要创建文件 hello.txt，这超出了当前只读模式的权限，
是否允许？(y/n)

Ce comportement illustre l'action conjointe de la sandbox (qui identifie la sortie de périmètre) et de la politique d'approbation (qui exige la validation de l'utilisateur avant d'exécuter l'action).

Étape 4 : Comparer avec le mode écriture

Basculez de nouveau via /permissions vers le mode workspace-write et relancez la création de hello.txt. L'action d'écriture s'effectuant désormais au sein de la zone autorisée, le fichier est créé sans alerte :

已创建 hello.txt

Vérifiez les paramètres actifs de la session avec la commande /status :

/status

Cet exercice met en évidence le rôle de la sandbox : filtrer et interrompre les écritures selon le profil actif pour sécuriser le système.

---

07 Résumé

Ce chapitre a posé les bases conceptuelles de Codex :

Concept	Définition simple	Équivalent Claude Code
Agent	Programme d'IA résolvant les tâches de manière autonome (concevoir → agir → vérifier)	Cycle d'agent (identique)
Sandbox (bac à sable)	Périmètre limitant les modifications de fichiers et le réseau	Permissions d'accès système
Approbaton	Niveau d'alerte lors des sorties de la sandbox	Mode de permissions
AGENTS.md	Fichier de conventions chargé avant chaque tâche	Fichier CLAUDE.md
Memory / Chronicle	Rétention des préférences et analyse d'écran (expérimental)	Mémoire locale

Vous comprenez désormais pourquoi Codex refuse d'accéder à certains fichiers externes (limite de la sandbox), pourquoi il s'interrompt pour demander une validation (politique d'approbation), et comment guider son comportement avec AGENTS.md ou la commande /permissions.

L'essentiel à retenir : Codex n'est pas un simple outil de génération automatique, mais un assistant d'exécution encadré par des règles de sécurité. Votre rôle consiste à orienter ses tâches, délimiter son périmètre d'action et superviser son avancement.

---

Le chapitre suivant 03 · Installation et connexion détaille l'installation pratique de Codex sous macOS, Windows et Linux, et l'initialisation de votre compte utilisateur.

---

Lectures recommandées

• Présentation de Codex et de ses quatre interfaces d'accès
• Connexion à des modèles tiers comme DeepSeek
• Bonnes pratiques : conseils pragmatiques pour la production