Bac à sable

Le bac à sable constitue la frontière qui permet à l’agent d’agir de manière autonome sans lui donner un accès illimité à votre machine. Lorsqu’une conversation locale exécute des commandes dans l’application de bureau ChatGPT, la Codex CLI ou l’extension IDE, ces commandes s’exécutent dans un environnement restreint au lieu de disposer par défaut d’un accès complet.

Cet environnement définit ce que l’agent peut faire de lui-même, notamment les fichiers qu’il peut modifier et la possibilité pour les commandes d’utiliser le réseau. Tant qu’une tâche reste dans ces limites, l’agent peut poursuivre son travail sans s’arrêter pour demander une confirmation. Lorsqu’il doit les dépasser, le processus d’approbation prend le relais.

Rôle du bac à sable

Le bac à sable s’applique aux commandes lancées, et pas seulement aux opérations intégrées sur les fichiers. Si l’agent exécute des outils comme git, des gestionnaires de paquets ou des outils d’exécution de tests, ces commandes héritent des mêmes limites du bac à sable.

Codex utilise les mécanismes de contrôle natifs de chaque système d’exploitation. L’implémentation diffère entre macOS, Linux, WSL2 et Windows natif, mais le principe reste le même sur toutes les interfaces : fournir à l’agent un espace de travail délimité afin que les tâches courantes puissent s’exécuter de manière autonome dans des limites claires.

Pourquoi est-ce important ?

Le bac à sable réduit la lassitude liée aux approbations. Au lieu de vous demander de confirmer chaque commande à faible risque, l’agent peut lire des fichiers, effectuer des modifications et exécuter les commandes courantes du projet dans les limites que vous avez déjà approuvées.

Il vous offre également un modèle de confiance plus clair pour le travail agentique. Vous ne faites pas que vous fier aux intentions de l’agent : vous avez aussi l’assurance que l’agent opère dans des limites imposées. Vous pouvez ainsi plus facilement le laisser travailler de manière autonome tout en sachant quand il s’arrêtera pour demander votre intervention.

Prise en main

Le mode d’autorisations par défaut applique automatiquement le bac à sable.

Prérequis

Sous macOS, le bac à sable fonctionne directement grâce au framework Seatbelt intégré.

Sous Windows, Codex utilise le bac à sable Windows natif lorsque vous travaillez dans PowerShell, et l’implémentation Linux du bac à sable lorsque vous travaillez dans WSL2.

Sous Linux et WSL2, commencez par installer bubblewrap avec votre gestionnaire de paquets :

Ubuntu/Debian

sudo apt install bubblewrap

Fedora

sudo dnf install bubblewrap

Codex utilise le premier exécutable bwrap trouvé dans PATH. Si aucun exécutable bwrap n’est disponible, Codex se rabat sur un utilitaire fourni, mais celui-ci nécessite la prise en charge de la création d’espaces de noms utilisateur sans privilèges. L’installation du paquet de la distribution qui fournit bwrap garantit la fiabilité de cette configuration.

Codex affiche un avertissement au démarrage lorsque bwrap est absent ou lorsque l’utilitaire ne peut pas créer l’espace de noms utilisateur requis. Sur les distributions qui restreignent ce paramètre AppArmor, privilégiez le chargement du profil AppArmor bwrap afin que bwrap puisse continuer à fonctionner sans désactiver globalement la restriction.

Fonctionnement des autorisations

Utilisez le contrôle des autorisations de votre interface pour modifier la manière dont Codex gère les actions locales.

Les approbations déterminent quand Codex s’interrompt avant une action, tandis que le bac à sable détermine les fichiers et les ressources réseau auxquels les commandes peuvent accéder. Lorsqu’une approbation propose différentes portées, comme une approbation ponctuelle ou valable pour la session, choisissez la portée la plus restreinte permettant à la tâche de continuer. Conservez les limites du projet par défaut ; utilisez des projets ou des worktrees distincts au lieu d’élargir l’accès à des dépôts sans rapport.

Dans l’application de bureau ChatGPT, utilisez le contrôle des autorisations situé sous la zone de saisie. Selon votre configuration, le menu peut inclure Demander une approbation, Approuver à ma place pour les demandes d’approbation admissibles, Accès complet, ainsi que des profils d’autorisations nommés ou personnalisés.

