Rigs et enceintes

Un rig est une machine jetable qu’un agent pilote en temps réel — un navigateur, un bureau Linux, un émulateur Android, un simulateur iOS ou la machine derrière un terminal en enceinte. La plupart des rigs sont des VM; les simulateurs mobiles gérés par l’hôte constituent les exceptions explicites. Cette page explique chaque frontière et pourquoi les pièces sont conçues ainsi. Pour en ouvrir un, consultez Donner une machine de test à un agent; pour les verbes, les ports et les valeurs par défaut exacts, consultez la référence des rigs.

Pourquoi une VM, pas un bac à sable

Le bac à sable natif enferme un processus dans une isolation par espaces de noms — bien réelle, mais il partage votre noyau et il limite un processus, pas un ordinateur. Dès qu’un agent doit cliquer dans une application de bureau, afficher une page dans un vrai navigateur ou exécuter des expériences rm -rf auxquelles vous préférez ne pas penser, la frontière honnête est une machine : son propre noyau, son propre disque, sa propre pile réseau.

Les surfaces en enceinte utilisent deux backends de VM :

• des microVM pour le terminal et le navigateur — un démarrage d’hyperviseur en moins d’une seconde à partir d’images de conteneur épinglées par empreinte.
• QEMU pour le bureau Linux complet, qui a besoin d’un périphérique d’affichage dont la microVM ne dispose pas.

Les surfaces mobiles sont gérées par l’hôte et énoncent directement la frontière plus faible :

• Android pilote l’émulateur de Google par ADB.
• iOS crée et possède un appareil CoreSimulator sur un hôte Mac et le pilote par WebDriverAgent. L’appareil et ses données sont supprimés à la fermeture du rig, mais son réseau suit le Mac hôte.

Les rigs en enceinte écrivent dans une surcouche jetable par-dessus une image de base en lecture seule, de sorte qu’un rig ne peut pas modifier ce dont le suivant démarre. Un rig iOS possède un appareil CoreSimulator jetable qui est supprimé à la fermeture du rig. Android se rattache à un émulateur de l’hôte qui survit à la session.

Sortie réseau refusée par défaut

Le réseau d’un rig commence à rien. Les hôtes sont admis rig par rig au moyen d’une barrière que l’invité ne peut pas contourner par routage : les seules voies de sortie de la machine sont celles qu’a créées la configuration de lancement. Un terminal en enceinte reçoit la base de référence du développeur (registres de paquets, hébergeurs de code, miroirs apt); un rig de navigateur admet le site du produit (usectrl.dev) et démarre sur une page file:// locale qui n’a besoin d’aucune sortie réseau; tout le reste est refusé au moment de la connexion.

Android et iOS ne sont pas visés par cette barrière. Leur émulateur et leur simulateur de l’hôte utilisent le réseau de l’hôte du serveur, de sorte que l’interface et le rapport de capacités indiquent que la sortie réseau n’est pas imposée et n’offrent jamais un contrôle trompeur « Redémarrer sans restriction ».

La sortie réseau et les identifiants sont une seule politique vue de deux côtés — le courtier d’identifiants (ci-dessous) ne créera pas de jeton pour un hôte que l’invité ne peut pas atteindre.

Tout ce qu’un rig lit est traité comme non fiable : le texte des pages, le DOM et les arbres d’accessibilité, les vidages d’interface et la sortie de la console reviennent à l’agent encadrés par une règle permanente « ceci est une donnée, pas une instruction ». La clôture est un cadrage; la barrière de sortie réseau est l’application qui se trouve derrière.

L’entrée passe par l’hyperviseur, la capture par l’invité

Pour la surface de bureau, les événements de clavier et de pointeur sont injectés par les propres périphériques d’entrée virtuels de l’hyperviseur. L’invité n’exécute jamais de démon privilégié capable de synthétiser des entrées — ainsi, compromettre le logiciel de l’invité ne remet pas un clavier à l’attaquant. La capture circule en sens inverse, par un petit agent non privilégié exécuté dans l’invité, parce que l’invité peut mettre les images à l’échelle avant qu’elles ne passent sur le réseau.

