Configuration du fichier config.toml : centraliser tous les paramètres
📚 Navigation dans la série : Le chapitre précédent 17 · Utilisation de l'ordinateur et navigateur (Computer Use) a donné des mains à Codex — lui permettant d'analyser l'écran, d'interagir avec le bureau et de piloter le navigateur. Ce chapitre se recentre sur un simple fichier texte — le fichier
config.toml. Après l'avoir croisé à plusieurs reprises dans les chapitres précédents (pour le paramétrage du bac à sable, de la mémoire ou des modèles), nous allons l'étudier en détail : où le situer, comment le structurer, quel paramètre contrôle quel comportement, et comment se gèrent les priorités lorsque plusieurs fichiers se superposent.
On entend souvent dire que les fichiers de configuration sont des éléments « à configurer après l'installation » et qu'il vaut mieux ne pas y toucher tant que le système fonctionne — pour être honnête, c'est exactement le contraire avec Codex.
Laissez-moi vous partager mon expérience : en mars 2026, à mes débuts avec Codex, je n'avais pas touché au fichier config.toml. À chaque lancement, je modifiais manuellement le modèle avec /model, j'ajustais les permissions avec /permissions et je forçais le réseau avec --search. Je répétais ces mêmes manipulations sept à huit fois par jour. Un jour, j'ai compté que j'avais exécuté la combinaison « basculer sur un modèle performant + accorder les droits d'écriture sur le projet » plus de trente fois dans la semaine. C'est là que j'ai réalisé que je transformais une tâche à configurer une fois pour toutes en une corvée quotidienne.
Le fichier config.toml sert précisément à cela : il n'est pas réservé aux experts, il simplifie la vie de tous ceux qui veulent éviter les tâches répétitives. Plus vous souhaitez éviter les configurations manuelles, plus vous avez intérêt à consacrer dix minutes à le paramétrer.
De plus, il recèle un piège classique pour les débutants : une même configuration écrite dans votre répertoire utilisateur global ou au sein de votre projet peut avoir un comportement différent, voire ne pas être prise en compte du tout. Ce chapitre détaille les règles de priorité et de localisation pour vous permettre de configurer votre environnement sereinement.
À la fin de ce chapitre, vous aurez en main :
- La définition de
config.tomlet sa répartition de rôles avecAGENTS.mdpour éviter les confusions. - L'emplacement et l'usage de la configuration utilisateur globale
~/.codex/config.tomlet de la configuration projet.codex/config.toml. - Les règles de priorité entre fichiers, ainsi qu'une limite de sécurité essentielle (certaines clés de configuration étant ignorées au niveau projet).
- Les principaux paramètres de configuration (
model,approval_policy,sandbox_mode,web_search,[features], etc.), leur rôle et leur valeur par défaut. - Des exemples pratiques pour appliquer une configuration minimale, surcharger un paramètre temporairement en ligne de commande avec
-c, et basculer d'un profil à un autre avec--profile.
01 Qu'est-ce que config.toml et quelle est sa différence avec AGENTS.md ?
En résumé : config.toml centralise les paramètres de comportement de Codex — il utilise le format TOML pour configurer les modèles, approbations, bac à sable, MCP et fonctionnalités de l'outil. Il se distingue d'AGENTS.md qui sert à documenter le contexte du projet pour Codex.
Il est fréquent de confondre ces deux fichiers au début. Le chapitre 11 · AGENTS.md expliquait comment documenter les spécificités du projet, tandis que le chapitre 15 · Permissions, bac à sable et approbations abordait les droits de modification de fichiers — les premières informations se placent dans AGENTS.md et les secondes dans config.toml.
Analogie : Le manuel d'utilisation d'un véhicule et les commandes du tableau de bord. Le fichier AGENTS.md ressemble au manuel d'utilisation rangé dans la boîte à gants : il contient des instructions en langage naturel à destination du conducteur (Codex) telles que « utiliser du carburant indice 95 » ou « laisser chauffer le moteur en hiver ». Il est lu comme contexte de référence à chaque démarrage de tâche. Le fichier config.toml correspond aux boutons physiques du tableau de bord : régler la température de la climatisation, activer le chauffage des sièges ou sélectionner le mode sport ou économique. Ce sont des interrupteurs configurés pour la machine. Le manuel donne des consignes, les boutons fixent le comportement technique.
Le format TOML (Tom's Obvious Minimal Language, un format de fichier de configuration simple à lire et à écrire) utilise des paires clé = valeur et des sections [nom_de_section]. Exemple de structure :
# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"La documentation officielle définit ainsi son rôle :
Codex enregistre la configuration de l'utilisateur à l'emplacement
~/.codex/config.toml.
Au quotidien, le fichier config.toml permet de répondre aux besoins suivants :
- « Définir un modèle par défaut pour éviter de le sélectionner manuellement à chaque session » — clé
model. - « Configurer par défaut les droits d'écriture sur le projet et la validation de sortie de zone » — clés
sandbox_modeetapproval_policy. - « Forcer la recherche web en temps réel au lieu d'utiliser le cache » — clé
web_search. - « Activer ou désactiver une fonctionnalité expérimentale » — section
[features].
Ces paramètres modifient directement le comportement d'exécution de l'outil, contrairement aux consignes rédigées dans AGENTS.md.
💡 En résumé : Le fichier
AGENTS.mdcontient les instructions en langage naturel pour Codex, tandis queconfig.tomlregroupe les paramètres de comportement technique de la machine. Le premier documente le contexte, le second configure le fonctionnement.
02 Emplacements du fichier : Niveau utilisateur et niveau projet
Avant d'analyser les paramètres, comprenons les deux emplacements possibles pour le fichier config.toml : l'un dans votre répertoire utilisateur global (valable pour tous les projets), l'autre au sein d'un projet spécifique (valable pour ce projet uniquement). Le piège mentionné en introduction provient de la confusion entre ces deux niveaux.
Analogie : Le disjoncteur général de la maison et l'interrupteur d'une pièce. Votre habitation dispose d'un disjoncteur général (dans l'entrée) qui définit les règles par défaut pour toute la maison, comme la limitation d'intensité globale. Chaque pièce dispose également de ses propres interrupteurs pour contrôler son éclairage local sans impacter les autres pièces. Les fichiers config.toml fonctionnent sur ce principe : la version utilisateur est le disjoncteur général, la version projet est l'interrupteur de la pièce.
Voici la répartition définie par la documentation :
| Niveau | Chemin du fichier | Impact | Usage | Condition requise |
|---|---|---|---|---|
| Utilisateur (User) | ~/.codex/config.toml | Tous vos projets | Paramètres personnels par défaut : modèle favori, permissions par défaut, MCP, notifications | Aucune |
| Projet (Project) | <repo>/.codex/config.toml | Projet en cours uniquement | Paramètres propres au projet : version de modèle spécifique, restrictions de sécurité locales | Projet marqué comme de confiance |
Trois règles essentielles sont à retenir :
Premièrement, le chemin utilisateur est fixe : ~/.codex/config.toml. Ce dossier ~/.codex (appelé CODEX_HOME) regroupe l'ensemble des données locales de Codex (configurations, jetons de connexion, historique, logs). Si le fichier config.toml n'existe pas dans ce répertoire, vous pouvez le créer manuellement.
Deuxièmement, la configuration projet doit être placée dans le sous-dossier .codex/ à la racine de votre dépôt (il s'agit d'un répertoire masqué .codex/config.toml, distinct du répertoire utilisateur ~/.codex). Ces paramètres ne s'appliquent que lorsque vous travaillez dans ce projet.
Troisièmement, la configuration projet n'est prise en compte que si le projet est marqué comme de confiance. C'est une sécurité intégrée par Codex pour éviter qu'un dépôt cloné ne modifie vos paramètres de sécurité locaux à votre insu. La documentation officielle le précise :
Si vous marquez un projet comme non fiable, Codex ignore les éléments du répertoire
.codex/local, y compris les configurations, hooks et règles propres au projet.
Par conséquent, si vous écrivez un fichier .codex/config.toml dans un projet non approuvé, il sera ignoré — seule votre configuration utilisateur globale s'appliquera. Si vos paramètres projet ne semblent pas pris en compte, vérifiez si vous avez bien accordé votre confiance au projet (lors de la demande d'approbation au premier accès au dossier).
Comment choisir l'emplacement adapté ?
Pour déterminer où placer une règle de configuration, posez-vous la question suivante : « Ce paramètre est-il lié à mes préférences personnelles de travail ou aux contraintes techniques de ce projet ? »
- Préférence personnelle de travail → Niveau utilisateur (
~/.codex/config.toml). Exemple : « Je souhaite utiliser le modèlegpt-5.5par défaut », configurer mes serveurs MCP globaux ou mes scripts de notification personnels. Ces règles s'appliqueront à tous vos projets. - Contrainte technique du projet → Niveau projet (
<repo>/.codex/config.toml). Exemple : « Ce projet utilise une version spécifique de modèle » ou « Ce projet sensible doit être configuré en lecture seule ». Ces paramètres sont enregistrés dans le dépôt Git et partagés avec l'équipe (si les membres marquent le projet comme fiable).
Conseil pratique : définissez vos habitudes de travail dans le fichier utilisateur global, et laissez le fichier projet vide par défaut. N'utilisez de configuration projet que pour des cas spécifiques (comme un dépôt client sensible pour lequel vous imposez sandbox_mode = "read-only"). Cela évite d'appliquer ces contraintes à vos autres projets.
💡 En résumé : Le fichier utilisateur
~/.codex/config.toml(dansCODEX_HOME) gère vos préférences globales, tandis que la version projet<repo>/.codex/config.tomlconfigure le dépôt en cours (sous réserve de confiance accordée au projet).
03 Gestion des priorités et limites de sécurité au niveau projet
Puisqu'un même paramètre peut être défini aux deux niveaux, quelle valeur l'emporte en cas de conflit ? Les règles de priorité (precedence) déterminent ce comportement.
En réalité, Codex évalue jusqu'à six niveaux de configuration (incluant les arguments de console, les profils de configuration et les configurations système). Voici l'ordre d'évaluation, du niveau le plus élevé au plus bas (la valeur supérieure écrase la valeur inférieure) :
| Priorité | Source de configuration | Rôle |
|---|---|---|
| 1 (Maximale) | Arguments CLI / Option --config | Surcharge temporaire pour la session en cours |
| 2 | Niveau Projet <repo>/.codex/config.toml | Paramètres propres au projet actif (si approuvé) |
| 3 | Profil de configuration (--profile) | Paramètres du fichier profil ~/.codex/<nom>.config.toml |
| 4 | Niveau Utilisateur ~/.codex/config.toml | Vos paramètres par défaut globaux |
| 5 | Niveau Système /etc/codex/config.toml (Unix, si présent) | Paramètres globaux imposés par l'administrateur |
| 6 (Minimale) | Valeurs par défaut de l'application | Paramètres d'usine de l'outil |
Visualisons cette structure sous forme de couches de configuration superposées :
Ce schéma illustre la superposition : la couche supérieure (arguments CLI) dispose de la priorité maximale et écrase les réglages des couches inférieures (projet, profil, utilisateur, etc.) pour les clés communes. Les paramètres les plus proches du contexte d'exécution immédiat l'emportent sur les configurations globales.
La documentation recommande d'exploiter cette logique de la manière suivante :
Utilisez ce système de priorité pour définir vos paramètres communs par défaut dans
config.toml, et réservez les profils de configuration aux seuls ajustements spécifiques.
En clair : le fichier utilisateur décrit votre fonctionnement habituel, les profils gèrent des variations d'usage spécifiques, et la ligne de commande applique les cas particuliers du moment.
Limite de sécurité au niveau projet : Clés restreintes
Bien que la configuration projet surcharge la configuration utilisateur, certains paramètres de sécurité système ne peuvent pas être définis au niveau projet. Si vous les utilisez dans un fichier .codex/config.toml local, ils seront ignorés par Codex et une alerte s'affichera au lancement.
Cette restriction vise à empêcher qu'un projet cloné ne redirige vos requêtes vers des serveurs tiers, ne modifie vos clés ou ne lance des commandes système masquées. La documentation liste les clés concernées :
Codex ignores les clés
openai_base_url,chatgpt_base_url,apps_mcp_product_sku,model_provider,model_providers,notify,profile,profiles,experimental_realtime_ws_base_urletotellorsqu'elles apparaissent dans un fichier.codex/config.tomllocal au projet.
Ces clés doivent obligatoirement être configurées dans le fichier utilisateur global :
| Clé de configuration | Rôle | Motif de la restriction |
|---|---|---|
model_provider / model_providers | Définition des serveurs et fournisseurs de modèles | Éviter le détournement de vos flux de requêtes |
openai_base_url / chatgpt_base_url | URL de base des services API | Sécuriser la destination de vos données |
notify | Commandes exécutées en fin de tâche | Empêcher l'exécution de scripts système masqués |
otel | Exportation des données de télémétrie et logs | Éviter la fuite de données d'exécution |
profile / profiles | Sélection du profil actif | Le choix du profil doit être fait en console et non imposé par le projet |
Retenez cette distinction : les paramètres d'infrastructure, de notification, de télémétrie ou de choix de profils s'inscrivent uniquement dans le fichier utilisateur global ; le fichier projet se limite aux réglages de fonctionnement locaux comme model, sandbox_mode ou approval_policy. Si un paramètre réseau comme model_providers configuré au niveau projet ne fonctionne pas, c'est qu'il est bloqué par cette règle de sécurité.
💡 En résumé : La priorité suit la logique la plus spécifique l'emporte (CLI > Projet > Profil > Utilisateur > Système > Usine). Cependant, le niveau projet ne peut pas modifier les paramètres d'infrastructure et de sécurité (comme
model_providerounotify) qui restent exclusifs à la configuration utilisateur.
04 Présentation des principaux paramètres de configuration
Bien que Codex supporte de nombreux paramètres (listés dans la référence de configuration officielle), la majorité des usages repose sur quelques options clés. Voici une présentation de ces options et de leurs valeurs par défaut pour vous aider à déterminer ce qu'il convient de configurer.
| Clé de configuration | Rôle | Valeur par défaut de l'application | Exemple d'écriture |
|---|---|---|---|
model | Modèle par défaut à utiliser | Défini par l'application | model = "gpt-5.5" |
approval_policy | Seuil de validation des commandes | on-request | approval_policy = "on-request" |
sandbox_mode | Limites d'accès système et réseau | workspace-write (si dépôt Git) | sandbox_mode = "workspace-write" |
model_reasoning_effort | Intensité du raisonnement du modèle | Géré par le modèle ou le profil | model_reasoning_effort = "high" |
web_search | Mode de recherche sur internet | cached (recherche sur cache) | web_search = "live" |
personality | Style de communication de l'IA | friendly | personality = "pragmatic" |
file_opener | Éditeur ciblé pour l'ouverture des liens de fichiers | vscode | file_opener = "cursor" |
Note concernant la valeur par défaut de
sandbox_mode: Le lancement classique decodexs'appuie sur le mode Auto — qui applique le modeworkspace-writedans les répertoires gérés par Git (accès en écriture au projet) et le moderead-onlydans les autres dossiers (lecture seule). La documentation désigneworkspace-writecomme le mode par défaut en référence au cas d'usage classique sur un dépôt Git.
Détaillons quelques paramètres importants :
Paramètres model, model_reasoning_effort, approval_policy et sandbox_mode
Ces clés ont été détaillées dans les chapitres correspondants (le choix du modèle au chapitre 05, le bac à sable et les approbations au chapitre 15). Définir ces clés dans config.toml permet de fixer ces comportements par défaut pour ne pas avoir à utiliser les commandes /model ou --sandbox à chaque session.
Le paramètre model_reasoning_effort accepte les valeurs minimal | low | medium | high | xhigh (selon le support du modèle). Choisissez une valeur basse pour les tâches simples afin de limiter la consommation et d'accélérer le traitement, ou high pour les tâches de programmation complexes.
web_search : Privilégier la recherche sur cache par défaut
Ce paramètre utilise une valeur par défaut axée sur la sécurité. Par défaut, la recherche web utilise la valeur cached : Codex interroge un index de résultats figés géré par OpenAI plutôt que de charger les pages web en direct. Cela limite l'exposition aux injections de requêtes (prompt injection) provenant de sites tiers.
Si vous devez effectuer des recherches d'actualité récente (comme la dernière version d'un package logiciel), la recherche sur cache peut renvoyer des informations obsolètes. Pour forcer la recherche en temps réel, modifiez ce paramètre :
web_search = "live" # Connexion en temps réel (équivaut à l'option CLI --search)
# web_search = "cached" # Valeur par défaut : consultation de l'index de cache
# web_search = "disabled" # Désactivation complète de l'outil de recherche webNotez que l'activation d'un bac à sable sans restriction (comme le mode --yolo) bascule automatiquement le paramètre web_search sur live.
personality : Style de communication
Le paramètre personality ajuste le ton employé par l'IA. Il accepte les valeurs none | friendly | pragmatic (et peut être modifié en cours de session avec /personality). La valeur pragmatic permet d'obtenir des réponses concises et directes, adaptées aux développeurs expérimentés.
file_opener : Association d'éditeur
Les chemins de fichiers affichés par Codex sous la forme nom_fichier.py:42 peuvent être cliquables. Le paramètre file_opener définit l'éditeur de code à lancer lors du clic. Il accepte les valeurs vscode | vscode-insiders | windsurf | cursor | none. Si vous développez avec Cursor, modifier cette valeur sur cursor permet d'ouvrir directement le fichier ciblé à la bonne ligne.
Syntaxe TOML : Ordre des éléments
C'est une erreur classique de configuration en format TOML. La spécification TOML impose que les déclarations de clés racines clé = valeur soient placées avant les définitions de sections [section]. La documentation le rappelle dans les commentaires de configuration :
Dans un fichier TOML, les clés de premier niveau (root keys) doivent impérativement être écrites avant les déclarations de tables.
Exemple de distinction de syntaxe :
| ❌ Syntaxe incorrecte (clé racine après une section) | ✅ Syntaxe correcte (clés racines en premier) |
|---|---|
[features]hooks = truemodel = "gpt-5.5" (provoque une erreur) | model = "gpt-5.5"[features]hooks = true |
Prenez l'habitude de lister l'ensemble de vos paramètres simples (comme model ou approval_policy) en début de fichier, avant de déclarer vos blocs de sections [features] ou d'outils.
💡 En résumé : Les principaux paramètres à gérer sont
model,approval_policy,sandbox_mode,model_reasoning_effort,web_search(surcachedpar défaut par sécurité),personalityetfile_opener. Respectez la structure TOML en plaçant vos clés simples avant les sections[table].
05 La section [features] : Activer les fonctionnalités optionnelles
La section [features] regroupe les interrupteurs d'activation des fonctionnalités optionnelles ou expérimentales de Codex (telles que le système de mémoire, les hooks de cycle de vie ou les collaborations de sous-agents).
Analogie : Les fonctionnalités expérimentales dans les paramètres de votre smartphone. Les fonctions stables sont actives d'office, mais une section « Fonctionnalités expérimentales » regroupe des options activables manuellement. Le bloc [features] joue ce rôle dans Codex : chaque fonctionnalité est associée à un booléen (true ou false) ; l'absence de mention laisse Codex appliquer son comportement par défaut.
Exemple de structure de section :
[features]
memories = true # Active le système de mémoire (Memories)
shell_snapshot = true # Active les captures de console pour accélérer l'exécution
hooks = false # Désactive les hooks de cycle de vieVoici la liste des fonctionnalités courantes et leurs valeurs par défaut :
| Clé de fonctionnalité | Valeur par défaut | Statut | Rôle |
|---|---|---|---|
hooks | true | Stable | Exécution de scripts liés aux événements du projet (hooks) |
multi_agent | true | Stable | Collaboration et délégation à des sous-agents |
shell_snapshot | true | Stable | Optimisation de l'environnement console pour accélérer les commandes |
fast_mode | true | Stable | Exécution rapide limitant les temps d'attente de réponse |
shell_tool | true | Stable | Accès à la console pour lancer des commandes système |
personality | true | Stable | Prise en compte du style de communication configuré |
memories | false | Stable | Système de mémoire à long terme (détaillé au chapitre 19) |
codex_git_commit | false | Expérimental | Génération automatique des messages de commit Git par Codex |
apps | false | Expérimental | Prise en charge des applications et connecteurs ChatGPT |
undo | false | Stable | Possibilité d'annuler les modifications via des snapshots Git |
⚠️ Fonctionnalités sujettes à modification : Les options notées « Expérimental » ou leurs comportements par défaut peuvent évoluer avec les versions de l'outil. Consultez la référence de configuration officielle de votre version avant de les activer.
Attention aux anciennes dénominations dans vos fichiers de configuration : des clés comme codex_hooks pour activer les hooks sont obsolètes. La documentation officielle impose désormais la clé courte hooks. Utilisez les clés à jour.
Trois méthodes permettent de modifier ces fonctionnalités :
- Dans
config.toml: Déclarer la clé sous la table[features]. - Temporairement en console : Lancer Codex avec l'option
--enable nom_feature(ou spécifier plusieurs--enablesuccessifs). - Désactiver : Déclarer la clé sur
falsedans votre fichier de configuration.
Recommandation pratique : conservez les paramètres par défaut à vos débuts. N'activen le système de mémoire (via memories = true) ou d'autres options que si vous en avez un besoin identifié. Cumuler les options expérimentales peut rendre le diagnostic des erreurs complexe.
💡 En résumé : Le bloc
[features]centralise l'activation des options de l'outil via des valeurs booléennes. Les options stables (commehooksoumulti_agent) sont actives par défaut, tandis que les fonctions avancées commememoriesexigent une activation manuelle. Fiez-vous aux noms de clés officiels.
06 Surcharges ponctuelles et profils de configuration (options -c et --profile)
Pour répondre aux besoins de modification temporaire d'un paramètre ou de gestion de profils de configuration multiples, Codex propose deux approches complémentaires.
Surcharge temporaire : L'option -c / --config
Si vous souhaitez tester un paramètre sans éditer vos fichiers de configuration, vous pouvez le surcharger directement au lancement en console :
# Pour les paramètres disposant d'une option dédiée
codex --model gpt-5.4
# Pour les autres paramètres, utilisez l'option générique -c (en syntaxe TOML, pas JSON)
codex --config model='"gpt-5.4"'
codex -c log_dir=./.codex-logDeux points de vigilance techniques sont décrits dans la documentation :
- La valeur fournie à
-cest interprétée au format TOML, et non JSON. Les chaînes de caractères exigent des guillemets internes (commemodel='"gpt-5.4"'où les guillemets simples protègent la commande shell et les guillemets doubles définissent la chaîne TOML). Encadrez vos valeurs complexes pour éviter les erreurs d'interprétation par la console. - Les clés imbriquées se déclarent avec un point, par exemple :
codex -c mcp_servers.context7.enabled=false.
Cette méthode est idéale pour tester l'impact d'une clé avant de l'enregistrer de façon permanente dans votre configuration.
Profils de configuration : L'option --profile
Comme évoqué au chapitre 15, un profil de configuration regroupe un ensemble de paramètres spécifiques au sein d'un fichier dédié dans votre répertoire CODEX_HOME, nommé <nom_profil>.config.toml :
# ~/.codex/deep-review.config.toml
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"Vous l'activez au démarrage avec l'option --profile :
codex --profile deep-review
codex exec --profile deep-review "review this change"Lors de l'appel, Codex charge d'abord votre fichier utilisateur global config.toml, puis applique les surcharges définies dans deep-review.config.toml. Inscrivez uniquement les clés qui diffèrent de votre configuration habituelle dans vos fichiers profils.
Notez une évolution importante de la gestion des profils :
⚠️ Changement de comportement à partir de la version 0.134.0. Les versions récentes de Codex n'acceptent plus la déclaration de blocs de profils sous la forme
[profiles.nom_profil]au sein du fichierconfig.tomlprincipal, ni l'usage de la cléprofile = "nom_profil". Les profils doivent obligatoirement être déclarés dans des fichiers individuels distincts nommés~/.codex/<nom_profil>.config.tomlet appelés en console. Fiez-vous aux messages de votre version en cas d'erreur.
Vous pouvez par exemple créer un profil quick (modèle léger, lecture seule pour l'analyse de code) et un profil build (modèle performant, droits d'écriture pour la production). Lancer codex --profile build configure instantanément votre session sans modification manuelle.
💡 En résumé : L'option
-cpermet de surcharger temporairement un paramètre au format TOML au lancement, tandis que--profileapplique les surcharges d'un fichier<nom_profil>.config.tomldistinct. La déclaration des profils s'effectue dans des fichiers séparés sur les versions récentes.
07 En pratique : Créer, tester et surcharger une configuration
Voici un exercice pour valider la prise en compte de vos configurations globales, de la surcharge temporaire et des profils dans un dossier de test.
Étape 1 : Localiser votre répertoire de configuration
Vérifiez la présence du fichier de configuration utilisateur dans votre terminal :
ls -la ~/.codex/config.tomlSi le fichier n'est pas présent, créez-le.
Étape 2 : Écrire une configuration utilisateur minimale
Ajoutez ces lignes dans votre fichier ~/.codex/config.toml (veillez à ce que les clés racines soient écrites avant les blocs de sections) :
# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
web_search = "cached"
[features]
memories = falseÉtape 3 : Vérifier le chargement du fichier
Lancez Codex dans votre console :
codexUne fois la session active, affichez le statut :
/statusComportement attendu : L'état retourné par /status (modèle sélectionné, stratégie d'approbation) doit correspondre aux valeurs définies dans votre fichier ~/.codex/config.toml utilisateur. Quittez la session.
Étape 4 : Tester la surcharge ponctuelle
Relancez Codex en modifiant temporairement la recherche web avec l'option -c :
codex -c web_search='"live"'Affichez à nouveau l'état de la session avec /status.
Comportement attendu : Le mode de recherche web doit indiquer live pour cette session. Ouvrez ensuite le fichier ~/.codex/config.toml dans votre éditeur de texte : la ligne web_search = "cached" est restée inchangée. La surcharge ponctuelle a fonctionné sans altérer votre fichier de configuration. Quittez la session.
Étape 5 : Créer et charger un profil spécifique
Créez un fichier profil nommé ~/.codex/strict.config.toml contenant des droits restreints :
# ~/.codex/strict.config.toml
model = "gpt-5.5"
sandbox_mode = "read-only"
approval_policy = "untrusted"Lancez Codex en appelant ce profil :
codex --profile strictVérifiez l'état de la session avec /status.
Comportement attendu : Le mode bac à sable affiche read-only et la stratégie d'approbation indique untrusted, conformément au profil strict qui s'est superposé à votre configuration globale. Relancer Codex sans l'option --profile restaurera vos paramètres habituels.
Ce test valide la bonne prise en compte de vos différents niveaux de configuration.
💡 En résumé : L'exercice valide la création de votre configuration de base, la vérification du statut avec
/status, la surcharge ponctuelle avec-cet l'application d'un profil de restriction avec--profile.
08 Résumé
Ce chapitre a détaillé le fonctionnement et la structure du fichier de configuration config.toml pour vous permettre d'adapter Codex à vos habitudes de travail.
Voici un récapitulatif des règles à retenir :
| Concept | Rôle | Règle clé |
|---|---|---|
| Rôles des fichiers | config.toml configure la machine, AGENTS.md documente le code. | Ne confondez pas instructions textuelles et clés techniques. |
| Localisation | Configuration utilisateur dans ~/.codex/, configuration projet dans .codex/ local. | Le fichier projet n'est chargé que si le projet est approuvé comme fiable. |
| Priorités | CLI > Projet > Profil > Utilisateur > Système > Valeurs par défaut. | La règle la plus proche du contexte d'exécution l'emporte. |
| Restriction projet | Certaines clés système (fournisseurs, URL de base, notifications) sont ignorées au niveau projet. | Ces clés de sécurité doivent être définies au niveau utilisateur. |
| TOML | Structure de fichier. | Écrivez les clés simples en début de fichier, avant les sections [table]. |
| Ajustements | Option -c pour modifier une clé, --profile pour appeler un fichier profil. | Les profils récents s'écrivent dans des fichiers individuels distincts. |
Vous êtes désormais en mesure de organiser vos configurations entre le niveau utilisateur global et le niveau projet, de respecter la hiérarchie des priorités d'évaluation, d'éviter d'inscrire des clés système restreintes au niveau projet, de structurer correctement vos fichiers au format TOML, d'activer les fonctionnalités optionnelles dans le bloc [features], et d'exploiter les options de surcharges -c et de profils --profile.
Le chapitre suivant 19 · Système de mémoire (Memories et Chronicle) présente l'activation du paramètre memories : comment permettre à Codex de conserver des informations d'une session à l'autre ? Comment l'assistant structure-t-il ses souvenirs, comment corriger ou nettoyer sa mémoire, et comment exploiter ce contexte persistant ? Nous verrons comment donner une mémoire à long terme à notre assistant de programmation.