Autorisations de l’agent et sécurité

Codex contribue à protéger votre code et vos données et réduit le risque d’utilisation abusive.

Par défaut, l’agent s’exécute sans accès au réseau. En local, Codex utilise un bac à sable imposé par le système d’exploitation, qui limite ses accès, généralement à l’espace de travail actuel. Une politique d’approbation détermine également quand il doit s’arrêter et vous demander votre accord avant d’agir.

Pour une explication générale du fonctionnement du bac à sable dans l’application de bureau ChatGPT, Codex CLI et l’extension IDE, consultez la page Bac à sable. Pour une vue d’ensemble plus large de la sécurité en entreprise, consultez le livre blanc sur la sécurité de Codex.

Migrez depuis la politique d’approbation untrusted, désormais retirée

Codex et ChatGPT Work ne prennent plus en charge approval_policy = "untrusted". Ce paramètre retiré peut empêcher le démarrage de l’un ou l’autre client. Supprimez-le de la configuration utilisateur ou du projet, des fichiers de profil, des scripts de démarrage et des paramètres par défaut gérés. Pour une utilisation interactive en lecture seule :

sandbox_mode = "read-only"
approval_policy = "on-request"

Ou exécutez codex --sandbox read-only --ask-for-approval on-request.

Avec on-request, les commandes autorisées par le bac à sable peuvent s’exécuter sans approbation, lire les fichiers accessibles et utiliser l’accès au réseau s’il est activé.

Pour conserver la règle d’approbation des commandes plus stricte, ne définissez pas explicitement approval_policy et ajoutez une entrée pour le projet dans votre fichier de configuration utilisateur ~/.codex/config.toml :

[projects."/path/to/project"]
trust_level = "untrusted"

Les commandes nécessitent alors une approbation, sauf si une règle de la politique d’exécution les autorise. Cela désactive également la configuration locale du projet. Définir explicitement on-request remplace la politique déduite du projet ; le paramètre géré allowed_approval_policies doit inclure untrusted pour autoriser cette politique.

Bac à sable et approbations

Les contrôles de sécurité de Codex reposent sur deux couches complémentaires :

• Mode du bac à sable : ce que Codex peut faire techniquement (par exemple, où il peut écrire et s’il peut accéder au réseau) lorsqu’il exécute des commandes générées par le modèle.
• Politique d’approbation : les situations dans lesquelles Codex doit vous demander votre accord avant d’exécuter une action (par exemple, sortir du bac à sable, utiliser le réseau ou exécuter des commandes hors d’un ensemble de confiance).

Codex utilise différents modes de bac à sable selon l’endroit où vous l’exécutez :

• Codex Cloud : s’exécute dans des conteneurs isolés gérés par OpenAI, ce qui empêche l’accès à votre système hôte ou à des données sans rapport avec la tâche. L’exécution se déroule en deux phases : la configuration précède la phase de l’agent et peut accéder au réseau pour installer les dépendances spécifiées. La phase de l’agent s’exécute ensuite hors ligne par défaut, sauf si vous activez l’accès Internet pour cet environnement. Les secrets configurés pour les environnements cloud sont disponibles uniquement pendant la configuration et sont supprimés avant le début de la phase de l’agent.
• Codex CLI / extension IDE : des mécanismes du système d’exploitation appliquent les politiques du bac à sable. Par défaut, l’accès au réseau est désactivé et les autorisations d’écriture sont limitées à l’espace de travail actif. Vous pouvez configurer le bac à sable, la politique d’approbation et les paramètres réseau en fonction de votre tolérance au risque.

Avec le préréglage Auto (par exemple, --sandbox workspace-write --ask-for-approval on-request), Codex peut automatiquement lire des fichiers, effectuer des modifications et exécuter des commandes dans le répertoire de travail.

Codex demande une approbation pour modifier des fichiers en dehors de l’espace de travail ou exécuter des commandes nécessitant un accès au réseau. Si vous souhaitez discuter ou planifier sans effectuer de modifications, passez en mode read-only avec la commande /permissions.

