Approbations et sécurité de l’agent

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 réseau. En local, le système d’exploitation impose à Codex un bac à sable qui limite les ressources auxquelles il peut accéder, généralement à celles de l’espace de travail courant. Une politique d’approbation détermine quand Codex doit s’arrêter et demander votre accord avant d’agir.

Pour comprendre le fonctionnement du bac à sable dans l’application de bureau ChatGPT, Codex CLI et l’extension pour IDE, consultez la présentation du bac à sable. Pour une vue d’ensemble de la sécurité en entreprise, consultez le livre blanc sur la sécurité de Codex.

Migration depuis l’ancienne politique d’approbation untrusted

Codex et ChatGPT Work ne prennent plus en charge approval_policy = "untrusted". Cet ancien paramètre peut empêcher le démarrage de l’un comme de l’autre. 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, utilisez la configuration suivante :

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

Vous pouvez aussi exécuter 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 le réseau si l’accès est activé.

Pour conserver la règle d’approbation des commandes la 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. Ce réglage désactive aussi la configuration locale du projet. Si vous définissez explicitement on-request, ce réglage prime sur la politique issue du projet. Pour autoriser la politique issue du projet, le paramètre géré allowed_approval_policies doit inclure untrusted.

Bac à sable et approbations

Lorsque Work Cloud accède à un ordinateur local, des politiques distinctes régissent l’exécution en local et dans le cloud :

• Exécution dans le cloud : les conteneurs cloud de Work utilisent les politiques existantes de Work Cloud.
• Exécution en local : les exigences d’exécution locale s’appliquent à l’ordinateur connecté. Les exigences MDM et les anciennes exigences relatives aux appareils gérés priment sur celles d’Agent Security. Ces dernières priment à leur tour sur le fichier d’exigences système de l’appareil.

Pour le mode Work avec accès local et pour les dots, les règles prises en charge dans Global s’appliquent à l’orchestrateur cloud partagé lorsque la gestion des politiques est activée. Les conteneurs cloud de Work et les ordinateurs cloud des dots utilisent leur propre configuration d’exécution et leurs propres exigences. Testez séparément les contrôles locaux et cloud. Conservez dans Global les contrôles de l’orchestrateur, notamment ceux des approbations et de la recherche web. Lorsqu’ils sont disponibles, utilisez les contrôles dédiés aux politiques d’approbation autorisées et aux modes de recherche web autorisés. Utilisez TOML pour les autres champs pris en charge. Avant d’appliquer un exemple Codex à l’accès à un ordinateur local avec Work Cloud, vérifiez la liste des champs et leur périmètre d’exécution dans la référence de configuration.

Passer de l’application de bureau au Web ou au mobile ne donne pas accès à un autre ordinateur. Avant d’activer la synchronisation ou d’élargir l’accès, vérifiez la configuration de référence d’Agent Security et testez une action autorisée et une action bloquée dans chaque environnement d’exécution. Consultez la configuration gérée.

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

• Mode du bac à sable : il détermine ce que Codex peut faire lorsqu’il exécute des commandes générées par le modèle, notamment où il peut écrire et s’il peut accéder au réseau.
• Politique d’approbation : elle détermine quand Codex doit demander votre accord avant d’agir, par exemple pour sortir du bac à sable, utiliser le réseau ou exécuter une commande qui ne figure pas parmi les commandes de confiance.

Le mode du bac à sable dépend de l’environnement dans lequel vous exécutez Codex :

• Codex Cloud (ancienne version) : Codex s’exécute dans des conteneurs isolés gérés par OpenAI, sans accès au système hôte ni aux données sans rapport avec la tâche. L’exécution se déroule en deux phases. La phase de préparation précède celle de l’agent et peut accéder au réseau pour installer les dépendances indiqué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 ne sont disponibles que pendant la préparation et sont supprimés avant le démarrage de la phase de l’agent.
• Codex Cloud actuel : consultez la section Variables d’environnement et secrets réseau pour savoir comment les identifiants sont gérés pendant la préparation et l’exécution des tâches.
• Codex CLI et extension pour IDE : le système d’exploitation fait appliquer les politiques du bac à sable. Par défaut, l’accès réseau est désactivé et les droits d’écriture se limitent à l’espace de travail actif. Vous pouvez configurer le bac à sable, la politique d’approbation et les paramètres réseau selon le niveau de risque que vous acceptez.

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

