Bac à sable

Le bac à sable permet à l’agent d’agir de manière autonome tout en limitant son accès à votre machine. Lorsqu’une discussion locale lance des commandes dans l’application de bureau ChatGPT, dans Codex CLI ou dans l’extension IDE, ces commandes s’exécutent par défaut dans un environnement à accès restreint.

Cet environnement détermine ce que l’agent peut faire de façon autonome, notamment les fichiers qu’il peut modifier et la possibilité pour les commandes d’accéder au réseau. Tant que la tâche respecte ces limites, l’agent peut poursuivre son travail sans vous demander de confirmation. S’il doit les dépasser, la procédure d’approbation prend le relais.

Fonctionnement du bac à sable

Le bac à sable s’applique aussi bien aux opérations intégrées sur les fichiers qu’aux commandes lancées par l’agent. Si l’agent utilise des outils comme git, des gestionnaires de paquets ou des outils d’exécution de tests, les commandes correspondantes héritent des mêmes restrictions.

Codex s’appuie sur les mécanismes de protection propres à chaque système d’exploitation. La mise en œuvre varie entre macOS, Linux, WSL2 et Windows en mode natif, mais le principe reste le même dans les différentes interfaces : l’agent dispose d’un environnement de travail délimité dans lequel il peut effectuer les tâches courantes de façon autonome.

Intérêt du bac à sable

Le bac à sable vous évite de multiplier les confirmations. Dans les limites que vous avez déjà approuvées, l’agent peut lire et modifier des fichiers et exécuter les commandes courantes du projet sans vous demander de confirmer chaque commande à faible risque.

Vous savez aussi sur quoi repose votre confiance lorsque vous déléguez une tâche à l’agent : au-delà de ses intentions, des mécanismes techniques lui imposent des limites. Vous pouvez ainsi le laisser travailler de façon autonome tout en sachant quand il s’arrêtera pour vous demander de l’aide.

Premiers pas

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 intégré Seatbelt.

Sur Windows, Codex utilise le bac à sable natif de Windows lorsque vous lancez Codex dans PowerShell, et le bac à sable de Linux lorsque vous le lancez 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 qu’il trouve dans PATH. Si aucun exécutable bwrap n’est disponible, Codex utilise un utilitaire fourni avec le logiciel. Celui-ci nécessite toutefois que le système autorise la création d’espaces de noms utilisateur sans privilèges. Pour garantir le bon fonctionnement de cette configuration, installez le paquet de votre distribution qui fournit bwrap.

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 nécessaire. Sur les distributions où AppArmor restreint cette opération, chargez de préférence le profil AppArmor de bwrap pour que bwrap puisse continuer à fonctionner sans désactiver la restriction à l’échelle du système.

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

Accès à l’ordinateur local avec Work Cloud

Pour les tâches qui utilisent l’accès à l’ordinateur local avec Work Cloud, le cloud d’OpenAI coordonne la conversation. Les restrictions du bac à sable dépendent de l’endroit où chaque étape s’exécute :

• Exécution dans le cloud : les conteneurs cloud de Work appliquent les politiques existantes de Work Cloud. Les règles d’accès aux sites du navigateur de bureau ne s’appliquent pas automatiquement aux navigateurs cloud.
• Exécution locale : les exigences prises en charge pour l’exécution locale s’appliquent aux étapes exécutées sur un ordinateur connecté.

Pour le mode Work avec accès local et pour les dots, l’orchestrateur cloud partagé applique les règles prises en charge de la politique Global 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 l’exécution locale et l’exécution dans le cloud pour vérifier quels contrôles s’appliquent dans chaque environnement. Une politique propre à un environnement ne donne pas accès à un autre.

Au sein d’une politique, l’ordre de priorité décroissant est le suivant : dérogation d’environnement propre à un système d’exploitation → dérogation d’environnement commune à tous les systèmes → Global. La politique prioritaire l’emporte même si une politique de priorité inférieure est plus spécifique. Pour l’exécution locale, les exigences MDM et les anciennes exigences applicables aux appareils gérés priment sur Agent Security, qui prime à son tour sur le fichier des exigences système de l’appareil.

Consultez la configuration gérée pour connaître les règles de fusion propres à chaque champ et les limites d’exécution. Vérifiez les restrictions d’accès aux fichiers et au réseau qui s’appliquent dans les sections Sécurité de Work en local et Sécurité de Work dans le cloud.

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 doit s’arrêter avant d’agir. Le bac à sable détermine à quels fichiers et ressources réseau les commandes peuvent accéder. Si plusieurs portées d’approbation vous sont proposées, par exemple pour une seule action ou pour toute la session, choisissez la plus restreinte qui permette de poursuivre la tâche. Par défaut, limitez l’accès au projet. Utilisez des projets ou des arbres de travail distincts pour éviter 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 réglage est disponible, ouvrez Paramètres > Contrôles des données > Accès réseau de Work pour gérer l’accès au 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 joindre que les noms d’hôte requis qui figurent sur 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 que l’exécution du code ou de la commande shell en cours est terminée et 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 proposer Demander l’approbation, Approuver pour moi pour les demandes d’approbation éligibles, Accès complet, ainsi que des profils d’autorisations nommés ou personnalisés.

