Rig e recinti

Un rig è una macchina usa e getta che un agente guida in tempo reale — un browser, un desktop Linux, un emulatore Android, un simulatore iOS o la macchina dietro un terminale isolato. La maggior parte dei rig sono VM; i simulatori mobili gestiti dall’host sono le eccezioni esplicite. Questa pagina spiega ogni confine e perché i pezzi hanno la forma che hanno. Per aprirne uno, vedi Assegna a un agente una macchina su cui testare; per i verbi, le porte e i valori predefiniti esatti, vedi il riferimento sui rig.

Perché una VM, non un sandbox

Il sandbox nativo avvolge un processo in un isolamento di namespace — reale, ma condivide il tuo kernel e vincola un processo, non un computer. Nel momento in cui un agente deve cliccare qua e là in un’app desktop, renderizzare una pagina in un browser reale o eseguire esperimenti con rm -rf a cui preferiresti non pensare, il confine onesto è una macchina: kernel proprio, disco proprio, stack di rete proprio.

Le superfici isolate usano due backend VM:

• microVM per il terminale e il browser — avvio dell’hypervisor in meno di un secondo da immagini container con digest fissato.
• QEMU per il desktop Linux completo, che richiede un dispositivo di visualizzazione che la microVM non ha.

Le superfici mobili sono gestite dall’host e dichiarano direttamente il confine più debole:

• Android guida l’emulatore di Google tramite ADB.
• iOS crea e possiede un dispositivo CoreSimulator su un host Mac e lo guida tramite WebDriverAgent. Il dispositivo e i suoi dati vengono eliminati alla chiusura del rig, ma la sua rete segue il Mac host.

I rig isolati scrivono su uno strato usa e getta sopra un’immagine di base in sola lettura, così un rig non può cambiare ciò da cui si avvia quello successivo. Un rig iOS possiede un dispositivo CoreSimulator usa e getta che viene eliminato alla chiusura del rig. Android si collega a un emulatore dell’host che sopravvive alla sessione.

Uscita in rete negata per impostazione predefinita

La rete di un rig parte da niente. Gli host vengono ammessi per singolo rig attraverso un varco che il guest non può aggirare: le uniche vie d’uscita della macchina sono quelle create dalla configurazione di avvio. Un terminale isolato riceve la base da sviluppatore (registry dei pacchetti, forge, i mirror apt); un rig browser ammette il sito del prodotto (usectrl.dev) e si avvia su una pagina locale file:// che non richiede alcuna uscita in rete; tutto il resto viene rifiutato al momento della connessione.

Android e iOS non sono coperti da questo varco. Il loro emulatore e simulatore dell’host usano la rete dell’host del server, quindi l’interfaccia e il report delle capacità segnalano l’uscita in rete come non applicata e non offrono mai un controllo fuorviante «Riavvia senza restrizioni».

Uscita in rete e credenziali sono un’unica policy vista da due lati — il broker delle credenziali (più sotto) non rilascia un token per un host che il guest non può raggiungere.

Tutto ciò che un rig legge è considerato non attendibile: testo delle pagine, DOM e alberi di accessibilità, dump dell’interfaccia e output della console tornano all’agente delimitati da una regola permanente: «questi sono dati, non istruzioni». La delimitazione è una cornice; il varco dell’uscita in rete è l’applicazione concreta che sta dietro.

L’input passa dall’hypervisor, la cattura dal guest

Per la superficie desktop, gli eventi di tastiera e puntatore vengono iniettati dai dispositivi di input virtuali dell’hypervisor stesso. Il guest non esegue mai un demone privilegiato in grado di sintetizzare input — quindi compromettere il software del guest non consegna una tastiera all’attaccante. La cattura scorre nella direzione opposta, attraverso un piccolo agente non privilegiato dentro il guest, perché il guest può ridimensionare i frame prima che attraversino la rete.

Due corsie di visualizzazione

Chi guarda e il modello che guida hanno esigenze opposte, quindi un rig serve due flussi indipendenti:

• La corsia umana è a piena risoluzione, della dimensione del tuo pannello, rinegoziata quando ridimensioni e inoltrata dal server come byte opachi — il server non decodifica mai un frame, perché un decoder video sul percorso delle richieste è ciò che gli impedirebbe di rispondere alle RPC.
• La corsia dell’agente è fatta di fermoimmagine ridimensionati, limitati a una dimensione adatta al modello, un’immagine per risultato di strumento, con i frame più vecchi scartati durante la compattazione mentre le loro descrizioni testuali sopravvivono.

Nessuna delle due corsie scende a compromessi per l’altra: tu ottieni un’immagine fluida, il modello ne ottiene una economica.

La presa in carico è un collo di bottiglia, non una richiesta