Codex demande votre approbation pour modifier des fichiers en dehors de l’espace de travail ou exécuter des commandes qui nécessitent un accès réseau. Pour discuter ou préparer un plan sans apporter de modifications, passez en mode read-only avec la commande /permissions.

Codex peut aussi demander votre approbation pour les appels d’outils d’applications (connecteurs) qui déclarent des effets de bord, même si l’action ne consiste pas à exécuter une commande shell ou à modifier un fichier. Les appels d’outils d’applications ou d’outils MCP nécessitent toujours une approbation si l’outil déclare une annotation indiquant une action destructrice, sauf s’il déclare aussi une annotation de lecture, qui est prioritaire.

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

GPT-6 Astra intègre une surveillance de sécurité dans Codex et ChatGPT Work. Elle 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 permissions, ni la vérification du résultat.

Si une tâche est mise en pause, lisez la notification et examinez les constats lorsqu’ils sont disponibles. Ne reprenez la tâche qu’après avoir vérifié qu’elle peut se poursuivre en toute sécurité. Si la notification indique que la tâche a pris fin ou ne propose aucune 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 individuellement, avant leur exécution, les actions qui nécessitent déjà une approbation. Même si la révision automatique approuve une action, la surveillance peut ensuite mettre en pause la tâche dont elle fait partie.

Accès réseau Elevated Risk

Pour les paramètres réseau de la version actuelle de Codex Cloud, consultez Connexion aux services. Pour l’ancienne version de Codex Cloud, consultez Accès de l’agent à Internet pour activer l’accès complet à Internet ou définir une liste de domaines autorisés.

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

[sandbox_workspace_write]
network_access = true

Isolation réseau

Dans les environnements d’exécution gérés de Codex Cloud qui les prennent en charge, les exigences d’Agent Security limitent l’accès réseau des commandes. Les paramètres d’accès à Internet de l’environnement Codex Cloud s’appliquent séparément. Autoriser un domaine dans Agent Security ne lève pas une restriction définie dans les paramètres Internet de l’environnement cloud. À eux seuls, ces contrôles réseau des commandes ne désactivent ni la recherche web hébergée, ni les applications, ni MCP. ChatGPT Work Cloud dispose de permissions distinctes pour ses fonctionnalités et n’hérite pas de ces exigences d’Agent Security.

La liste d’autorisation gérée s’applique aux commandes qui utilisent le proxy géré. Si la politique permet de lever toutes les restrictions du bac à sable et que cette élévation de privilèges est approuvée, la commande peut s’exécuter sans passer par le proxy. Une autorisation réseau limitée est distincte d’une levée complète des restrictions du bac à sable. Configurez les exigences obligatoires d’approbation et de bac à sable selon les limites à faire respecter, puis testez les commandes avec et sans élévation de privilèges. Consultez la configuration gérée.

Des règles de destination contrôlent l’accès réseau des scripts, des programmes et des sous-processus lancés par les commandes. Lorsque l’accès 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 n’active pas le proxy à lui seul.