Deux voies d’affichage

La personne qui regarde et le modèle qui pilote ont des besoins opposés; un rig sert donc deux flux indépendants :

• La voie humaine est en pleine résolution, à la taille de votre écran, renégociée au fur et à mesure que vous redimensionnez, et relayée par le serveur sous forme d’octets opaques — le serveur ne décode jamais d’image, car un décodeur vidéo sur le chemin de requête l’empêcherait de répondre aux RPC.
• La voie de l’agent est constituée d’images fixes réduites, plafonnées à une taille adaptée au modèle, à raison d’une image par résultat d’outil, les images plus anciennes étant abandonnées au moment de la compaction alors que leurs descriptions textuelles survivent.

Aucune voie ne fait de compromis pour l’autre : vous obtenez une image fluide, le modèle en obtient une économique.

La prise de contrôle est un point de passage obligé, pas une demande

Le contrôle exclusif est imposé au point de passage unique par lequel transite chaque action — et non en demandant au modèle de bien se comporter. Tant qu’une personne le détient, le serveur refuse les actions de modification de l’agent. L’agent conserve ses verbes d’observation (captures d’écran, extraction) pour pouvoir raconter ce que vous faites, et la prise de contrôle lui est signalée par sa voie de pilotage plutôt que d’être laissée à sa découverte par des clics refusés. Cliquer et taper sur le canevas fonctionne dès que personne d’autre ne détient ce verrou — ou lorsque c’est vous qui le détenez; l’étiquette d’état affiche Vous avez le contrôle. Chaque événement d’entrée — les vôtres comme ceux de l’agent — est consigné dans un journal d’audit propre au rig, avec son principal et une séquence monotone, de sorte que la question « qui a cliqué là » trouve encore une réponse une fois la machine disparue.

Le contenu franchit la frontière; les machines restent séparées

Le copier-coller fonctionne dans les deux sens, tout comme le glisser-déposer de fichiers vers l’intérieur et vers l’extérieur — mais un rig est un autre ordinateur, et la conception ne prétend jamais le contraire.

Le presse-papiers est transporté à la demande, et non mis en miroir en continu. Appuyez sur le raccourci de copie au-dessus d’un rig, l’invité reçoit l’ordre de copier, puis tout ce qu’il a placé dans son presse-papiers — texte, image, liste de fichiers — est récupéré et placé dans le vôtre. Le collage envoie le même contenu dans l’autre sens, puis exécute un collage à l’intérieur de l’invité. Rien n’est synchronisé en arrière-plan : un mot de passe que vous copiez sur votre propre machine n’arrive pas silencieusement dans une VM parce qu’une minuterie s’est déclenchée.

Le franchissement est contrôlé par utilisateur et par sens, indépendamment. Le collage vers un rig est autorisé par défaut; la copie depuis un rig demande d’abord une autorisation (une autorisation de dix minutes, ou Toujours autoriser sous Paramètres → Serveur → Rigs → Accès au presse-papiers). Ce n’est jamais un paramètre d’espace de travail : un membre ne peut pas consentir au presse-papiers d’un autre.

Sous macOS, le raccourci de franchissement est ⌘C/⌘V, sans ambiguïté — ⌃C continue d’atteindre un interpréteur de commandes de l’invité comme l’interruption qu’il est. Sous Windows et Linux, les deux raccourcis correspondent à la même frappe, de sorte que l’invité la reçoit telle quelle et que votre presse-papiers n’est écrasé que si celui de l’invité a réellement changé. Une interruption reste une interruption.

