Approbations 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 avec l’accès réseau désactivé. En local, Codex utilise un environnement isolé imposé par le système d’exploitation, qui limite les ressources auxquelles il peut accéder (généralement à l’espace de travail actuel), ainsi qu’une politique d’approbation qui détermine quand il doit s’arrêter et vous demander votre autorisation avant d’agir.

Pour une présentation générale du fonctionnement de l’environnement isolé dans l’application de bureau ChatGPT, Codex CLI et l’extension IDE, consultez la page sur l’environnement isolé. Pour une présentation plus générale de la sécurité en entreprise, consultez le livre blanc sur la sécurité de Codex.

Environnement isolé et approbations

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

• Mode d’environnement isolé : ce que Codex peut techniquement faire (par exemple, les emplacements dans lesquels il peut écrire et son éventuel accès 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 autorisation avant d’exécuter une action (par exemple, sortir de l’environnement isolé, utiliser le réseau ou exécuter des commandes ne faisant pas partie d’un ensemble approuvé).

Codex utilise différents modes d’environnement isolé 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 tout accès à votre système hôte ou à des données sans rapport avec la tâche. Il utilise un modèle d’exécution en deux phases : la configuration s’exécute avant 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 ne sont disponibles que pendant la configuration et sont supprimés avant le début de la phase de l’agent.
• Codex CLI / extension IDE : des mécanismes au niveau du système d’exploitation appliquent les politiques de l’environnement isolé. 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 l’environnement isolé, la politique d’approbation et les paramètres réseau selon 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 votre approbation pour modifier des fichiers en dehors de l’espace de travail ou exécuter des commandes nécessitant un accès réseau. Si vous souhaitez discuter ou planifier sans apporter de modifications, passez en mode read-only avec la commande /permissions.

Codex peut également solliciter votre approbation pour les appels d’outils d’app (connecteur) qui signalent des effets secondaires, même lorsque l’action n’est ni une commande shell ni une modification de fichier. Les appels destructifs d’outils d’app/MCP nécessitent toujours une approbation lorsque l’outil signale une annotation destructive, même s’il fournit également d’autres indications (par exemple, des indications de lecture seule).

Accès réseau

Pour Codex cloud, consultez la page sur l’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 d’environnement isolé workspace-write par défaut maintient l’accès réseau désactivé, sauf si vous l’activez dans votre configuration :

[sandbox_workspace_write]
network_access = true

Isolation du réseau

L’accès réseau est contrôlé au moyen de règles de destination qui s’appliquent aux scripts, programmes et sous-processus lancés par les commandes. Lorsque l’accès réseau des commandes est déjà activé, activez la fonctionnalité network_proxy afin de limiter ce trafic à la politique réseau que vous configurez.

[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 uniquement besoin d’activer ou de désactiver l’option, et la forme de tableau 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 façon dont l’accès réseau activé est appliqué ; elle n’accorde pas à elle seule l’accès au réseau. Utilisez sandbox_workspace_write.network_access avec la configuration workspace-write pour déterminer si les commandes disposent d’un accès 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.

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

Politique réseau

Les règles de domaine donnent la priorité à la liste d’autorisation :

• Les hôtes exacts ne correspondent qu’à eux-mêmes.
• *.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 refusé. Considérez * comme un accès réseau étendu et privilégiez autant que possible des règles ciblées.
• deny prévaut toujours sur allow, et la règle globale * n’est valide que pour les règles d’autorisation.

Destinations locales et privées

Par défaut, allow_local_binding = false bloque les destinations de bouclage, link-local et privées :

• Exceptions spécifiques : ajoutez une adresse IP locale littérale exacte ou une règle d’autorisation localhost lorsqu’une commande doit accéder à une cible locale précise.
• Accès plus large : définissez allow_local_binding = true uniquement si vous souhaitez intentionnellement étendre l’accès aux destinations locales ou privées.
• Caractères génériques : les règles utilisant des caractères génériques ne sont pas considérées comme des exceptions locales explicites.
• Adresses résolues : les noms d’hôte résolus en adresses IP locales ou privées restent bloqués, même s’ils correspondent à la liste d’autorisation.

Protections contre le rebinding DNS

Avant d’autoriser un nom d’hôte, Codex effectue, dans la mesure du possible, une vérification de classification DNS et IP :

• Les recherches qui échouent ou expirent sont bloquées.
• Les noms d’hôte résolus en adresses non publiques sont bloqués.
• Cette vérification réduit le risque de rebinding DNS, sans toutefois l’éliminer. Empêcher totalement le rebinding nécessiterait d’épingler les adresses IP résolues au niveau de la couche de transport.

Si un DNS malveillant fait partie des menaces envisagées, appliquez également des contrôles de sortie à un niveau inférieur.

Paramètres dangereux

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

• dangerously_allow_non_loopback_proxy = true peut exposer les écouteurs du proxy 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 étroitement contrôlés. Lorsque le proxy de sockets Unix est activé, les écouteurs restent limités à l’interface de bouclage même si une liaison hors bouclage a été demandée, afin que le réseau en environnement isolé ne devienne pas un pont distant vers les démons locaux.

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

Vous pouvez également 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 mis en cache renvoie donc des résultats préindexés au lieu de récupérer des pages en direct. Cela réduit l’exposition aux injections de prompt provenant de contenus en direct arbitraires, mais vous devez tout de même considérer les résultats web comme non fiables. Si vous utilisez --yolo ou un autre paramètre d’accès complet de l’environnement isolé, la recherche web utilise par défaut des résultats en direct. Utilisez --search ou définissez web_search = "live" pour autoriser la navigation en direct, ou définissez-le sur "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 externe au web doit être limité par l’index de recherche. Soyez prudent lorsque vous activez l’accès réseau ou la recherche web dans Codex. Une injection de prompt peut amener l’agent à récupérer et suivre des instructions non fiables.

Valeurs par défaut et recommandations

• Au démarrage, Codex détecte si le dossier est géré par un système de contrôle de version et recommande :
  • Dossiers gérés par un système de contrôle de version : Auto (écriture dans l’espace de travail + approbations à la demande)
  • Dossiers non gérés par un système de contrôle de version : read-only
• Selon votre configuration, Codex peut également démarrer en mode read-only jusqu’à ce que vous approuviez explicitement le répertoire de travail (par exemple, via une invite d’intégration ou /permissions).
• L’espace de travail comprend le répertoire actuel et les répertoires temporaires tels que /tmp. Utilisez la commande /status pour afficher les répertoires inclus dans l’espace de travail.
• Pour accepter les valeurs par défaut, exécutez codex.
• Vous pouvez les définir 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

Dans la politique d’environnement isolé workspace-write par défaut, les racines accessibles en écriture comprennent 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 résolu du répertoire Git est également protégé en lecture seule.
• <writable_root>/.agents est protégé en lecture seule lorsqu’il existe en tant que répertoire.
• <writable_root>/.codex est protégé en lecture seule lorsqu’il existe en tant que répertoire.
• La protection est récursive : tout ce qui se trouve sous ces chemins est donc en lecture seule.

Exécuter 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, ce qui vous permet de continuer à contrôler le 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, apporte des modifications et exécute des commandes avec un accès réseau sans demandes 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 = { ... } } vous permet de conserver certaines catégories de demandes d’approbation en mode interactif tout en rejetant automatiquement les autres. La stratégie granulaire couvre les approbations de sandbox, les demandes liées aux règles execpolicy, les demandes MCP, les demandes request_permissions et les approbations de scripts de compétences.

Examens automatiques des approbations

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

approvals_reviewer = "user"

Les examens automatiques des approbations s’appliquent lorsque les approbations sont interactives, par exemple avec approval_policy = "on-request" ou une stratégie d’approbation granulaire. Définissez approvals_reviewer = "auto_review" pour transmettre les demandes d’approbation éligibles à un agent chargé de l’examen avant que Codex n’exécute la demande :

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

Pour en savoir plus sur le cycle de vie complet de l’agent chargé de l’examen, les conditions de déclenchement, la priorité de la configuration et le comportement en cas d’échec, consultez l’examen automatique.

L’agent examine uniquement les actions qui nécessitent déjà une approbation, telles que les élévations de privilèges de la sandbox, 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 la sandbox se poursuivent sans étape d’examen supplémentaire.

La stratégie d’examen recherche les exfiltrations de données, les tentatives d’accès aux identifiants, les affaiblissements persistants de la sécurité et les actions destructrices. Les actions à risque faible ou moyen peuvent être exécutées lorsque la stratégie l’autorise. La stratégie refuse les actions présentant un risque critique. Les actions à haut risque nécessitent une autorisation suffisante de l’utilisateur et ne doivent correspondre à aucune règle de refus. Les échecs de création de demande, de session d’examen et d’analyse entraînent un refus par défaut. Les délais d’expiration sont signalés séparément, mais l’action n’est toujours pas exécutée.

La stratégie d’examen par défaut se trouve dans le dépôt open source de Codex. Les entreprises peuvent remplacer sa section propre au locataire par guardian_policy_config dans les exigences administrées. Le texte local [auto_review].policy est également pris en charge, mais les exigences administrées sont prioritaires. Pour en savoir plus sur la configuration, consultez la configuration administrée.

Dans l’application de bureau ChatGPT, ces examens apparaissent comme des éléments d’examen automatique avec un statut tel que En cours d’examen, Approuvé, Refusé, Interrompu ou Expiré. Ils peuvent également inclure un niveau de risque et une évaluation de l’autorisation de l’utilisateur pour la demande examinée.

L’examen automatique utilise des appels de modèle supplémentaires et peut donc accroître l’utilisation de Codex. Les administrateurs peuvent le limiter avec allowed_approvals_reviewers.

Combinaisons courantes de sandbox et d’approbations

Pour les exécutions non interactives, utilisez codex exec --sandbox workspace-write ; Codex conserve les anciens appels codex exec --full-auto comme mécanisme de compatibilité obsolète et affiche un avertissement.

Avec --ask-for-approval untrusted, Codex n’exécute automatiquement que les opérations de lecture reconnues comme sûres. Les commandes susceptibles de modifier l’état ou de déclencher des chemins d’exécution externes (par exemple, les opérations Git destructrices ou les options de sortie/de remplacement de configuration de Git) nécessitent une approbation.

Configuration dans config.toml

Pour en savoir plus sur le processus général de configuration, consultez les notions de base de la configuration, la configuration avancée et la référence de configuration.

# Always ask for approval mode
approval_policy = "untrusted"
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 également enregistrer des préréglages sous forme de 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"

Tester la sandbox localement

Pour voir ce qui se passe lorsqu’une commande s’exécute dans la sandbox 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 aux plateformes disposent d’alias (par exemple codex sandbox seatbelt et codex sandbox landlock).

Sandbox au niveau du système d’exploitation

Codex applique la sandbox différemment selon votre système d’exploitation :

• macOS utilise les stratégies Seatbelt et exécute les commandes à l’aide de sandbox-exec avec un profil (-p) correspondant au mode --sandbox que vous avez sélectionné. Lorsque l’accès en lecture restreint active les valeurs par défaut de la plateforme, Codex ajoute une stratégie de plateforme macOS soigneusement sélectionnée (au lieu d’autoriser largement /System) afin de préserver la compatibilité avec les outils courants.
• Linux utilise bwrap ainsi que seccomp par défaut.
• Windows utilise l’implémentation de sandbox Linux lors de l’exécution dans le Sous-système Windows pour Linux 2 (WSL2). WSL1 était pris en charge jusqu’à Codex 0.114 ; à partir de 0.115, la sandbox Linux est passée à bwrap, de sorte que WSL1 n’est plus pris en charge. Lorsqu’il s’exécute nativement sous Windows, Codex utilise une implémentation de sandbox Windows.

Si vous utilisez l’extension Codex IDE sous Windows, elle prend directement en charge WSL2. Ajoutez le paramètre suivant à vos réglages VS Code afin de maintenir l’agent dans WSL2 dès que celui-ci est disponible :

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Ainsi, l’extension IDE hérite de la sémantique de la sandbox 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.

Lors d’une exécution native sous Windows, configurez le mode de sandbox 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 en savoir plus.

Lorsque vous exécutez Linux dans un environnement conteneurisé tel que Docker, la sandbox peut ne pas fonctionner si la configuration de l’hôte ou du conteneur bloque l’espace de noms, les opérations setuid bwrap ou les opérations seccomp nécessaires à Codex.

Dans ce cas, configurez votre conteneur Docker afin qu’il fournisse l’isolation dont vous avez besoin, puis exécutez codex avec --sandbox danger-full-access (ou l’option --dangerously-bypass-approvals-and-sandbox) dans le conteneur.

Exécuter Codex dans des Dev Containers

Si votre hôte ne peut pas exécuter directement la sandbox Linux, ou si votre organisation a déjà standardisé son développement sur des conteneurs, exécutez Codex avec des Dev Containers et laissez Docker fournir la limite d’isolation externe. Cette approche fonctionne avec Visual Studio Code Dev Containers et les outils compatibles.

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

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

• une image de base Ubuntu 24.04 avec Codex et les outils de développement courants installés ;
• un profil de pare-feu basé sur une liste d’autorisation pour les accès sortants ;
• 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, afin 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 d’exemple .devcontainer de 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 également démarrer le conteneur depuis la CLI :

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

L’exemple comporte 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 de réseau sortant.

Le pare-feu de référence est volontairement conçu comme un point de départ. Si vous comptez sur une liste d’autorisation de domaines pour assurer l’isolation, mettez en œuvre des protections contre le rebinding DNS et le rafraîchissement DNS adaptées à votre environnement, telles que des actualisations tenant compte du TTL ou un pare-feu compatible DNS.

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

• Laissez le bac à sable Linux de Codex activé si le profil Dev Container accorde les capacités dont bwrap a besoin pour créer le bac à sable interne.
• Si le conteneur constitue la limite de sécurité souhaitée, exécutez Codex avec --sandbox danger-full-access dans le conteneur afin que Codex ne tente pas de créer une seconde couche de bac à sable.

Gestion des versions

Codex fonctionne de manière optimale avec un processus de gestion des versions :

• Travaillez sur une branche de fonctionnalité et assurez-vous que git status est propre avant de déléguer. Les correctifs de Codex seront ainsi plus faciles à isoler et à annuler.
• Privilégiez les processus basés sur des correctifs (par exemple, git diff/git apply) plutôt que la modification directe des fichiers suivis. Effectuez des commits fréquents afin de pouvoir revenir en arrière par petits incréments.
• Traitez les suggestions de Codex comme n’importe quelle autre PR : exécutez des vérifications ciblées, examinez les différences et documentez les décisions dans les messages de commit à des fins d’audit.

Surveillance et télémétrie

Codex prend en charge une surveillance facultative via OpenTelemetry (OTel) afin d’aider les équipes à auditer l’utilisation, à examiner les problèmes et à satisfaire aux 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 ; activez-la explicitement dans votre configuration.

Vue d’ensemble

• Codex désactive par défaut l’exportation OTel afin que les exécutions locales restent autonomes.
• Lorsqu’elle est activée, Codex émet des événements de journal structurés couvrant les conversations, les requêtes API, l’activité des flux SSE/WebSocket, les invites utilisateur (masquées 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 (origine), la version de la CLI et une étiquette d’environnement permettant de séparer le trafic de développement, de préproduction et de production.

Activer OTel (facultatif)

Ajoutez un bloc [otel] à votre configuration Codex (généralement ~/.codex/config.toml), en choisissant un exportateur et en indiquant si le texte des invites 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" laisse l’instrumentation active, mais n’envoie les données nulle part.
• 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 les vide lors de l’arrêt. Codex 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, politique de bac à sable/d’approbation)
• codex.api_request (tentative, état/réussite, durée et détails de l’erreur)
• codex.sse_event (type d’événement de flux, réussite/échec, durée, ainsi que le nombre de tokens sur response.completed)
• codex.websocket_request et codex.websocket_event (durée de la requête, ainsi que type/réussite/erreur pour chaque message)
• codex.user_prompt (longueur ; contenu masqué sauf activation explicite)
• codex.tool_decision (approuvé/refusé, source : configuration ou utilisateur)
• codex.tool_result (durée, réussite, extrait de 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 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 invites. Les invites peuvent contenir du code source et des données sensibles.
• Acheminez la télémétrie uniquement vers des collecteurs que vous contrôlez ; appliquez des limites de conservation et des contrôles d’accès conformes à vos exigences de conformité.
• Considérez les arguments et les sorties des outils comme sensibles. Privilégiez si possible le masquage 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 ne souhaitez pas 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 avec l’accès réseau désactivé, l’exportation OTel ne peut pas atteindre votre collecteur. Pour exporter les données, autorisez l’accès 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 afin de détecter les changements d’approbation ou de bac à sable et les exécutions d’outils inattendues.

OTel est facultatif et conçu pour compléter, et non remplacer, les protections de bac à sable et d’approbation 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 la section Configuration gérée. Consultez cette page pour connaître les détails de configuration et de politique.