Codex peut également demander une approbation pour les appels aux outils d’applications (connecteurs) qui déclarent des effets de bord, même si l’action n’est ni une commande shell ni une modification de fichier. Les appels destructifs aux outils d’applications ou MCP nécessitent toujours une approbation lorsque l’outil déclare une annotation de caractère destructif (sauf s’il déclare une annotation de lecture, qui est prioritaire).

Surveillance de sécurité et tâches en pause

GPT-6 Astra intègre une surveillance de sécurité dans Codex et ChatGPT Work. Cette surveillance s’exécute de manière asynchrone et peut mettre une tâche en pause si elle détecte un comportement potentiellement dangereux du modèle. La mise en pause peut intervenir après l’activité qui l’a déclenchée ; la surveillance ne remplace ni le bac à sable, ni les autorisations, ni la révision du résultat.

Si une tâche est mise en pause, lisez l’avis et examinez les constats lorsqu’ils sont disponibles. Reprenez uniquement après avoir vérifié que la tâche peut se poursuivre en toute sécurité. Si l’avis indique que la tâche est terminée ou ne propose pas d’option de reprise, vous ne pouvez pas la reprendre depuis cette interface.

La surveillance de sécurité évalue le comportement du modèle pendant une tâche. La révision automatique des demandes d’approbation évalue chaque action qui nécessite déjà une approbation avant son exécution. Une action approuvée par cette révision automatique peut tout de même faire partie d’une tâche que la surveillance mettra ensuite en pause.

Accès au réseau Elevated Risk

Pour Codex Cloud, consultez la page Accès Internet de l’agent afin d’activer un accès Internet complet ou une liste de domaines autorisés.

Dans l’application de bureau ChatGPT, Codex CLI ou l’extension IDE, le mode de bac à sable par défaut workspace-write maintient l’accès au réseau désactivé, sauf si vous l’activez dans votre configuration :

[sandbox_workspace_write]
network_access = true

Isolation réseau

L’accès au réseau est contrôlé par des règles de destination qui s’appliquent aux scripts, aux programmes et aux sous-processus lancés par les commandes. Lorsque l’accès au réseau des commandes est déjà activé, activez la fonctionnalité network_proxy pour soumettre ce trafic à la politique réseau que vous configurez. L’ajout de règles de domaine ne suffit pas à activer le proxy.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Pour une session CLI ponctuelle, utilisez la forme booléenne abrégée si vous avez seulement besoin d’activer ou de désactiver la fonctionnalité, et la forme de table si vous définissez également des options de politique :

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

Cette fonctionnalité modifie la manière dont l’accès au réseau, une fois activé, est contrôlé ; elle n’accorde pas cet accès à elle seule. Utilisez sandbox_workspace_write.network_access avec la configuration workspace-write pour déterminer si les commandes ont accès au réseau :

• Réseau désactivé + network_proxy activé : le réseau reste désactivé et la fonctionnalité n’a aucun effet.
• Réseau activé + network_proxy désactivé : le réseau reste activé avec un accès sortant direct sans restriction.
• Réseau activé + network_proxy activé : le réseau reste activé et le trafic sortant est limité par la politique réseau configurée.

La fonctionnalité de proxy s’applique également aux profils d’autorisations. Dans un profil, network.enabled = true accorde aux commandes l’accès au réseau, tandis que features.network_proxy = true active l’application des règles de domaine de ce profil :

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Si vous omettez la fonctionnalité de proxy dans cet exemple, les commandes disposent d’un accès direct au réseau et la règle autorisant api.openai.com ne limite pas leurs destinations.

Les exigences experimental_network gérées par l’administrateur sont distinctes du paramètre d’activation de la fonctionnalité côté utilisateur. Elles peuvent configurer et démarrer la mise en réseau dans le bac à sable sans features.network_proxy, mais elles n’activent pas l’accès au réseau lorsque le bac à sable actif le maintient désactivé. Consultez la page Configuration gérée pour connaître la structure de requirements.toml côté administrateur.

Politique réseau

Les règles de domaine reposent avant tout sur une liste d’autorisation :