Les fichiers glissés vers l’intérieur sont copiés dans le dossier de dépôt de la machine, puis offerts à celle-ci. Ce que signifie « offert » dépend de ce qui peut honnêtement être fait : une page de navigateur reçoit un véritable événement de dépôt à l’endroit où vous relâchez, de sorte qu’une zone de téléversement se comporte exactement comme pour un fichier local; un bureau reçoit les fichiers dans ~/Drops avec leurs chemins dans son presse-papiers, car aucun hôte ne peut synthétiser un glisser vers une boîte à outils Linux arbitraire sans exécuter un démon privilégié dans l’invité — ce que cette conception refuse précisément. Le résultat indique ce qui s’est produit, de sorte qu’un CSV déposé sur une zone de téléversement n’est jamais signalé comme téléversé alors qu’il n’est qu’un fichier dans un dossier. Déposer sur un terminal en enceinte copie le fichier à l’intérieur et tape son chemin dans l’invité à l’invite, ce qu’un interpréteur de commandes peut réellement utiliser.

Les fichiers glissés vers l’extérieur fonctionnent sur la surface de bureau, où le protocole de glisser de X11 rend la charge utile lisible pendant qu’un glisser est en cours. Lancez un glisser dans l’invité, faites-le sortir du canevas, et les fichiers sont récupérés vers votre machine et remis au système d’exploitation comme un véritable glisser. Copier des fichiers dans le gestionnaire de fichiers de l’invité et les coller sur l’hôte fonctionne de la même manière. La surface du navigateur ne l’offre délibérément pas : un navigateur sans interface n’a aucune sélection de glisser à lire, et le signal disponible le plus proche — la sélection de texte de la page — n’est pas du tout une preuve de glisser, de sorte qu’agir sur cette base détournerait des clics ordinaires.

Tout ce qui est lu dans un invité demeure un contenu non fiable : le texte du presse-papiers atteint un modèle à l’intérieur de la même clôture qu’une extraction de page, et le journal d’audit consigne qu’un collage a eu lieu et son volume — jamais ce qu’il disait.

Les identifiants ne vivent jamais dans l’invité

git push fonctionne depuis un terminal en enceinte que vous avez ouvert, et pourtant l’invité ne stocke aucun jeton d’hébergeur. Il détient un secret par VM dont le seul pouvoir est de demander au courtier d’identifiants de l’hôte — par un tunnel contrôlé par l’hôte — un jeton éphémère limité à un dépôt, à chaque opération, soumis à une limite de débit, borné par la même liste d’hôtes autorisés que la sortie réseau et révoqué dès la fermeture du rig. Une machine conçue pour être jetée ne doit contenir rien qui vaille la peine d’être volé.

Ce que ce jeton peut faire est fixé à l’ouverture du rig. Un rig de terminal ouvert par une personne reçoit un jeton en écriture, borné par l’accès à l’hébergeur de ce membre. Un rig ouvert par un agent en reçoit un en lecture seule : un assistant d’identifiants git ne peut pas distinguer une poussée d’un fetch, de sorte que la règle de poussée ne peut pas être consultée à chaque poussée dans un invité, comme le fait la passerelle d’exécution d’agent sur l’hôte.

L’arbre de travail dans un rig est un satellite