Sélectionnez un mode pour explorer cet exemple. Votre choix ne modifie pas vos autorisations dans ChatGPT ou Codex.

Do anything

Approve for me

GPT-6 AstraLight

How should ChatGPT actions be approved?Learn more

• Ask for approvalAlways ask to edit external files and use the internet
• Approve for meOnly ask for actions detected as potentially unsafe
• Full accessUnrestricted access to the internet and any file on your computer
• Custom (config.toml)Uses permissions defined in config.toml

Approve for me

Approve for me keeps the same workspace-write sandbox as Ask for approval, but eligible approval requests are routed through automatic review instead of showing a prompt for manual approval. More details about automatic review.

Sandbox

workspace-write

Approvals policy

on-request

Reviewer

auto_review

Dans la CLI, saisissez /permissions pour ouvrir le sélecteur d’autorisations et changer de 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 proposer Demander l’approbation, Approuver pour moi 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 les valeurs par défaut dans config.toml. Les principes de configuration expliquent le fonctionnement de ce fichier. La référence de configuration décrit précisément les clés sandbox_mode, approval_policy, approvals_reviewer et sandbox_workspace_write.writable_roots. Ces paramètres vous permettent de définir l’autonomie accordée par défaut à l’agent, les répertoires dans lesquels il peut écrire, les situations où il doit demander une approbation et la personne ou l’agent chargé d’examiner les demandes éligibles.

Les principaux modes du bac à sable sont les suivants :

• read-only : l’agent peut consulter les fichiers, mais il doit obtenir une approbation pour les modifier ou exécuter des commandes.
• workspace-write : l’agent peut lire les fichiers, modifier ceux de l’espace de travail et y exécuter les commandes locales courantes. Ce mode par défaut facilite le travail en local.
• danger-full-access : l’agent s’exécute sans les restrictions du bac à sable. Ce mode lève les restrictions d’accès au système de fichiers et au réseau. Utilisez-le uniquement si vous souhaitez accorder un accès complet à l’agent.

Les principales politiques d’approbation sont les suivantes :

• on-request : l’agent travaille par défaut dans le bac à sable et demande une approbation s’il doit en dépasser les limites.
• never : l’agent ne s’interrompt 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 la section Migration depuis l’ancienne politique d’approbation untrusted.

Lorsque les approbations sont interactives, vous pouvez aussi choisir qui examine les demandes avec approvals_reviewer :

• user : les demandes d’approbation s’affichent pour l’utilisateur. Il s’agit de la valeur par défaut.
• auto_review : un agent examine les demandes d’approbation éligibles (voir la révision automatique).

Pour accorder un accès complet, associez sandbox_mode = "danger-full-access" à approval_policy = "never". Pour automatiser des tâches locales en limitant les risques, associez sandbox_mode = "workspace-write" à approval_policy = "on-request", ou utilisez les options CLI équivalentes --sandbox workspace-write --ask-for-approval on-request. Vous pouvez alors conserver approvals_reviewer = "user" pour les approbations manuelles ou définir approvals_reviewer = "auto_review" pour la révision automatique des demandes.

Si l’agent doit travailler dans plusieurs répertoires, les répertoires racines accessibles en écriture vous permettent d’étendre la zone qu’il peut modifier tout en conservant le bac à sable. Pour élargir ou restreindre durablement le périmètre de confiance, ajustez le mode du bac à sable et la politique d’approbation par défaut au lieu de multiplier les exceptions ponctuelles.

Lorsqu’un workflow nécessite une exception précise, utilisez des règles. En fonction du préfixe d’une commande, une règle permet d’autoriser son exécution hors du bac à sable, de la soumettre à approbation ou de l’interdire. Cette approche est souvent plus adaptée qu’une extension générale des droits d’accès. Pour savoir où trouver les réglages propres à l’IDE, consultez les paramètres de l’extension IDE de Codex.

La révision automatique, lorsqu’elle est disponible, ne modifie pas les limites du bac à sable. C’est l’un des choix possibles pour approvals_reviewer lorsqu’une action nécessite une approbation, par exemple pour exécuter une commande hors du bac à sable, accéder à une ressource réseau bloquée ou appeler un outil dont les effets nécessitent encore une approbation. Les actions déjà autorisées dans le bac à sable s’exécutent sans examen supplémentaire. Pour connaître le cycle de vie de l’agent chargé de la révision, les types de déclencheurs, les effets d’un refus et les détails de configuration, consultez la section Révision automatique.

La documentation de chaque plateforme en précise les particularités. Pour la configuration, le fonctionnement et le dépannage sous Windows en mode natif, consultez la section Windows. Pour connaître les exigences d’administration et les contraintes que l’organisation peut imposer au bac à sable et aux approbations, consultez la section Approbations et sécurité des agents.