• Un nom d’hôte exact ne correspond qu’à lui-même.
• *.example.com correspond aux sous-domaines tels que api.example.com, mais pas à example.com.
• **.example.com correspond à la fois au domaine racine et aux sous-domaines.
• Une règle d’autorisation globale * correspond à tout hôte public qui n’est pas interdit. Considérez * comme un accès réseau étendu et privilégiez des règles ciblées lorsque c’est possible.
• deny l’emporte toujours sur allow, et le caractère global * n’est valide que dans les règles d’autorisation.

Destinations locales et privées

Par défaut, allow_local_binding = false bloque les destinations de bouclage, de liaison locale et privées :

• Exceptions précises : ajoutez une règle autorisant une adresse IP locale littérale exacte ou localhost lorsqu’une commande a besoin d’accéder à une cible locale.
• Accès plus large : définissez allow_local_binding = true uniquement si vous souhaitez délibérément étendre l’accès aux destinations locales ou privées.
• Caractères génériques : les règles qui en contiennent ne constituent pas des exceptions locales explicites.
• Adresses résolues : les noms d’hôte qui se résolvent en adresses IP locales ou privées restent bloqués, même s’ils correspondent à la liste d’autorisation.

Protections contre le DNS rebinding

Avant d’autoriser un nom d’hôte, Codex vérifie autant que possible sa résolution DNS et la classification des adresses IP obtenues :

• Les résolutions qui échouent ou dépassent le délai imparti sont bloquées.
• Les noms d’hôte qui se résolvent en adresses non publiques sont bloqués.
• Cette vérification réduit le risque de rebinding DNS, sans l’éliminer. Pour empêcher complètement le rebinding, il faudrait conserver les adresses IP résolues jusqu’à la couche transport et imposer leur utilisation.

Si votre modèle de menace inclut un DNS malveillant, appliquez aussi des contrôles du trafic sortant à une couche inférieure.

Paramètres dangereux

Deux paramètres élargissent délibérément le périmètre de confiance :

• dangerously_allow_non_loopback_proxy = true peut rendre les points d’écoute du proxy accessibles au-delà de l’interface de bouclage.
• dangerously_allow_all_unix_sockets = true contourne la liste d’autorisation des sockets Unix.

Utilisez-les uniquement dans des environnements strictement contrôlés. Lorsque le relais des sockets Unix par proxy est activé, les points d’écoute restent limités à l’interface de bouclage, même si une liaison à une autre interface a été demandée. Ainsi, le réseau du bac à sable ne devient pas une passerelle d’accès à distance aux démons locaux.

network_proxy est désactivé par défaut. Lorsque vous l’activez :

Trafic hors du proxy réseau des commandes

Le proxy réseau filtre les scripts, les programmes et les processus enfants exécutés dans le bac à sable local des commandes. Il ne filtre pas la recherche web, les appels d’outils d’applications ou de connecteurs, les connexions aux serveurs MCP, l’activité du navigateur ou de la fonctionnalité Utilisation de l’ordinateur, les tâches Codex Cloud, ni les requêtes du client destinées aux modèles ou à l’authentification. Ces interfaces utilisent des connexions aux services, des paramètres de fonctionnalités, des politiques d’espace de travail ou des contrôles d’environnement distincts.

Les outils du navigateur vérifient séparément les interdictions réseau gérées et les listes d’autorisation exclusives avant d’accéder à une origine. Les politiques d’origine du navigateur peuvent restreindre davantage l’accès aux sites, les envois et téléchargements de fichiers ainsi que les outils de développement. Consultez les contrôles gérés du navigateur.

Pour les utilisateurs soumis à une gestion centralisée, combinez la politique réseau des commandes avec des contrôles tels que allowed_web_search_modes, les mcp_servers approuvés et les exigences relatives aux fonctionnalités pour les applications, les plugins, les navigateurs ou l’Utilisation de l’ordinateur. Consultez Configuration gérée.