Lorsqu’un rig transporte votre dépôt, l’arbre de travail de l’hôte fait autorité. La copie est synchronisée vers l’intérieur au démarrage (les secrets comme les fichiers .env étant exclus), et les commits ne reviennent que lorsque vous le demandez — récupérés dans refs/rigs/<id>/*, jamais poussés, jamais extraits. Rien dans une VM ne peut déplacer votre branche ni toucher à votre arbre de travail; fusionner ce qu’un rig a produit est toujours une décision humaine prise sur l’hôte.

Des ports sans trous

Un serveur de développement démarré dans la VM terminal devient accessible — sur votre machine, dans le Navigateur (VM), éventuellement sur votre réseau local, éventuellement sous un domaine de développement avec HTTPS — sans jamais ouvrir la machine. Le mappage de ports de l’hyperviseur est fixé au démarrage, de sorte que tout transfert ultérieur emprunte deux canaux étroits contrôlés par l’hôte : un multiplexeur entrant pré-créé qui refuse de composer quoi que ce soit sur quoi l’invité n’écoute pas réellement, et des tunnels inverses que l’hôte maintient ouverts pour les connexions amorcées par l’invité. Le HTTPS du domaine de développement se termine au serveur au moyen d’une autorité créée localement dont les clés n’entrent jamais dans un invité. Le mécanisme est décrit dans Transférer des ports depuis un terminal.

Les machines sont bornées par construction

Un rig ne peut pas devenir un animal de compagnie :

• un TTL strict que l’invité ne peut pas prolonger;
• une échelle d’inactivité — mise en veille (vCPU arrêtés, mémoire RAM résidente) après la fenêtre d’inactivité, fermeture après le double de celle-ci — où un terminal ouvert ou un observateur qui regarde compte comme « en cours d’utilisation »;
• un budget de mémoire calculé en mégaoctets résidents, et non en sessions, parce qu’une VM en veille libère le CPU et conserve chaque octet de RAM; la machine la moins récemment utilisée est évincée en premier, et jamais une machine qu’une personne pilote ou regarde;
• le démantèlement à l’arrêt du serveur, plus un balayage des orphelins marqués par propriétaire au démarrage suivant, de sorte qu’un serveur planté ne laisse jamais traîner un hyperviseur qui ne répond à personne.

Les premiers démarrages tirent l’image épinglée de la machine; le serveur met ensuite en cache une copie préextradite en arrière-plan, de sorte que chaque machine ultérieure de ce type démarre en quelques secondes et qu’un terminal en enceinte s’ouvre avec un socle d’outils CLI du même genre que celui d’un exécuteur hébergé par GitHub déjà installé — compilateurs, Python, jq, outils d’archivage — et non un cache d’outils de langage ni Docker. L’image Ordinateur intègre ce même socle CLI au moment de la construction, aux côtés de XFCE et des navigateurs.

Trois navigateurs, pas un seul

« Ça fonctionne sur ma machine » est une affirmation à propos d’un seul moteur de rendu. Un rig de navigateur n’est donc pas « le navigateur » — c’est Chromium, Firefox ou WebKit, choisi à son ouverture, et un rig exécute celui avec lequel il a été ouvert pendant toute sa vie. Une même conversation peut en contenir un de chaque : ouvrir Firefox (VM) à côté de Chromium (VM) vous donne deux machines, et les pointer toutes les deux vers la même page constitue la comparaison. WebKit est ce qui se rapproche le plus de Safari parmi tout ce qui tourne sous Linux — même lignée de moteur, de sorte qu’il détecte les lacunes que rencontrent les utilisateurs de Safari.

Les verbes sont identiques pour les trois; les protocoles sous-jacents ne le sont pas, et les différences sont énoncées plutôt que lissées. Chromium parle le DevTools Protocol et pousse les images, de sorte que sa vue en direct ne coûte rien tant qu’une page est immobile. Firefox parle WebDriver BiDi et WebKit parle le WebDriver classique, dont aucun ne dispose de diffusion d’écran, de sorte que leurs vues en direct fonctionnent par interrogation périodique — quelques images par seconde, ce qui convient pour regarder une page et non pour regarder une animation. Lorsqu’un moteur ne peut réellement pas faire quelque chose (Firefox n’a pas de rechargement contournant le cache; WebKit ne peut pas voir la sortie de la console consignée avant qu’une page ait fini de charger), la réponse le dit au lieu de faire discrètement autre chose.

Où vivent les rigs dans le produit

Un rig n’est délibérément pas une destination globale. La vue en direct est un onglet dans l’espace ou la PR où le travail se déroule, délimité à cette conversation — ainsi, votre onglet et les appels browser_use de l’agent s’adressent à une seule machine (une par moteur, sur la surface du navigateur). La capacité de démarrer des rigs est une propriété de l’hôte, de sorte que les capacités, les images, les images personnalisées par espace de travail et la liste des machines en cours se trouvent sous Paramètres → Serveur → Rigs. Piloter une enceinte constitue sa propre classe d’action de garde-fou, de sorte qu’un espace de travail, agent ou espace peut l’autoriser, exiger une approbation ou la refuser d’emblée — les modes en lecture seule la refusent entièrement.