[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 souhaitez seulement activer ou désactiver la fonctionnalité. Utilisez une table si vous définissez aussi 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 réseau est contrôlé lorsqu’il est activé. Elle n’accorde pas elle-même cet accès. Utilisez sandbox_workspace_write.network_access dans la configuration workspace-write pour déterminer si les commandes ont accès au réseau :

• Réseau désactivé et network_proxy activé : le réseau reste désactivé et la fonctionnalité est sans effet.
• Réseau activé et network_proxy désactivé : le réseau reste activé, avec un accès sortant direct sans restriction.
• Réseau activé et network_proxy activé : le réseau reste activé et la politique réseau configurée limite le trafic sortant.

Le proxy s’applique aussi aux profils de permissions. Dans un profil, network.enabled = true accorde aux commandes l’accès réseau, tandis que features.network_proxy = true fait appliquer les règles de domaine du 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 accèdent directement 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 indépendantes du paramètre d’activation de la fonctionnalité côté utilisateur. Elles peuvent configurer et démarrer les services réseau du bac à sable sans features.network_proxy, mais elles n’activent pas l’accès réseau si le bac à sable actif le désactive. Consultez la configuration gérée pour connaître la structure du fichier requirements.toml côté administrateur.

Politique réseau

Les règles de domaine reposent en priorité sur une liste d’autorisation :

• Un nom d’hôte exact correspond uniquement à cet hôte.
• *.example.com correspond aux sous-domaines tels que api.example.com, mais pas à example.com.
• **.example.com correspond à la fois au domaine racine et à ses 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 les règles ciblées lorsque c’est possible.
• deny prime toujours sur allow, et le caractère générique 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, les adresses locales au lien et les destinations privées :

• Exceptions ciblées : ajoutez une règle qui autorise une adresse IP locale exacte ou localhost lorsqu’une commande doit atteindre une destination locale précise.
• Accès élargi : ne définissez allow_local_binding = true que si vous souhaitez étendre l’accès aux réseaux locaux ou privés.
• Caractères génériques : les règles contenant des caractères génériques ne constituent pas des exceptions locales explicites.
• Résolution d’adresses : les noms d’hôtes qui se résolvent en adresses IP locales ou privées restent bloqués, même s’ils correspondent à la liste d’autorisation.

Protection contre les attaques par DNS rebinding

Avant d’autoriser un nom d’hôte, Codex vérifie, dans la mesure du possible, la résolution DNS et la classification des adresses IP :

• Si la résolution échoue ou dépasse le délai imparti, l’accès est bloqué.
• Les noms d’hôtes qui se résolvent en adresses non publiques sont bloqués.
• Cette vérification réduit le risque de DNS rebinding sans l’éliminer. Pour empêcher complètement ces attaques, il faudrait maintenir les adresses IP résolues fixes jusque dans la couche de transport.

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 proxy pour sockets Unix est activé, les points d’écoute restent limités à l’interface de bouclage, même si une écoute sur une autre interface a été demandée. Le réseau du bac à sable ne peut donc pas servir de passerelle distante vers les démons locaux.

network_proxy est désactivé par défaut. Lorsque vous l’activez, les paramètres suivants s’appliquent :

Trafic qui ne passe pas par le proxy réseau des commandes

Le proxy réseau filtre le trafic des scripts, des programmes et des processus enfants qui s’exécutent 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 dans le cloud, ni les requêtes du client destinées au modèle ou à l’authentification. Ces fonctionnalités utilisent des connexions aux services, des paramètres, des politiques d’espace de travail ou des contrôles d’environnement distincts.

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

Pour les utilisateurs soumis à une configuration gérée, associez la politique réseau des commandes à des contrôles tels que allowed_web_search_modes, les serveurs approuvés dans mcp_servers et les exigences relatives aux applications, aux plugins, aux navigateurs ou à la fonctionnalité Utilisation de l’ordinateur. Consultez la 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 consulte les résultats dans un cache de recherche web. Ce cache est un index de résultats web maintenu 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 consultés en direct sur des sites quelconques. Considérez 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 renvoie par défaut des résultats en direct. Utilisez --search ou définissez web_search = "live" pour autoriser la navigation en direct. Pour désactiver l’outil, choisissez "disabled" :

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

Définissez web_search = "indexed" lorsque l’index de recherche doit contrôler l’accès au web externe. Soyez prudent 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 démarrage, Codex détecte si le dossier est sous gestion de versions et recommande les modes suivants :
  • Dossiers sous gestion de versions : Auto (écriture dans l’espace de travail et approbations sur demande).
  • Autres dossiers : 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 lors de la prise en main ou avec /permissions.
• L’espace de travail comprend le répertoire courant et des répertoires temporaires tels que /tmp. Utilisez la commande /status pour voir quels répertoires en font partie.
• Pour accepter les paramètres par défaut, exécutez codex.
• Vous pouvez aussi 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 répertoires racines accessibles en écriture

Avec la politique de bac à sable par défaut workspace-write, certains chemins restent protégés même si leur répertoire racine est accessible en écriture :

• <writable_root>/.git reste en lecture seule, qu’il s’agisse d’un répertoire ou d’un fichier.
• Si <writable_root>/.git est un fichier de redirection (gitdir: ...), le répertoire Git vers lequel il pointe est également en lecture seule.
• <writable_root>/.agents est en lecture seule lorsqu’il existe en tant que répertoire.
• <writable_root>/.codex est en lecture seule lorsqu’il existe en tant que répertoire.
• <writable_root>/.aws est en lecture seule lorsqu’il existe en tant que répertoire.
• La protection est récursive : tout le contenu de ces chemins est en lecture seule.

Exécution sans demande d’approbation

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

Cette option fonctionne avec tous les modes --sandbox. Vous gardez ainsi la maîtrise du degré d’autonomie de Codex. Codex fait de son mieux dans les limites que vous fixez.

Si vous avez besoin que Codex lise des fichiers, les modifie et exécute des commandes avec accès réseau sans demander d’approbation, utilisez --sandbox danger-full-access (ou l’option --dangerously-bypass-approvals-and-sandbox). Évaluez les risques au préalable.

Pour un réglage intermédiaire, approval_policy = { granular = { ... } } permet de conserver les demandes d’approbation interactives pour certaines catégories et de refuser automatiquement les autres. Cette politique granulaire couvre les approbations relatives au bac à sable, les demandes liées aux règles de la politique d’exécution, les demandes MCP, les demandes request_permissions et les approbations des scripts de skills.

Révision automatique des demandes d’approbation

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

approvals_reviewer = "user"

La révision automatique s’applique 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 confier 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 paramètres et le comportement en cas d’échec, consultez la section Révision automatique.

L’agent de révision évalue uniquement les actions qui nécessitent déjà une approbation. Il peut s’agir d’une demande de levée des restrictions du bac à sable, d’une requête réseau soumise à approbation, d’une demande request_permissions ou d’un appel d’outil d’application ou MCP soumis à approbation. Une règle applicable à une commande peut aussi imposer une révision à l’intérieur du bac à sable.

La politique de révision recherche les tentatives d’exfiltration de données, de recherche d’identifiants, d’affaiblissement durable de la sécurité et les actions destructrices. Les actions à risque faible ou modéré peuvent s’exécuter si la politique les autorise. La politique refuse les actions à risque critique. Les actions à risque élevé nécessitent une autorisation suffisante de l’utilisateur et ne doivent correspondre à aucune règle de refus. Si la construction du prompt, la session de révision ou l’analyse de la réponse échoue, l’action est bloquée. Les dépassements de délai sont signalés séparément, mais l’action reste bloquée.

Pour remplacer la politique en local ou à l’échelle d’une organisation, consultez la configuration de la révision automatique.

Dans l’application de bureau ChatGPT, ces révisions apparaissent sous le libellé « Révision automatique ». Leur état indique, par exemple, si l’examen est en cours, si la demande a été approuvée ou refusée, si l’examen a été interrompu ou si le délai a expiré. La révision peut aussi indiquer le niveau de risque de la demande et préciser si l’utilisateur a suffisamment autorisé l’action.

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

Combinaisons courantes de bac à sable et d’approbations

Pour une exécution non interactive, utilisez codex exec --sandbox workspace-write.

Configuration dans config.toml

Pour plus de détails sur la configuration, consultez les principes de base, 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 vos préréglages dans des fichiers de profil, puis sélectionner le profil voulu 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"

Test du bac à sable en local

Pour observer le comportement d’une commande 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 accessible via codex debug. Les commandes propres à chaque plateforme disposent d’alias, par exemple codex sandbox seatbelt et codex sandbox landlock.

Bac à sable du système d’exploitation

Codex fait appliquer les restrictions du bac à sable différemment selon votre système d’exploitation :

• macOS utilise les politiques Seatbelt et exécute les commandes avec sandbox-exec et un profil (-p) correspondant au mode --sandbox sélectionné. Lorsque les restrictions d’accès en lecture activent les règles par défaut de la plateforme, Codex ajoute une politique spécifique à macOS pour assurer la compatibilité avec les outils courants sans autoriser un accès général à /System.
• Linux utilise par défaut bwrap et seccomp.
• Windows prend en charge MXC et conserve elevated et unelevated comme anciennes solutions de repli. Dans le sous-système Windows pour Linux 2 (WSL2), Codex utilise l’implémentation Linux du bac à sable. Codex prenait en charge WSL1 jusqu’à la version 0.114 incluse. Depuis la version 0.115, le bac à sable Linux utilise bwrap et WSL1 n’est plus pris en charge.

Sur Windows, l’extension Codex pour IDE prend directement en charge WSL2. Ajoutez le paramètre suivant à votre configuration VS Code pour que l’agent s’exécute dans WSL2 chaque fois que celui-ci est disponible :

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

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

Sur Windows, privilégiez MXC lorsque l’appareil et la politique le permettent. Ajoutez le paramètre suivant dans config.toml :

[features]
prefer_mxc = true

Conservez dans windows.sandbox une ancienne implémentation autorisée comme solution de repli. Consultez le guide de configuration sur Windows pour connaître les paramètres et les limites de compatibilité.

Si vous exécutez Linux dans un environnement conteneurisé tel que Docker, le bac à sable risque de 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) dans le conteneur.