Vous pouvez aussi contrôler l’outil de recherche web sans accorder un accès réseau complet aux commandes lancées. Par défaut, Codex utilise un cache de recherche web pour accéder aux résultats. Ce cache est un index de résultats web géré par OpenAI : le mode avec cache renvoie donc des résultats déjà indexés au lieu de récupérer des pages en direct. Cela réduit l’exposition aux attaques par injection de prompt provenant de contenus en ligne arbitraires, mais vous devez toujours considérer les résultats web comme non fiables. Si vous utilisez --yolo ou un autre paramètre de bac à sable avec accès complet, la recherche web renvoie par défaut des résultats en direct. Utilisez --search ou définissez web_search = "live" pour autoriser la navigation en direct, ou utilisez la valeur "disabled" pour désactiver l’outil :

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Définissez web_search = "indexed" lorsque l’accès au web externe doit être limité par l’index de recherche. Faites preuve de prudence lorsque vous activez l’accès réseau ou la recherche web dans Codex. Une attaque par injection de prompt peut amener l’agent à récupérer et à suivre des instructions non fiables.

Paramètres par défaut et recommandations

• Au lancement, Codex détecte si le dossier est sous gestion de versions et recommande :
  • Dossiers sous gestion de versions : Auto (écriture dans l’espace de travail + approbations sur demande)
  • Dossiers sans gestion de versions : read-only
• Selon votre configuration, Codex peut aussi démarrer en mode read-only jusqu’à ce que vous déclariez explicitement le répertoire de travail comme fiable (par exemple, via une invite lors de la prise en main ou /permissions).
• L’espace de travail comprend le répertoire courant et des répertoires temporaires comme /tmp. Utilisez la commande /status pour voir quels répertoires font partie de l’espace de travail.
• Pour accepter les paramètres par défaut, exécutez codex.
• Vous pouvez définir ces paramètres explicitement :
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Chemins protégés dans les racines accessibles en écriture

Avec la politique de bac à sable par défaut workspace-write, les racines accessibles en écriture contiennent toujours des chemins protégés :

• <writable_root>/.git est protégé en lecture seule, qu’il s’agisse d’un répertoire ou d’un fichier.
• Si <writable_root>/.git est un fichier pointeur (gitdir: ...), le chemin du répertoire Git vers lequel il pointe est également protégé en lecture seule.
• <writable_root>/.agents est protégé en lecture seule lorsqu’il existe sous forme de répertoire.
• <writable_root>/.codex est protégé en lecture seule lorsqu’il existe sous forme de répertoire.
• La protection est récursive : tout ce qui se trouve sous ces chemins est donc en lecture seule.

Exécution sans demandes d’approbation

Vous pouvez désactiver les demandes d’approbation avec --ask-for-approval never ou -a never (forme abrégée).

Cette option fonctionne avec tous les modes --sandbox : vous gardez donc le contrôle du niveau d’autonomie de Codex. Codex fait de son mieux dans les limites que vous définissez.

Si vous avez besoin que Codex lise des fichiers, effectue des modifications et exécute des commandes avec un accès réseau sans demander d’approbation, utilisez --sandbox danger-full-access (ou l’option --dangerously-bypass-approvals-and-sandbox). Faites preuve de prudence avant de le faire.

Pour une solution intermédiaire, approval_policy = { granular = { ... } } permet de conserver des demandes d’approbation interactives pour certaines catégories tout en rejetant automatiquement les autres. La politique granulaire couvre les approbations du bac à sable, les demandes liées aux règles execpolicy, les demandes MCP, les demandes request_permissions et les approbations des scripts de skills.

Révisions automatiques des demandes d’approbation

Par défaut, les demandes d’approbation vous sont adressées :

approvals_reviewer = "user"

Les révisions automatiques des demandes d’approbation s’appliquent lorsque les approbations sont interactives, par exemple avec approval_policy = "on-request" ou une politique d’approbation granulaire. Définissez approvals_reviewer = "auto_review" pour soumettre les demandes d’approbation admissibles à un agent de révision avant que Codex n’exécute l’action demandée :

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Pour connaître le cycle de vie complet de l’agent de révision, les conditions de déclenchement, l’ordre de priorité des configurations et le comportement en cas d’échec, consultez Révision automatique.

L’agent de révision évalue uniquement les actions qui nécessitent déjà une approbation, comme les demandes d’exécution hors du bac à sable, les requêtes réseau bloquées, les demandes request_permissions ou les appels d’outils d’applications et MCP ayant des effets de bord. Les actions qui restent dans le bac à sable se poursuivent sans étape de révision supplémentaire.

