Codex lit sa configuration à plusieurs emplacements. Vos paramètres personnels par défaut se trouvent dans ~/.codex/config.toml. Vous pouvez les remplacer pour un projet à l’aide de fichiers .codex/config.toml. Par sécurité, Codex ne charge les couches de configuration .codex/ d’un projet que si vous lui faites confiance.
Fichier de configuration de Codex
Codex enregistre votre configuration utilisateur dans ~/.codex/config.toml. Pour appliquer des paramètres à un projet ou à un sous-dossier précis, ajoutez un fichier .codex/config.toml à l’emplacement voulu dans votre dépôt.
Pour ouvrir le fichier de configuration depuis l’extension Codex pour IDE, sélectionnez l’icône en forme d’engrenage en haut à droite, puis Codex Settings > Open config.toml.
La CLI et l’extension pour IDE utilisent les mêmes couches de configuration. Elles vous permettent de :
- Définir le modèle et le fournisseur par défaut.
- Configurer les politiques d’approbation et les paramètres du bac à sable.
- Configurer les serveurs MCP.
Ordre de priorité de la configuration
Les exigences imposent des contraintes, tandis que la configuration définit les valeurs par défaut. L’accès à un ordinateur local avec Work Cloud obéit aux règles suivantes :
- Entre plusieurs politiques : une politique de priorité supérieure l’emporte sur une politique de priorité inférieure, même si cette dernière est plus spécifique.
- Au sein d’une même politique : les paramètres d’environnement propres à un système d’exploitation priment sur ceux qui s’appliquent à tous les systèmes d’exploitation. Les paramètres Global viennent en dernier.
- Pour l’exécution locale : les exigences MDM et les anciennes exigences applicables aux appareils gérés priment sur celles d’Agent Security. Agent Security prime à son tour sur le fichier d’exigences système de l’appareil.
- Pour Work Cloud : les conteneurs cloud du mode Work conservent les politiques Work Cloud existantes. Pour le mode Work avec accès local et pour les dots, lorsque la politique gérée est activée, la politique Global prise en charge régit l’orchestrateur cloud partagé. Les exigences d’exécution locale applicables régissent l’ordinateur connecté.
Pour certaines exigences, les règles de fusion varient selon le champ. Consultez la configuration gérée pour connaître la portée des politiques et les limites d’exécution, et la référence de configuration pour vérifier la compatibilité avec le mode Work.
Codex détermine les valeurs à appliquer dans l’ordre de priorité décroissant suivant :
- Options de la CLI et valeurs définies avec
--config - Fichiers de configuration du projet :
.codex/config.toml, de la racine du projet jusqu’au répertoire de travail courant (le fichier le plus proche l’emporte, uniquement pour les projets de confiance) - Fichiers de profil sélectionnés avec
--profile profile-name(~/.codex/profile-name.config.toml) - Configuration utilisateur :
~/.codex/config.toml - Valeurs par défaut de
config.tomlgérées dans le cloud, lorsqu’elles sont fournies pour l’espace de travail auquel vous êtes connecté - Configuration système (si elle existe) :
/etc/codex/config.tomlsous Unix - Valeurs par défaut intégrées
Tirez parti de cet ordre de priorité pour définir les valeurs par défaut communes dans config.toml et ne placer dans les fichiers de profil que les valeurs qui diffèrent.
La configuration gérée dans le cloud et la configuration système permettent de définir des marketplaces de plugins et d’indiquer si les plugins sont activés par défaut. Ces paramètres sont distincts des politiques imposées par requirements.toml. Consultez la section Configurer les marketplaces de plugins et les paramètres par défaut.
Si vous indiquez qu’un projet n’est pas de confiance, Codex ignore les couches .codex/ propres au projet, y compris sa configuration locale, ses hooks et ses règles. Codex charge toujours les configurations utilisateur et système, y compris les hooks et les règles de portée utilisateur ou globale.
Pour remplacer ponctuellement des valeurs avec -c/--config et connaître les règles d’utilisation des guillemets en TOML, consultez la configuration avancée.
Sur les machines gérées, votre organisation peut aussi imposer des contraintes via
requirements.toml, par exemple en interdisant approval_policy = "never" ou
sandbox_mode = "danger-full-access". Consultez la configuration gérée et les exigences imposées par l’administrateur.
Options de configuration courantes
Voici quelques-uns des paramètres les plus souvent modifiés.
Modèle par défaut
Choisissez le modèle que Codex utilise par défaut dans la CLI et l’IDE.
model = "gpt-6.1-sol"Demandes d’approbation
Définissez quand Codex doit s’interrompre pour demander votre approbation avant d’exécuter les commandes générées.
approval_policy = "on-request"Pour connaître les différences de comportement entre on-request et never, consultez les sections Exécuter des commandes sans demande d’approbation et Combinaisons courantes de paramètres de bac à sable et d’approbation. Si une configuration existante utilise approval_policy = "untrusted", consultez la section Migrer depuis l’ancienne politique d’approbation untrusted.
Niveau d’accès du bac à sable
Réglez le niveau d’accès de Codex au système de fichiers et au réseau pendant l’exécution des commandes.
sandbox_mode = "workspace-write"Pour connaître le comportement de chaque mode, notamment la protection des chemins .git, .agents, .codex et .aws et les paramètres réseau par défaut, consultez les sections Bac à sable et approbations, Chemins protégés dans les répertoires racines accessibles en écriture et Accès réseau.
Profils d’autorisations
Codex prend également en charge les profils d’autorisations nommés, qui permettent de réutiliser des politiques d’accès au système de fichiers et au réseau. Les profils intégrés sont :read-only, :workspace et :danger-full-access. Pour les profils personnalisés, utilisez des tables [permissions.<name>] et une valeur default_permissions correspondant au profil voulu. Consultez la section Autorisations.
Mode de bac à sable sous Windows
Sous Windows, privilégiez MXC lorsque l’appareil et la politique le permettent. Configurez une ancienne implémentation comme solution de repli :
[windows]
sandbox = "elevated" # Legacy fallback
[features]
prefer_mxc = trueN’utilisez unelevated que si la configuration avec élévation de privilèges est indisponible et que la politique de votre organisation le permet. Consultez le guide du bac à sable Windows pour connaître les limites de compatibilité et les options de déploiement.
Mode de recherche web
Codex active la recherche web par défaut dans les discussions locales et fournit des résultats issus d’un cache de recherche web. Ce cache est un index de résultats web tenu à jour par OpenAI. En mode cache, Codex renvoie donc des résultats déjà indexés au lieu de récupérer les pages en direct. Cela réduit l’exposition aux attaques par injection de prompt provenant de contenus web consultés en direct. Traitez les résultats web comme des données non fiables. Si vous utilisez --yolo ou un autre paramètre de bac à sable accordant un accès complet, la recherche web fournit par défaut des résultats en direct. Choisissez un mode avec web_search :
"cached"(par défaut) fournit les résultats du cache de recherche web."indexed"autorise l’accès au Web externe uniquement si la requête passe par le contrôle de l’index de recherche."live"récupère les données les plus récentes sur le Web (comme--search)."disabled"désactive l’outil de recherche web.
web_search = "cached" # default; serves results from the web search cache
# web_search = "indexed" # gate external web access through the search index
# web_search = "live" # fetch the most recent data from the web (same as --search)
# web_search = "disabled"Effort de raisonnement
Réglez l’effort que le modèle consacre au raisonnement s’il prend en charge ce paramètre.
model_reasoning_effort = "medium"Style de communication
Pour omettre les instructions de personnalité intégrées, utilisez le réglage suivant :
personality = "none"Ce réglage supprime la section Personality des instructions intégrées du modèle. Il ne modifie pas les instructions de base personnalisées que vous avez explicitement définies. Les anciennes valeurs friendly et pragmatic ne permettent plus de sélectionner un style. Codex ne propose plus la commande /personality.
Raccourcis clavier de l’interface du terminal
Personnalisez les raccourcis du terminal dans tui.keymap. Certaines actions de la zone de saisie utilisent par défaut les raccourcis correspondants de tui.keymap.global. Les raccourcis propres au contexte sont prioritaires lorsqu’ils sont pris en charge. Une liste vide dissocie l’action de tout raccourci.
[tui.keymap.global]
open_transcript = "ctrl-t"
[tui.keymap.composer]
submit = ["enter", "ctrl-m"]
[tui.keymap.chat]
interrupt_turn = "f12"Environnement des commandes
Définissez les variables d’environnement que Codex transmet aux commandes qu’il lance. Pour ne conserver que les variables dont vous avez besoin, filtrez-les par nom :
[shell_environment_policy]
ignore_default_excludes = false
[shell_environment_policy.filters]
"PATH" = "include"
"HOME" = "include"Par défaut, ignore_default_excludes vaut true : Codex ne filtre donc pas automatiquement les variables dont le nom contient KEY, SECRET ou TOKEN. Définissez ce paramètre sur false pour activer ce filtrage automatique. Pour connaître les règles d’exclusion, leur ordre de priorité et les anciennes options de configuration, consultez la politique d’environnement du shell.
Répertoire des journaux
Choisissez où Codex écrit ses fichiers journaux locaux. Définir explicitement log_dir active également la journalisation facultative en texte clair de l’interface du terminal dans le fichier codex-tui.log de ce répertoire.
log_dir = "/absolute/path/to/codex-logs"Pour une exécution ponctuelle, vous pouvez aussi définir ce répertoire depuis la CLI :
codex -c log_dir=./.codex-logIndicateurs de fonctionnalité
Utilisez la table [features] de config.toml pour activer ou désactiver des fonctionnalités facultatives et expérimentales.
Indicateurs de fonctionnalité courants
| Clé | Valeur par défaut | Maturité | Description |
|---|---|---|---|
apps |
true | Stable | Active les intégrations d’applications (connecteurs) |
goals |
true | Stable | Active la sauvegarde des objectifs et leur poursuite automatique |
hooks |
true | Stable | Active les hooks de cycle de vie définis dans hooks.json ou directement dans [hooks]. Consultez la section Hooks. |
fast_mode |
true | Stable | Permet de sélectionner le mode Rapide et d’utiliser service_tier = "fast" |
memories |
false | Stable | Active les Mémoires |
multi_agent |
true | Stable | Active les outils de collaboration entre sous-agents |
remote_plugin |
true | Stable | Active le catalogue distant de plugins |
shell_snapshot |
true | Stable | Crée un instantané de votre environnement shell pour accélérer les commandes exécutées à plusieurs reprises |
shell_tool |
true | Stable | Active les outils d’exécution de commandes |
unified_exec |
true | Stable | Permet de reprendre l’exécution des commandes. Seules les exigences gérées peuvent désactiver cette fonctionnalité |
web_search |
true | Obsolète | Ancien indicateur. Privilégiez le paramètre de premier niveau web_search |
web_search_cached |
false | Obsolète | Ancien indicateur qui équivaut à web_search = "cached" si le paramètre de premier niveau n’est pas défini |
web_search_request |
false | Obsolète | Ancien indicateur qui équivaut à web_search = "live" si le paramètre de premier niveau n’est pas défini |
Ce tableau présente les indicateurs courants accessibles aux utilisateurs. Il ne recense pas toutes les fonctionnalités internes ou en cours de développement. La colonne Maturité utilise des libellés tels que « Expérimental », « Bêta » et « Stable ». Consultez la section Maturité des fonctionnalités pour savoir comment les interpréter.
Pour configurer les hooks de cycle de vie, consultez la section Hooks.
Activation des fonctionnalités
- Dans
config.toml, ajoutezfeature_name = truesous[features]. - Depuis la CLI, exécutez
codex --enable feature_name. - Pour activer plusieurs fonctionnalités, exécutez
codex --enable feature_a --enable feature_b. - Pour désactiver une fonctionnalité, attribuez la valeur
falseà sa clé dansconfig.toml.