Bac à sable

Le bac à sable définit les limites qui permettent à l’agent d’agir de manière autonome sans lui donner un accès sans restriction à votre machine. Lorsqu’une discussion locale exécute des commandes dans l’application de bureau ChatGPT, Codex CLI ou l’extension IDE, ces commandes s’exécutent dans un environnement restreint au lieu de bénéficier par défaut d’un accès complet.

Cet environnement détermine ce que l’agent peut faire de lui-même, notamment les fichiers qu’il peut modifier et si les commandes peuvent accéder au 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. S’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 tels que git, des gestionnaires de paquets ou des outils d’exécution de tests, ces commandes sont soumises aux mêmes limites du bac à sable.

Codex s’appuie sur les mécanismes de contrôle natifs de chaque système d’exploitation. L’implémentation diffère sur macOS, Linux, WSL2 et Windows en natif, mais le principe reste le même dans les différentes interfaces : fournir à l’agent un environnement de travail délimité, afin que les tâches courantes puissent s’exécuter de façon autonome dans des limites clairement définies.

Pourquoi c’est important

Le bac à sable réduit la lassitude liée aux demandes d’approbation. Au lieu de vous demander de confirmer chaque commande à faible risque, l’agent peut lire des fichiers, les modifier et exécuter les commandes courantes du projet dans le périmètre que vous avez déjà approuvé.

Le bac à sable vous donne aussi un cadre de confiance plus clair pour le travail avec un agent. Votre confiance ne repose pas seulement sur les intentions de l’agent, mais aussi sur les limites techniques qui lui sont imposées. Vous pouvez ainsi plus facilement le laisser travailler de façon autonome, tout en sachant quand il s’arrêtera pour demander de l’aide.

Bien démarrer

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

Prérequis

Sur macOS, le bac à sable fonctionne sans configuration supplémentaire grâce au framework Seatbelt intégré.

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

Sur Linux et WSL2, installez d’abord 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 utilise à la place un utilitaire intégré, 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 assure la fiabilité de cette configuration.

Codex affiche un avertissement au démarrage si bwrap est absent ou si l’utilitaire ne peut pas créer l’espace de noms utilisateur requis. Sur les distributions qui appliquent cette restriction AppArmor, chargez de préférence le profil AppArmor bwrap afin que bwrap puisse continuer à fonctionner sans désactiver globalement la restriction.

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

sudo systemctl reload apparmor.service

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Utilisez le réglage des autorisations de votre interface pour modifier la façon 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 demande d’approbation propose différentes portées, par exemple une approbation ponctuelle ou valable pour toute la session, choisissez la portée la plus restreinte qui permette à la tâche de continuer. Conservez par défaut les limites du projet ; utilisez des projets ou des arbres de travail distincts au lieu d’étendre l’accès à des dépôts sans rapport entre eux.

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 à chaque outil déterminent les fonctionnalités disponibles. Lorsque le 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 ne peuvent accéder qu’aux 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 de code ou de commandes shell en cours terminée et après que Work a actualisé son environnement d’exécution. La version web de ChatGPT ne donne accès ni au bac à sable local de Codex ni au sélecteur de mode d’approbation.

Dans l’application de bureau ChatGPT, utilisez le réglage des autorisations sous la zone de saisie. Selon votre configuration, le menu peut inclure Demander l’approbation, Approuver à ma place pour les demandes d’approbation éligibles, 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 modifier le profil d’autorisations actif.

Dans l’extension IDE, utilisez le réglage des autorisations sous la zone de saisie. Selon votre configuration, le menu peut inclure Demander l’approbation, Approuver à ma place pour les demandes d’approbation éligibles, Accès complet, ainsi que des profils d’autorisations nommés ou personnalisés.

Configuration des valeurs par défaut

Pour retrouver le même comportement à chaque démarrage, définissez des valeurs par défaut dans config.toml. La page Principes de configuration en explique le fonctionnement, et la Référence de configuration documente précisément les clés 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 cas où il doit s’interrompre pour demander une approbation et qui examine les demandes d’approbation éligibles.

Voici un aperçu des principaux modes de bac à sable :

• read-only : l’agent peut consulter les fichiers, mais ne peut ni les modifier ni exécuter de commandes sans approbation.
• workspace-write : l’agent peut lire des fichiers, effectuer des modifications dans l’espace de travail et exécuter des commandes locales courantes à l’intérieur de ce périmètre. C’est le mode par défaut, conçu pour fluidifier le travail local.
• danger-full-access : l’agent fonctionne sans les restrictions du bac à sable. Ce mode supprime les restrictions d’accès au système de fichiers et au réseau. Ne l’utilisez que si vous souhaitez que l’agent agisse avec un accès complet.

Les principales politiques d’approbation sont les suivantes :

• on-request : l’agent travaille par défaut dans le bac à sable et demande une approbation lorsqu’il doit en dépasser les limites.
• never : l’agent ne s’arrête pas pour demander une approbation.

Codex et ChatGPT Work ne permettent plus de sélectionner untrusted comme politique d’approbation. Si une configuration existante utilise cette valeur, consultez Migration depuis la politique d’approbation untrusted retirée.

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. C’est le réglage par défaut.
• auto_review : les demandes d’approbation éligibles sont transmises à un agent chargé de les examiner (voir révision automatique).

L’accès complet consiste à utiliser sandbox_mode = "danger-full-access" avec approval_policy = "never". En revanche, 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 la révision automatique des demandes d’approbation.

Si l’agent doit travailler dans plusieurs répertoires, les racines accessibles en écriture permettent d’étendre les emplacements qu’il peut modifier sans supprimer entièrement le bac à sable. Si vous avez besoin d’un périmètre de confiance plus large ou plus restreint, 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. Elles permettent d’autoriser, de soumettre à approbation ou d’interdire des préfixes de commandes hors du bac à sable, ce qui est souvent plus adapté qu’un élargissement général de l’accès. Pour savoir où accéder aux paramètres propres à l’IDE, consultez les paramètres de l’extension IDE Codex.

La révision automatique, lorsqu’elle est disponible, ne modifie pas les limites du bac à sable. C’est une option possible pour approvals_reviewer afin de traiter les demandes d’approbation à ces limites, comme les demandes de sortie du bac à sable, les accès réseau bloqués ou les appels d’outils ayant des effets sur le système 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 de l’agent chargé de la révision, les types de déclencheurs, la signification des refus et les détails de configuration, consultez la révision automatique.

Les détails propres à chaque plateforme figurent dans sa documentation. Pour la configuration native sur Windows, le fonctionnement et le dépannage, consultez Windows. Pour les exigences d’administration et les contraintes de l’organisation concernant le bac à sable et les approbations, consultez Autorisations de l’agent et sécurité.