La politique de révision vérifie les risques d’exfiltration de données, les tentatives de recherche d’identifiants, l’affaiblissement durable de la sécurité et les actions destructrices. Les actions à risque faible ou modéré peuvent être exécutées lorsque la politique les autorise. Celle-ci refuse les actions présentant un risque critique. Les actions à risque élevé exigent une autorisation suffisante de l’utilisateur et l’absence de règle d’interdiction applicable. Les échecs de construction du prompt, de session de révision ou d’analyse bloquent l’action par défaut. Les dépassements de délai sont signalés séparément, mais l’action reste bloquée.

La politique de révision par défaut se trouve dans le dépôt open source de Codex. Les entreprises peuvent remplacer sa section propre au tenant à l’aide de guardian_policy_config dans les exigences gérées. Le texte local de [auto_review].policy est également pris en charge, mais les exigences gérées sont prioritaires. Pour en savoir plus sur la configuration, consultez Configuration gérée.

Dans l’application de bureau ChatGPT, ces révisions apparaissent sous forme d’éléments de révision automatique, avec un état tel que Révision en cours, Approuvé, Refusé, Interrompu ou Délai dépassé. Elles peuvent également inclure un niveau de risque et une évaluation de l’autorisation donnée par l’utilisateur pour la demande examinée.

La révision automatique effectue des appels supplémentaires au modèle et peut donc augmenter votre consommation Codex. Les administrateurs peuvent l’encadrer avec allowed_approvals_reviewers.

Combinaisons courantes de bac à sable et d’approbation

Pour les exécutions non interactives, utilisez codex exec --sandbox workspace-write ; Codex conserve la prise en charge des anciennes commandes codex exec --full-auto pour des raisons de compatibilité, mais cet usage est obsolète et déclenche un avertissement.

Configuration dans config.toml

Pour une présentation plus complète de la configuration, consultez les Principes de configuration, la Configuration avancée et la Référence de configuration.

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Vous pouvez aussi enregistrer des préréglages dans des fichiers de profil, puis les sélectionner avec codex --profile profile-name :

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Testez le bac à sable localement

Pour observer ce qui se passe lorsqu’une commande s’exécute dans le bac à sable de Codex, utilisez les commandes Codex CLI suivantes :

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

La commande sandbox est également disponible sous le nom codex debug, et les utilitaires propres à chaque plateforme disposent d’alias (par exemple codex sandbox seatbelt et codex sandbox landlock).

Bac à sable au niveau du système d’exploitation

Codex met en œuvre le bac à sable différemment selon votre système d’exploitation :

• macOS utilise des politiques Seatbelt et exécute les commandes avec sandbox-exec, selon un profil (-p) correspondant au mode --sandbox que vous avez sélectionné. Lorsque l’accès restreint en lecture active les paramètres par défaut de la plateforme, Codex ajoute une politique macOS ciblée (au lieu d’autoriser largement l’accès à /System) pour préserver la compatibilité avec les outils courants.
• Linux utilise bwrap et seccomp par défaut.
• Sur Windows , Codex utilise l’implémentation Linux du bac à sable lorsqu’il s’exécute dans Windows Subsystem for Linux 2 (WSL2). WSL1 était pris en charge jusqu’à Codex 0.114 inclus ; depuis la version 0.115, le bac à sable Linux utilise bwrap, et WSL1 n’est donc plus pris en charge. Lorsqu’il s’exécute nativement sur Windows, Codex utilise une implémentation du bac à sable Windows.

L’extension IDE Codex prend directement en charge WSL2 sur Windows. Ajoutez le paramètre suivant dans vos paramètres VS Code pour maintenir l’agent dans WSL2 dès que celui-ci est disponible :

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

L’extension IDE applique ainsi les règles du bac à sable Linux pour les commandes, les approbations et l’accès au système de fichiers, même lorsque le système d’exploitation hôte est Windows. Pour en savoir plus, consultez le guide WSL.