Exécution de Codex dans Dev Containers

Si votre hôte ne peut pas exécuter directement le bac à sable Linux ou si votre organisation utilise déjà des conteneurs comme environnements de développement standard, exécutez Codex avec Dev Containers et confiez à Docker l’isolation du conteneur vis-à-vis de l’hôte. Cette approche fonctionne avec Visual Studio Code Dev Containers et les outils compatibles.

Dans le conteneur, choisissez l’un de ces modes :

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

Gestion de versions

Codex fonctionne mieux avec un workflow de gestion de versions :

• Travaillez sur une branche dédiée à la fonctionnalité et vérifiez avec git status que votre arbre de travail est propre avant de déléguer. Vous pourrez ainsi isoler et annuler plus facilement les correctifs de Codex.
• Privilégiez les workflows fondés sur des correctifs (par exemple, git diff/git apply) plutôt que de modifier directement les fichiers suivis. Faites des commits fréquents pour pouvoir revenir en arrière par petites étapes.
• Traitez les suggestions de Codex comme toute autre pull request : 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). Elle aide les équipes à auditer l’utilisation de Codex, à analyser les problèmes et à respecter leurs exigences de conformité sans affaiblir les paramètres de sécurité locaux par défaut. La télémétrie est désactivée par défaut. Pour l’utiliser, 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 sur les discussions, les requêtes API, l’activité des flux SSE/WebSocket, les prompts des utilisateurs (dont le contenu est masqué par défaut), les décisions d’approbation des outils et leurs résultats.
• Codex associe aux événements exportés service.name (service émetteur), la version de la CLI et un libellé d’environnement pour distinguer le trafic de développement, de préproduction et de production.

