Le bac à sable des commandes

Les bulles dotées de l’outil Run commands peuvent exécuter des commandes dans votre projet : installer des paquets, lancer des compilations et des tests. Trois couches décident de ce qui s’exécute réellement.

1. Ce qu’une bulle peut faire

Chaque rôle dispose d’un ensemble fixe d’outils. Un Coder peut écrire des fichiers et exécuter des commandes ; un Reviewer peut exécuter des commandes mais pas écrire des fichiers ; un Researcher ne peut faire ni l’un ni l’autre. Les outils d’un rôle intégré sont fixes. Pour en choisir d’autres, créez une bulle personnalisée.

Les outils de fichiers maintiennent toujours un loop rattaché à son dossier. Ses commandes y sont maintenues par le système d’exploitation uniquement lorsque Sandbox agent commands est activé (ci-dessous). Sans le bac à sable, une commande désignant un fichier situé hors du dossier est refusée, mais un script, une compilation ou un gestionnaire de paquets lancé par une commande peut toujours écrire n’importe où dans le projet.

2. Le filtre de commandes

Chaque commande est lue avant son exécution et reçoit l’une des trois réponses suivantes.

Refusée, systématiquement :

• lancer un shell directement (bash, sh, cmd, powershell, wsl) et tout ce qui modifie le shell lui-même ;
• l’accès à distance (ssh, scp, rsync et similaires), l’arrêt de processus, la modification de permissions ;
• les commandes git destructrices (reset --hard, clean -f, pushes forcés, commandes interactives) et la publication de paquets ;
• tout chemin situé hors du projet et tout fichier qui ressemble à un secret (.env, clés, certificats) ;
• une adresse web qui n’est pas un registre de paquets, GitHub, Docker Hub ou votre propre machine ;
• tout ce qui ne s’arrête jamais, comme un serveur de développement ou un mode de surveillance. Ces éléments ont leur place dans un terminal.

Demandée, sauf si vous avez activé Full Auto :

• les commits, pushes, merges, rebases, checkouts git et opérations similaires ;
• la suppression de fichiers à l’intérieur du dossier du loop ;
• l’exécution de code en ligne (node -e, python -c et similaires).

Autorisée : tout le reste, tel que npm install ou npm test.

Les commandes s’exécutent sans aucune variable d’environnement dont le nom contient KEY, SECRET, TOKEN, PASSWORD, CREDENTIAL ou PRIVATE. Une commande dispose de deux minutes, ou dix pour les gestionnaires de paquets, compilateurs et exécuteurs de tests. Une fois le temps écoulé, l’ensemble de l’arborescence des processus est arrêté.

Demande et Full Auto

Lorsqu’une commande requiert votre accord, l’application demande : Allow once, Allow always this session (pour ce type de commande sur ce tableau, jusqu’au redémarrage du gateway) ou Deny. Si aucune fenêtre n’est ouverte pour demander, ou si personne ne répond à temps, la commande est refusée.

Full Auto transforme chaque « demander » en « autoriser » pour un tableau. Cela ne modifie rien d’autre : les commandes refusées, les attributions d’outils et les dossiers s’appliquent toujours. L’option reste active jusqu’à ce que vous la désactiviez.

3. Le bac à sable

Le filtre lit une commande et refuse ce qu’il peut voir. Un script de compilation ou l’étape d’installation d’un paquet peut toujours écrire des fichiers qu’aucun argument ne nomme. Sandbox agent commands (dans Paramètres, désactivé par défaut) force également le système d’exploitation à respecter les dossiers :

• le projet est en lecture seule, le propre dossier du loop est inscriptible, les dossiers des autres loops qu’il contient sont en lecture seule et le dossier de l’application elle-même est en lecture seule ;
• il n’y a aucun accès réseau depuis l’intérieur du bac à sable.

Système	Méthode
Linux	bubblewrap (bwrap)
macOS	sandbox-exec
Windows	WSL avec bubblewrap (par défaut), ou Docker

Lorsque le bac à sable est actif, une commande qui ne peut pas être mise en bac à sable est refusée et ne s’exécute jamais sans lui. Si un backend n’est pas prêt, Paramètres affiche l’étape unique pour y remédier, avec la commande exacte à copier, par exemple l’installation de bubblewrap dans WSL.

Perfica n’installe jamais de bac à sable à votre place. L’image Docker n’est téléchargée qu’après confirmation d’une boîte de dialogue indiquant sa taille.

Windows, loops à la racine du projet

Sous Windows, le projet est accessible via le partage de fichiers de WSL, où la casse des noms n’est pas respectée. Pour un loop dont le dossier est l’ensemble du projet, une commande qui écrit le dossier de l’application avec une casse différente peut toujours y écrire. Les loops qui possèdent un sous-dossier ne sont pas concernés.

Le terminal

Le panneau du terminal au bas de l’application est votre propre shell (Bash, PowerShell ou CMD), et non celui des agents. Le filtre ne s’applique pas à celui-ci. Run in terminal place une commande provenant d’une réponse de chat ou d’une entrée de journal sur la ligne de saisie du terminal ; il n’appuie jamais sur Entrée à votre place.