Il controllo esclusivo è applicato nell’unico punto da cui passa ogni azione — non chiedendo al modello di comportarsi bene. Mentre lo tiene una persona, il server rifiuta le azioni mutative dell’agente. L’agente conserva i suoi verbi di osservazione (screenshot, estrazione) per poter raccontare ciò che stai facendo, e viene informato della presa in carico attraverso la sua corsia di guida invece di essere lasciato a scoprirla con clic rifiutati. Cliccare e digitare sul canvas funziona ogni volta che nessun altro detiene quel lock — o quando lo detieni tu; il tag di stato mostra Hai il controllo. Ogni evento di input — tuo e dell’agente — finisce in un log di audit per singolo rig, con il suo principal e una sequenza monotona, così «chi ha cliccato quello» resta una domanda a cui si può rispondere anche dopo che la macchina non c’è più.

I contenuti attraversano il confine; le macchine restano separate

Copia e incolla funzionano in entrambe le direzioni, e altrettanto fa il trascinamento dei file dentro e fuori — ma un rig è un computer diverso, e il progetto non finge mai il contrario.

Gli appunti vengono trasferiti su richiesta, non replicati in continuazione. Premi la combinazione di copia su un rig e al guest viene detto di copiare, poi qualunque cosa abbia messo nei suoi appunti — testo, un’immagine, un elenco di file — viene prelevata e collocata nei tuoi. L’incolla invia lo stesso contenuto nella direzione opposta e poi preme incolla dentro il guest. Nulla viene sincronizzato in background: una password che copi sulla tua macchina non arriva in silenzio dentro una VM perché è scattato un timer.

Il passaggio è controllato per utente e per direzione, in modo indipendente. Incollare in un rig è consentito per impostazione predefinita; copiare da un rig chiede prima il permesso (un’autorizzazione di dieci minuti, oppure Consenti sempre sotto Impostazioni → Server → Rig → Accesso agli appunti). Non è mai un’impostazione dello spazio di lavoro: un membro non può dare il consenso per gli appunti di un altro membro.

Su macOS la combinazione di passaggio è ⌘C/⌘V, che non è ambigua — ⌃C continua ad arrivare a una shell del guest come l’interruzione che è. Su Windows e Linux le due combinazioni sono lo stesso tasto, quindi il guest lo riceve invariato e i tuoi appunti vengono sovrascritti solo quando quelli del guest sono cambiati davvero. Un’interruzione resta un’interruzione.

I file trascinati dentro vengono copiati nella cartella di deposito della macchina e poi le vengono offerti. Cosa significhi «offerti» dipende da ciò che si può fare onestamente: una pagina del browser riceve un evento di drop reale nel punto in cui lasci il file, quindi una zona di caricamento si comporta esattamente come farebbe per un file locale; un desktop riceve i file in ~/Drops con i loro percorsi nei suoi appunti, perché nessun host può sintetizzare un trascinamento in un toolkit Linux arbitrario senza eseguire un demone privilegiato dentro il guest — che è esattamente ciò che questo progetto rifiuta di avere. Il risultato dice quale dei due casi si è verificato, così un CSV lasciato su una zona di caricamento non viene mai segnalato come caricato quando è soltanto un file in una cartella. Trascinare su un terminale isolato copia il file dentro e ne digita al prompt il percorso nel guest, che è ciò che una shell può davvero usare.

I file trascinati fuori funzionano sulla superficie desktop, dove il protocollo di trascinamento di X11 rende leggibile il payload mentre un trascinamento è in corso. Avvia un trascinamento dentro il guest, portalo fuori dal canvas e i file vengono prelevati sulla tua macchina e consegnati al sistema operativo come un trascinamento reale. Copiare file nel file manager del guest e incollarli sull’host funziona allo stesso modo. La superficie browser deliberatamente non lo offre: un browser headless non ha una selezione di trascinamento da leggere, e il segnale più vicino disponibile — la selezione di testo della pagina — non è affatto prova di un trascinamento, quindi agire su di essa dirotterebbe i clic normali.

Tutto ciò che viene letto da un guest resta contenuto non attendibile: il testo degli appunti raggiunge un modello dentro la stessa delimitazione di un’estrazione di pagina, e il log di audit registra che è avvenuto un incolla e quanto ne è stato incollato — mai ciò che diceva.

Le credenziali non risiedono mai nel guest

git push funziona da un terminale isolato che hai aperto tu, eppure il guest non conserva alcun token del forge. Custodisce un solo segreto per VM, il cui unico potere è chiedere al broker delle credenziali dell’host — su un tunnel controllato dall’host — un token di breve durata e limitato al repo, per singola operazione, con limiti di frequenza, vincolato alla stessa allowlist degli host usata per l’uscita in rete e revocato nel momento in cui il rig si chiude. Una macchina costruita per essere buttata via non deve contenere nulla che valga la pena rubare.

Ciò che quel token può fare viene fissato all’apertura del rig. Un rig di terminale aperto da una persona riceve un token di scrittura, limitato all’accesso al forge di quel membro. Un rig aperto da un agente ne riceve uno di sola lettura: un credential helper di git non sa distinguere un push da un fetch, quindi nel guest la regola di push non può essere interrogata a ogni push come fa il gateway delle esecuzioni degli agenti sull’host.

