For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale

Principes de configuration

Découvrez les principes de configuration de votre client Codex local

Codex lit les informations de configuration à plusieurs emplacements. Vos paramètres personnels par défaut sont stockés dans ~/.codex/config.toml, et vous pouvez les remplacer au niveau d’un projet à l’aide de fichiers .codex/config.toml. Par mesure de sécurité, Codex ne charge les couches .codex/ propres à un projet que si vous avez déclaré ce projet fiable.

Fichier de configuration de Codex

Codex stocke la configuration utilisateur dans ~/.codex/config.toml. Pour limiter certains paramètres à un projet ou à un sous-dossier spécifique, ajoutez un fichier .codex/config.toml dans votre dépôt.

Pour ouvrir le fichier de configuration depuis l’extension IDE Codex, sélectionnez l’icône d’engrenage en haut à droite, puis Paramètres Codex > Ouvrir config.toml.

La CLI et l’extension IDE partagent les mêmes couches de configuration. Vous pouvez les utiliser pour les opérations suivantes :

Ordre de priorité de la configuration

Codex détermine les valeurs dans l’ordre suivant (de la priorité la plus élevée à la plus faible) :

  1. Options de la CLI et remplacements via --config
  2. Fichiers de configuration du projet : .codex/config.toml, appliqués dans l’ordre de la racine du projet jusqu’au répertoire de travail actuel (le plus proche prévaut ; projets déclarés fiables uniquement)
  3. Fichiers de profil sélectionnés avec --profile profile-name (~/.codex/profile-name.config.toml)
  4. Configuration utilisateur : ~/.codex/config.toml
  5. Paramètres par défaut de config.toml gérés dans le cloud, lorsqu’ils sont fournis pour l’espace de travail auquel vous êtes connecté
  6. Configuration système (si elle existe) : /etc/codex/config.toml sous Unix
  7. Paramètres par défaut intégrés

Appuyez-vous sur cet ordre de priorité pour définir les paramètres par défaut communs dans config.toml et ne conserver dans les fichiers de profil que les valeurs qui diffèrent.

La configuration gérée dans le cloud et la configuration système peuvent définir des marketplaces de plugins et déterminer si les plugins sont activés par défaut. Ces paramètres sont distincts des politiques imposées par requirements.toml. Consultez Configurez les marketplaces de plugins et les paramètres par défaut.

Si vous déclarez un projet non fiable, Codex ignore les couches .codex/ propres au projet, y compris sa configuration locale, ses hooks et ses règles. Les configurations utilisateur et système restent chargées, y compris les hooks et les règles utilisateur et globaux.

Pour effectuer des remplacements ponctuels via -c/--config (y compris les règles d’utilisation des guillemets en TOML), consultez Configuration avancée.

Sur les machines gérées, votre organisation peut également imposer des contraintes via requirements.toml (par exemple, interdire approval_policy = "never" ou sandbox_mode = "danger-full-access"). Consultez Configuration gérée et Exigences imposées par l’administrateur.

Options de configuration courantes

Voici quelques-unes des options les plus souvent modifiées :

Modèle par défaut

Choisissez le modèle que Codex utilise par défaut dans la CLI et l’IDE.

model = "gpt-5.6"

Demandes d’approbation

Définissez quand Codex s’interrompt 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 Exécutez sans demandes d’approbation et Combinaisons courantes de paramètres du bac à sable et d’approbation. Si une configuration existante utilise approval_policy = "untrusted", consultez Migrez depuis l’ancienne politique d’approbation untrusted, désormais supprimée.

Niveau du bac à sable

Ajustez l’étendue de l’accès au système de fichiers et au réseau dont dispose Codex lors de l’exécution des commandes.

sandbox_mode = "workspace-write"

Pour connaître le comportement de chaque mode (y compris les chemins protégés .git/.codex et les paramètres réseau par défaut), consultez 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 des profils d’autorisations nommés pour réutiliser les 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. Les profils personnalisés utilisent des tables [permissions.<name>] et une valeur default_permissions correspondante. Consultez Autorisations.

Mode du bac à sable Windows

Lorsque vous exécutez Codex de manière native sur Windows, définissez le mode du bac à sable natif sur elevated dans la table windows. Utilisez unelevated uniquement si vous ne disposez pas des droits d’administrateur ou si la configuration avec élévation des privilèges échoue.

[windows]
sandbox = "elevated"   # Recommended
# sandbox = "unelevated" # Fallback if admin permissions/setup are unavailable