Activation facultative d’OTel

Ajoutez un bloc [otel] à votre configuration Codex (généralement dans ~/.codex/config.toml), choisissez un exportateur et indiquez 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

• Avec exporter = "none", l’instrumentation reste active, mais aucune donnée n’est envoyée.
• Pour envoyer les événements à votre propre collecteur, choisissez l’une des configurations 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. Il exporte uniquement la télémétrie produite 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, politiques de bac à sable et d’approbation)
• codex.api_request (tentative, état et réussite, durée et détails de l’erreur)
• codex.sse_event (type d’événement du flux, réussite ou échec, durée et nombre de tokens pour response.completed)
• codex.websocket_request et codex.websocket_event (durée de la requête, puis type, réussite ou erreur pour chaque message)
• codex.user_prompt (longueur du prompt, contenu masqué sauf activation explicite de sa journalisation)
• codex.tool_decision (approbation ou refus, décision issue de la configuration ou de l’utilisateur)
• codex.tool_result (durée, réussite, extrait du résultat)

Les métriques OTel associées comprennent codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event et codex.tool.call. Chacune associe un compteur à un histogramme de durée, avec l’instrument .duration_ms correspondant.

Pour consulter le catalogue complet des événements et la référence de configuration, reportez-vous à la documentation de configuration de Codex sur GitHub.

Recommandations de sécurité et de confidentialité

• Conservez log_user_prompt = false, sauf si votre politique autorise explicitement le stockage du contenu des prompts. Les prompts peuvent contenir du code source et des données sensibles.
• Envoyez la 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.
• Traitez les arguments et les sorties des outils comme des données sensibles. Dans la mesure du possible, masquez ces données au niveau du collecteur ou du SIEM.
• Vérifiez les paramètres locaux de conservation des données (par exemple, history.persistence / history.max_bytes) si vous souhaitez éviter que Codex enregistre les transcriptions des sessions sous CODEX_HOME. Consultez la configuration avancée et la référence de configuration.
• Si vous exécutez la CLI sans accès réseau, l’export OTel ne peut pas atteindre votre collecteur. Pour exporter les événements, autorisez l’accès réseau en mode workspace-write pour le point de terminaison OTel, ou effectuez l’export depuis Codex dans le cloud en ajoutant le domaine du collecteur à votre liste d’autorisation.
• Examinez régulièrement les événements pour repérer les changements relatifs aux approbations ou au bac à sable ainsi que les exécutions d’outils inattendues.

OTel est facultatif. Il complète les protections du bac à sable et des approbations décrites ci-dessus, sans les remplacer.

Configuration gérée

Les administrateurs d’entreprise peuvent définir les paramètres de sécurité de Codex pour leur espace de travail dans la configuration gérée. Consultez cette page pour connaître la procédure de configuration et les politiques applicables.