Pour une exécution native sur Windows, configurez le mode de bac à sable natif dans config.toml :

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Consultez le guide de configuration de Windows pour plus de détails.

Lorsque vous exécutez Linux dans un environnement conteneurisé tel que Docker, le bac à sable peut ne pas fonctionner si la configuration de l’hôte ou du conteneur bloque les opérations sur les espaces de noms, l’exécution de bwrap avec setuid ou les opérations seccomp dont Codex a besoin.

Dans ce cas, configurez votre conteneur Docker pour assurer l’isolation nécessaire, puis exécutez codex avec --sandbox danger-full-access (ou l’option --dangerously-bypass-approvals-and-sandbox) à l’intérieur du conteneur.

Exécutez Codex dans Dev Containers

Si votre hôte ne peut pas exécuter directement le bac à sable Linux, ou si votre organisation a déjà adopté le développement conteneurisé comme standard, exécutez Codex avec Dev Containers et laissez Docker assurer l’isolation externe. Cette approche fonctionne avec Dev Containers pour Visual Studio Code et les outils compatibles.

Utilisez l’exemple de devcontainer sécurisé pour Codex comme implémentation de référence. Cet exemple installe Codex, des outils de développement courants, bubblewrap et des contrôles du trafic sortant reposant sur un pare-feu.

L’implémentation de référence comprend :

• une image de base Ubuntu 24.04 avec Codex et des outils de développement courants préinstallés ;
• un profil de pare-feu fondé sur une liste d’autorisation pour les connexions sortantes ;
• des paramètres VS Code et des recommandations d’extensions pour rouvrir l’espace de travail dans un conteneur ;
• des montages persistants pour l’historique des commandes et la configuration de Codex ;
• bubblewrap, pour que Codex puisse continuer à utiliser son bac à sable Linux lorsque le conteneur accorde les capacités nécessaires.

Pour l’essayer :

1. Installez Visual Studio Code et l’extension Dev Containers.
2. Copiez la configuration .devcontainer de l’exemple Codex dans votre dépôt, ou partez directement du dépôt Codex.
3. Dans VS Code, exécutez Dev Containers: Open Folder in Container... et sélectionnez .devcontainer/devcontainer.secure.json.
4. Une fois le conteneur démarré, ouvrez un terminal et exécutez codex.

Vous pouvez aussi démarrer le conteneur depuis la CLI :

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

L’exemple comprend trois éléments principaux :

• .devcontainer/devcontainer.secure.json contrôle les paramètres du conteneur, les capacités, les montages, les variables d’environnement et les extensions VS Code.
• .devcontainer/Dockerfile.secure définit l’image basée sur Ubuntu et les outils installés.
• .devcontainer/init-firewall.sh applique la politique réseau aux connexions sortantes.

Le pare-feu de référence constitue volontairement un point de départ. Si votre isolation repose sur une liste de domaines autorisés, mettez en place des protections adaptées à votre environnement contre le DNS rebinding et les risques liés à l’actualisation DNS, par exemple des actualisations tenant compte du TTL ou un pare-feu prenant en compte le DNS.

Dans le conteneur, choisissez l’un des modes suivants :

• Gardez le bac à sable Linux de Codex activé si le profil Dev Container accorde les capacités nécessaires à bwrap pour créer le bac à sable interne.
• Si vous comptez sur le conteneur pour assurer la sécurité, exécutez Codex avec --sandbox danger-full-access à l’intérieur du conteneur afin qu’il ne tente pas de créer une seconde couche de bac à sable.

Gestion de versions

Codex fonctionne mieux avec un workflow intégrant la gestion de versions :

• Travaillez sur une branche de fonctionnalité et vérifiez que git status n’indique aucune modification en attente avant de déléguer. Les patchs de Codex seront ainsi plus faciles à isoler et à annuler.
• Privilégiez les workflows fondés sur des patchs (par exemple, git diff/git apply) plutôt que la modification directe des fichiers suivis. Créez des commits fréquents pour pouvoir revenir en arrière par petites étapes.
• Traitez les suggestions de Codex comme toute autre PR : effectuez des vérifications ciblées, examinez les diffs et consignez les décisions dans les messages de commit pour faciliter les audits.