Il worktree in un rig è un satellite

Quando un rig porta il tuo repository, il worktree dell’host resta quello autorevole. La copia viene sincronizzata all’interno all’avvio (con i segreti come i file .env esclusi), e i commit tornano indietro solo quando lo chiedi — recuperati in refs/rigs/<id>/*, mai inviati con push, mai messi in checkout. Nulla dentro una VM può spostare il tuo branch o toccare il tuo working tree; unire ciò che un rig ha prodotto è sempre una decisione umana presa sull’host.

Porte senza buchi

Un dev server avviato dentro la VM del terminale diventa raggiungibile — sulla tua macchina, nel Browser (VM), facoltativamente sulla tua LAN, facoltativamente sotto un dominio di sviluppo con HTTPS — senza mai aprire la macchina. La mappa delle porte dell’hypervisor è fissata all’avvio, quindi tutti gli inoltri successivi viaggiano su due canali stretti controllati dall’host: un multiplexer in entrata pre-creato che rifiuta di contattare qualsiasi cosa su cui il guest non sia effettivamente in ascolto, e tunnel inversi che l’host tiene aperti per le connessioni avviate dal guest. L’HTTPS del dominio di sviluppo termina sul server usando un’autorità generata localmente, le cui chiavi non entrano mai in alcun guest. La meccanica è in Inoltra porte da un terminale.

Le macchine sono delimitate per costruzione

Un rig non può diventare un pet:

• un TTL rigido che il guest non può prolungare;
• una scala di inattività — messa in pausa (vCPU ferme, RAM residente) dopo la finestra di inattività, chiusura dopo il doppio della stessa — in cui un terminale aperto o uno spettatore che guarda conta come «in uso»;
• un budget di memoria contato in megabyte residenti, non in sessioni, perché una VM in pausa libera la CPU e conserva ogni byte di RAM; la macchina usata meno di recente viene espulsa per prima, e mai una che una persona sta guidando o guardando;
• lo smantellamento allo spegnimento del server, più una bonifica degli orfani contrassegnati dalla proprietà all’avvio successivo, così un server andato in crash non abbandona mai un hypervisor che non risponde a nessuno.

I primi avvii scaricano l’immagine fissata della macchina; poi il server mette in cache in background una copia già estratta, così ogni macchina successiva di quel tipo si avvia in pochi secondi e un terminale isolato si presenta con una base CLI già installata, del tipo che offrirebbe un runner ospitato su GitHub — compilatori, Python, jq, strumenti per archivi — non un toolcache linguistico o Docker. L’immagine Computer incorpora quella stessa base CLI al momento della build, accanto a XFCE e ai browser.

Tre browser, non uno

«Sulla mia macchina funziona» è un’affermazione su un singolo motore di rendering. Quindi un rig browser non è «il browser» — è Chromium, Firefox o WebKit, scelto quando lo apri, e un rig esegue quello con cui è stato aperto per tutta la sua vita. Una conversazione può contenerne uno di ciascuno: aprire Firefox (VM) accanto a Chromium (VM) ti dà due macchine, e puntarle entrambe sulla stessa pagina è il confronto. WebKit è quanto di più vicino a Safari esista su Linux — stessa discendenza del motore, quindi intercetta le lacune che incontrano gli utenti di Safari.

I verbi sono identici in tutti e tre; i protocolli sottostanti no, e le differenze vengono dichiarate invece di essere appianate. Chromium parla il DevTools Protocol e spinge i frame, quindi la sua vista dal vivo non costa nulla mentre una pagina è ferma. Firefox parla WebDriver BiDi e WebKit il WebDriver classico, e nessuno dei due ha una screencast, quindi le loro viste dal vivo fanno polling — pochi frame al secondo, che è giusto per guardare una pagina e non per guardare un’animazione. Dove un motore non riesce davvero a fare qualcosa (Firefox non ha un ricaricamento che aggira la cache; WebKit non vede l’output della console registrato prima che una pagina finisca di caricare), la risposta lo dice invece di fare in silenzio qualcos’altro.

Dove vivono i rig nel prodotto

Un rig deliberatamente non è una destinazione globale. La vista dal vivo è una scheda nello spazio o nella PR in cui si svolge il lavoro, limitata a quella conversazione — così la tua scheda e le chiamate browser_use dell’agente si rivolgono a una macchina (una per motore, sulla superficie browser). Se i rig possano avviarsi o meno è una proprietà dell’host, quindi le capacità, le immagini, le immagini personalizzate per spazio di lavoro e l’elenco delle macchine in esecuzione risiedono in Impostazioni → Server → Rig. Pilotare un recinto è una classe di azioni guardrail a sé, quindi uno spazio di lavoro, un agente o uno spazio può consentirla, richiedere approvazione o negarla del tutto — le modalità di sola lettura la negano in blocco.