Mode de recherche web

Codex active la recherche web par défaut pour les discussions locales et fournit les résultats à partir d’un cache de recherche web. Ce cache est un index de résultats web maintenu par OpenAI : le mode avec cache renvoie donc des résultats pré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 arbitraires récupérés en direct, mais vous devez toujours considérer les résultats web comme non fiables. Si vous utilisez --yolo ou un autre paramètre du bac à sable offrant un accès complet, la recherche web utilise par défaut les résultats en direct. Choisissez un mode avec web_search :

  • "cached" (par défaut) fournit les résultats à partir du cache de recherche web.
  • "indexed" n’autorise l’accès au web externe que lorsque la requête est soumise au 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

Ajustez l’effort de raisonnement du modèle lorsque celui-ci prend en charge ce réglage.

model_reasoning_effort = "high"

Style de communication

Définissez un style de communication par défaut pour les modèles compatibles.

personality = "friendly" # or "pragmatic" or "none"

Vous pouvez modifier ce paramètre ultérieurement dans une session active avec /personality, ou pour chaque fil ou tour lorsque vous utilisez les API app-server.

Raccourcis clavier de la TUI

Personnalisez les raccourcis du terminal dans tui.keymap. Certaines actions de la zone de saisie utilisent les raccourcis correspondants de tui.keymap.global en dernier recours ; les raccourcis propres au contexte sont prioritaires lorsqu’ils sont pris en charge. Une liste vide supprime les raccourcis associés à l’action.

[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 lancées. Utilisez des filtres par clé pour ne conserver que les variables dont vous avez besoin :

[shell_environment_policy]
ignore_default_excludes = false

[shell_environment_policy.filters]
"PATH" = "include"
"HOME" = "include"

ignore_default_excludes vaut true par défaut, ce qui désactive le filtrage automatique des variables dont le nom contient KEY, SECRET ou TOKEN. Définissez ce paramètre sur false pour activer ce filtrage automatique. Pour les règles d’exclusion, l’ordre de priorité et l’ancienne configuration, consultez Politique d’environnement du shell.

Répertoire des journaux

Modifiez l’emplacement où Codex écrit les fichiers journaux locaux. Définir explicitement log_dir active également le journal facultatif en texte brut de la TUI, codex-tui.log, dans ce répertoire.

log_dir = "/absolute/path/to/codex-logs"

Pour une exécution ponctuelle, vous pouvez aussi le définir depuis la CLI :

codex -c log_dir=./.codex-log

Indicateurs de fonctionnalités

Utilisez la table [features] dans config.toml pour activer ou désactiver les fonctionnalités facultatives et expérimentales.

Indicateurs de fonctionnalités courants

CléValeur par défautMaturitéDescription
appstrueStableActivez les intégrations d’applications (connecteurs)
goalstrueStableActivez les objectifs persistants et la poursuite automatique
hookstrueStableActivez les hooks de cycle de vie définis dans hooks.json ou directement dans [hooks]. Consultez Hooks.
fast_modetrueStableActivez la sélection du mode Rapide et son utilisation via service_tier = "fast"
memoriesfalseExpérimentalActivez les Mémoires
multi_agenttrueStableActivez les outils de collaboration entre sous-agents
personalitytrueStableActivez les commandes de sélection de la personnalité
remote_plugintrueStableActivez le catalogue de plugins à distance
shell_snapshottrueStableCréez un instantané de votre environnement shell pour accélérer les commandes répétées
shell_tooltrueStableActivez l’outil shell par défaut
unified_exectrue sauf sur WindowsStableUtilisez l’outil exec unifié reposant sur un PTY
web_searchtrueObsolèteAncienne option d’activation ; privilégiez le paramètre web_search de premier niveau
web_search_cachedfalseObsolèteAncienne option d’activation correspondant à web_search = "cached" lorsqu’aucune valeur n’est définie
web_search_requestfalseObsolèteAncienne option d’activation correspondant à web_search = "live" lorsqu’aucune valeur n’est définie

Ce tableau présente les options courantes destinées aux utilisateurs, et non 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 Maturité des fonctionnalités pour savoir comment interpréter ces libellés.

Omettez les clés des fonctionnalités pour conserver leurs valeurs par défaut.

Pour configurer les hooks de cycle de vie, consultez Hooks.

Activation des fonctionnalités

  • Dans config.toml, ajoutez feature_name = true sous [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é, définissez sa clé sur false dans config.toml.