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 du bac à sable Linux lorsque vous travaillez dans WSL2.

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

sudo apt install bubblewrap

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.

ChatGPT Work exécute le code et les commandes shell dans un environnement géré et isolé. La politique de l’espace de travail et les contrôles propres aux outils déterminent les fonctionnalités disponibles. Lorsque ce paramètre est disponible, utilisez Paramètres > Contrôles des données > Accès réseau de Work pour gérer l’accès réseau du code et des commandes shell. Activez Autoriser l’accès à l’Internet public pour permettre à ces commandes d’accéder à l’Internet public. Lorsque cette option est désactivée, les commandes peuvent uniquement atteindre les noms d’hôte requis figurant dans une liste d’autorisation gérée.

La recherche Web, les plugins et le navigateur distant disposent de contrôles distincts. Les modifications prennent effet une fois l’exécution en cours du code ou du shell terminée et après que Work a actualisé son environnement d’exécution. ChatGPT web ne donne pas accès au sélecteur local du bac à sable ou du mode d’approbation de Codex.

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.

Dans la CLI, saisissez /permissions pour ouvrir le sélecteur d’autorisations et changer le profil d’autorisations actif.

Dans l’extension IDE, utilisez le contrôle des autorisations 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 démarrer systématiquement avec le même comportement, définissez les valeurs par défaut dans config.toml. Principes de base de la configuration explique son fonctionnement, et la Référence de configuration documente les clés exactes de 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, quand il doit s’interrompre pour demander une approbation et qui examine 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 de la valeur par défaut.
• auto_review : les demandes d’approbation éligibles sont transmises à un agent réviseur (voir révision 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 spécifique, utilisez les règles. Les règles vous permettent d’autoriser, de soumettre à confirmation ou d’interdire des préfixes de commandes hors du bac à sable, ce qui est souvent plus adapté que d’élargir considérablement l’accès. Pour connaître les points d’accès aux paramètres propres à l’IDE, consultez les paramètres de l’extension Codex pour IDE.

La révision automatique, lorsqu’elle est disponible, ne modifie pas les limites du bac à sable. Elle constitue l’une des valeurs possibles 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 toujours une approbation. Les actions déjà autorisées dans le bac à sable s’exécutent sans révision 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 la révision automatique.

Les détails propres à chaque plateforme figurent dans la documentation correspondante. Pour en savoir plus sur la configuration native de Windows, son comportement et la résolution des problèmes, consultez Windows. Pour connaître les exigences applicables aux administrateurs et les contraintes au niveau de l’organisation concernant le bac à sable et les approbations, consultez Approbations et sécurité des agents.