Configurer les valeurs par défaut

Pour bénéficier du même comportement à chaque démarrage, définissez les valeurs par défaut dans config.toml. Principes de base de la configuration explique son fonctionnement, tandis que la Référence de configuration décrit les clés exactes pour sandbox_mode, approval_policy, approvals_reviewer et sandbox_workspace_write.writable_roots. Utilisez ces paramètres pour déterminer le degré d’autonomie accordé par défaut à l’agent, les répertoires dans lesquels il peut écrire, les situations où il doit s’interrompre pour demander une approbation et la personne chargée d’examiner les demandes d’approbation admissibles.

Dans les grandes lignes, les modes de bac à sable courants sont les suivants :

• read-only : l’agent peut examiner les fichiers, mais il ne peut ni les modifier ni exécuter de commandes sans approbation.
• workspace-write : l’agent peut lire les fichiers, les modifier dans l’espace de travail et exécuter des commandes locales courantes dans ces limites. Il s’agit du mode par défaut offrant le moins de contraintes pour le travail local.
• danger-full-access : l’agent s’exécute sans les restrictions du bac à sable. Ce mode supprime les limites du système de fichiers et du réseau ; ne l’utilisez que si vous souhaitez que l’agent dispose d’un accès complet.

Les politiques d’approbation courantes sont les suivantes :

• untrusted : l’agent demande une autorisation avant d’exécuter des commandes qui ne figurent pas dans son ensemble de confiance.
• on-request : l’agent travaille par défaut dans le bac à sable et demande une autorisation lorsqu’il doit dépasser ces limites.
• never : l’agent ne s’arrête pas pour afficher des demandes d’approbation.

Lorsque les approbations sont interactives, vous pouvez également choisir qui les examine avec approvals_reviewer :

• user : les demandes d’approbation sont présentées à l’utilisateur. Il s’agit du comportement par défaut.
• auto_review : les demandes d’approbation admissibles sont transmises à un agent réviseur (voir examen automatique).

L’accès complet consiste à utiliser sandbox_mode = "danger-full-access" avec approval_policy = "never". À l’inverse, le préréglage d’automatisation locale à moindre risque associe sandbox_mode = "workspace-write" à approval_policy = "on-request", ou utilise les options CLI correspondantes --sandbox workspace-write --ask-for-approval on-request. Vous pouvez ensuite conserver approvals_reviewer = "user" pour les approbations manuelles ou définir approvals_reviewer = "auto_review" pour l’examen automatique des approbations.

Si l’agent doit travailler dans plusieurs répertoires, les racines accessibles en écriture vous permettent d’étendre les emplacements qu’il peut modifier sans supprimer entièrement le bac à sable. Si vous avez besoin d’une limite de confiance plus large ou plus étroite, ajustez le mode de bac à sable et la politique d’approbation par défaut au lieu de vous appuyer sur des exceptions ponctuelles.

Lorsqu’un workflow nécessite une exception précise, utilisez les règles. Les règles vous permettent d’autoriser, de soumettre à approbation ou d’interdire des préfixes de commande en dehors du bac à sable, ce qui est souvent plus adapté qu’un élargissement général de l’accès. Pour connaître les points d’entrée des paramètres propres à l’IDE, consultez les paramètres de l’extension Codex IDE.

Lorsqu’il est disponible, l’examen automatique ne modifie pas les limites du bac à sable. Il s’agit d’une valeur possible de approvals_reviewer pour les demandes d’approbation à cette limite, comme les élévations de privilèges du bac à sable, les accès réseau bloqués ou les appels d’outils produisant des effets de bord qui nécessitent encore une approbation. Les actions déjà autorisées dans le bac à sable s’exécutent sans examen supplémentaire. Pour en savoir plus sur le cycle de vie du réviseur, les types de déclencheurs, la sémantique des refus et les détails de configuration, consultez l’examen automatique.

Les détails propres à chaque plateforme figurent dans la documentation correspondante. Pour en savoir plus sur la configuration, le comportement et le dépannage sous Windows natif, consultez Windows. Pour connaître les exigences relatives aux administrateurs et les contraintes organisationnelles concernant le bac à sable et les approbations, consultez Approbations des agents et sécurité.