Surveillance et télémétrie

Codex propose une surveillance facultative via OpenTelemetry (OTel) pour aider les équipes à auditer l’utilisation, à examiner les problèmes et à respecter les exigences de conformité sans affaiblir les protections de sécurité locales par défaut. La télémétrie est désactivée par défaut ; activez-la explicitement dans votre configuration.

Vue d’ensemble

• Codex désactive l’export OTel par défaut pour que les exécutions locales restent autonomes.
• Lorsque l’export est activé, Codex émet des événements de journal structurés couvrant les discussions, les requêtes API, l’activité des flux SSE/WebSocket, les prompts des utilisateurs (masqués par défaut), les décisions d’approbation des outils et les résultats des outils.
• Codex associe aux événements exportés service.name (émetteur), la version de la CLI et une étiquette d’environnement pour distinguer le trafic de développement, de préproduction et de production.

Activez OTel (facultatif)

Ajoutez un bloc [otel] à votre configuration Codex (généralement dans ~/.codex/config.toml), en choisissant un exportateur et en indiquant si le texte des prompts doit être journalisé.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" maintient l’instrumentation active, mais n’envoie aucune donnée.
• Pour envoyer des événements à votre propre collecteur, choisissez l’une des options suivantes :

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex regroupe les événements par lots et envoie les événements en attente à l’arrêt. Codex exporte uniquement les données de télémétrie produites par son module OTel.

Catégories d’événements

Voici quelques types d’événements représentatifs :

• codex.conversation_starts (modèle, paramètres de raisonnement, politique de bac à sable et d’approbation)
• codex.api_request (tentative, statut/réussite, durée et détails de l’erreur)
• codex.sse_event (type d’événement du flux, réussite/échec, durée et nombre de tokens pour response.completed)
• codex.websocket_request et codex.websocket_event (durée de la requête et type/réussite/erreur pour chaque message)
• codex.user_prompt (longueur ; contenu masqué sauf si sa journalisation est explicitement activée)
• codex.tool_decision (approuvé/refusé, origine : configuration ou utilisateur)
• codex.tool_result (durée, réussite, extrait de la sortie)

Les métriques OTel associées (paires composées d’un compteur et d’un histogramme de durée) comprennent codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event et codex.tool.call (avec les instruments .duration_ms correspondants).

Pour le catalogue complet des événements et la référence de configuration, consultez la documentation de configuration de Codex sur GitHub.

Recommandations de sécurité et de confidentialité

• Conservez log_user_prompt = false, sauf si la politique autorise explicitement le stockage du contenu des prompts. Les prompts peuvent contenir du code source et des données sensibles.
• Envoyez les données de télémétrie uniquement à des collecteurs que vous contrôlez ; appliquez des limites de conservation et des contrôles d’accès conformes à vos exigences de conformité.
• Traitez les arguments et les sorties des outils comme des données sensibles. Privilégiez leur masquage au niveau du collecteur ou du SIEM lorsque c’est possible.
• Vérifiez les paramètres de conservation des données locales (par exemple, history.persistence / history.max_bytes) si vous ne souhaitez pas que Codex enregistre les transcriptions des sessions dans CODEX_HOME. Consultez les pages Configuration avancée et Référence de configuration.
• Si vous exécutez la CLI avec l’accès au réseau désactivé, l’exportation OTel ne peut pas atteindre votre collecteur. Pour exporter, autorisez l’accès au réseau en mode workspace-write pour le point de terminaison OTel, ou exportez depuis Codex Cloud en ajoutant le domaine du collecteur à votre liste d’autorisation.
• Examinez régulièrement les événements pour repérer les changements concernant les approbations ou le bac à sable, ainsi que les exécutions d’outils inattendues.

OTel est facultatif et conçu pour compléter, et non remplacer, les protections du bac à sable et des approbations décrites ci-dessus.

Configuration gérée

Les administrateurs d’entreprise peuvent configurer les paramètres de sécurité de Codex pour leur espace de travail dans Configuration gérée. Consultez cette page pour en savoir plus sur la configuration et les politiques.