Stasjoner

Bare fakta. For modellen bak dem, les Stasjoner og isolerte miljøer; for å åpne en maskin, følg veiledningen.

Flater og backender

Flate	Styrer	Backend	Verdi	Isolert utgående trafikk
Terminal (exec)	Et skall over VM-ens exec-kanal	mikro-VM	smolvm	Ja
Nettleser	Hodeløs Chromium (CDP), Firefox (WebDriver BiDi) eller WebKit (W3C WebDriver)	mikro-VM	smolvm	Ja
Datamaskin	X11-skrivebord: inndata via hypervisoren, skjermfangst via gjesteagenten	QEMU	qemu-hvf (macOS), qemu-kvm (Linux), qemu-tcg (uakselerert reserve, velges aldri automatisk)	Ja
Android	Android via ADB	Googles emulator	android-emulator	Nei — emulatoren håndterer sitt eget nettverk
iOS	iOS-simulator via WebDriverAgent	CoreSimulator	ios-simulator	Nei — nettverket følger Mac-verten

Terminalen og computer_use-flaten deler flateverdien computer; terminalen kjennetegnes av exec-bildemarkøren sin og gjenbrukes aldri som et styrbart skrivebord (eller omvendt). Én samtale gjenbruker én terminalmaskin.

Nettlesermotorer

Motor	Verdi	Protokoll	Sanntidsvisning	Stillbilder
Chromium	chromium (standard)	Chrome DevTools Protocol	Screencast — nettleseren dytter bilder etter hvert som siden tegnes på nytt	JPEG
Firefox	firefox	WebDriver BiDi	Stillbilder med polling (BiDi har ingen screencast), begrenset til 6 fps	JPEG
WebKit	webkit	W3C WebDriver (klassisk)	Stillbilder med polling, transkodet av vertens ffmpeg	PNG

En stasjon kjører én motor hele levetiden. Én samtale kan ha én stasjon per motor, og det er det som gjør en side-ved-side-sammenligning mulig: å åpne «Firefox (VM)» ved siden av «Chromium (VM)» er to maskiner, og å lukke den ene lar den andre fortsette å kjøre.

Send engine til rig.open eller til browser_use-verktøyet. Et ukjent navn avvises i stedet for å falle tilbake til standard — å be om en nettleser og stille få en annen, svarer på et kompatibilitetsspørsmål med feil svar.

Motoravhengige begrensninger, oppgitt i stedet for omgått:

• Firefox har ingen omlasting som omgår cachen (den avviser BiDis ignoreCache kategorisk), så en hard omlasting er en vanlig omlasting.
• WebKit har heller ingen omlasting som omgår cachen, ingen konsollstrøm (utdata fanges ved å kroke console.* etter hver navigasjon, så alt som logges under lasting, går tapt — hvert konsolluttrekk sier det), og trenger ffmpeg på verten for sanntidsvisningen.
• Ingen av dem eksponerer et plattform-tilgjengelighetstre over protokollen sin, så extract (a11y) returnerer en DOM-avledet tilnærming, merket som nettopp det.
• Ingen av dem kan ta imot en ekte filslipp; et filinndatafelt kan likevel pekes mot stier inne i maskinen.

Maskinbilder

Flate	Bilde	Hentes
Terminal	ubuntu:24.04, festet med digest	Automatisk ved første oppstart, via maskinens eget slusede nettverk
Nettleser (Chromium, Firefox, WebKit)	debian:trixie-slim, festet med digest, pluss motorens egne pakker	Automatisk ved første oppstart, deretter bufret som en forvarmet pakke
Datamaskin	Et qcow2-skrivebordsbilde med Chromium, Firefox, WebKit og den samme CLI-basislinjen for GitHub-hostede runnere som terminalen varmer opp	Importer under Innstillinger → Server → Stasjoner (nedlastinger festet med sjekksum der de er publisert)
Android	Googles systembilder	Gjennom Android SDK
iOS	En Xcode-simulatorkjøretid pluss WebDriverAgent festet med sjekksum	Kjøretid gjennom Xcode; automatiseringsbro fra Innstillinger → Server → Stasjoner

Etter den første oppstarten av hver mikro-VM-type bufrer serveren en forhåndsutpakket kopi under datamappen og starter alle senere maskiner fra den — også forvarmede bilder med pakkene allerede installert. Terminalen varmer opp et CLI-verktøysett av samme slag som en GitHub-hostet runner (git, gcc, python3, jq, rsync, arkivverktøy og resten av apt-basislinjen; ikke Docker eller verktøycacher for språk). Datamaskin-qcow2-en baker inn de samme CLI-navnene ved bygging av bildet, ved siden av XFCE og de tre nettleserne. Hver nettleser varmer opp motoren sin. Alle tre motorene deler en Debian-base, men deler aldri en pakke: cachen er nøklet på bildet, motoren og en lydrevisjon (audio-v1-<engine>), fordi en maskin som er varmet opp for én motor — eller før PulseAudio og ffmpeg var en del av arbeidslasten — ikke har noen av de andre i seg. Terminalpakken er nøklet på en verktøysettrevisjon (tools-v1) av samme grunn: en pakke som er varmet opp før kompilatoren var en del av bildet, må ikke betjene en maskin som skal ha en.

Det finnes ikke noe ferdigbygd automatiseringsbilde som er verdt å bruke — Chromiums chromedp/headless-shell kompilerer bort både ALSA og PulseAudio, så den kan aldri gi lyd; den eneste vedlikeholdte Firefox-varianten er 33× størrelsen på Debian-basen og leveres fortsatt uten socat; det finnes ingen vedlikeholdt WebKit-variant i det hele tatt. Derfor installerer hver motor ved første start (chromium, firefox-esr eller webkit2gtk-driver) og når Debian-arkivene (deb.debian.org, security.debian.org, cloudfront.debian.net) mens den gjør det. Chromium er distribusjonsbinæren, startet som chromium --headless=new.

Egne bilder per arbeidsområde

Innstillingsnøkkel	Overstyrer
rigs.smolvm.execImage	Terminal (VM)-bildet
rigs.smolvm.browserImage	Nettleser (VM)-bildet for Chromium

Angis gjennom arbeidsområdets innstillingslager, som er forbeholdt administratorer (Innstillinger → Server → Stasjoner → Egne bilder (dette arbeidsområdet)). Verdien må være en registerreferanse — lokale stier, arkiver og flagglignende strenger avvises, både i feltet og igjen ved oppstart. En ugyldig lagret verdi ignoreres med et tydelig varsel, og standarden startes i stedet. Bildets eget register (pluss kjente blob-CDN-følgesvenner for Docker Hub, GHCR, Quay, GitLab og GCR) tillates gjennom slusen for utgående trafikk for hentingen.

Bildekontrakt for terminal — bash til stede; git, curl, socat forhåndsinstallert eller en Debian/Ubuntu apt-base (det isolerte miljøet installerer disse tre pluss et CLI-verktøysett av samme slag som en GitHub-hostet runner ved første start: kompilatorer, Python 3, jq, arkivverktøy, rsync. Verktøycacher for språk og Docker installeres ikke).

Bildekontrakt for nettleser — en Debian/Ubuntu apt-base (eller pakkene allerede installert) med bash og socat, pluss en chromium-binær som serveren starter selv som chromium --headless=new, med DevTools på gjestens loopback 9223, videreformidlet til gjesteporten 9222. PulseAudio og ffmpeg installeres ved første start for lydbanen. Ikke bygg FROM chromedp/headless-shell: oppstrøms headless.gn kompilerer bort både ALSA og PulseAudio, så den binæren kan ikke gi lyd. Overstyringen gjelder bare Chromium-stasjoner — arbeidslastkommandoen den starter, er Chromiums, og å gi den til Firefox eller WebKit ville starte en binær som ikke finnes. En Firefox- eller WebKit-stasjon ignorerer den med et tydelig varsel og starter sitt festede bilde.

Automatiseringsporter — hver nettlesermaskin videresender nøyaktig én vertsloopback-port til gjestens 9222. Bak den: Chromiums DevTools og Firefox’ fjernagent ligger på gjestens loopback 9223 med en socat-relé foran (begge binder loopback ubetinget); WebKits driver tar en --host og binder gjestens NIC selv. Firefox validerer i tillegg Host-headeren mot sin egen port, så klienten sender gjestesidens autoritet i stedet for den den koblet til.

Handlingsverb

Hver handling parses fullstendig: en feilformet nyttelast returnerer en melding som navngir feltet, aldri et unntak. Observasjonsverb (merket ○) forblir tillatt mens et menneske har kontrollen; mutative verb avvises.

computer_use

screenshot○, cursor_position○, mouse_move, left_click, right_click, middle_click, double_click, triple_click, left_mouse_down, left_mouse_up, left_click_drag, scroll, key, hold_key (0–60 s), type, wait○ (0–60 s), set_display, clipboard_read○, clipboard_write.

Koordinater er gjestepiksler i gjestens gjeldende modus; hvert skjermbilde oppgir skjermstørrelsen. Tastenkombinasjoner bruker X11-stavemåter (ctrl+s, alt+Tab, Return).

clipboard_read tar en selection: clipboard (det ctrl+C fyller, standarden), primary (X11 merk-for-å-kopiere) eller xdnd (en dra-operasjon underveis). Et tomt resultat er et normalt svar for alle tre. clipboard_write tar bare text — bilder og filer går på filbanen, fordi en handlings argumenter lagres i revisjonsloggen, og bildetekst har ingenting der å gjøre. Innholdet på utklippstavlen kommer tilbake inngjerdet som ikke-klarerte data.

browser_use

navigate (bare http/https), reload (hard valgfritt), stop_loading, click (velger eller koordinat), fill, type, key (DOM-tastnavn), scroll, mouse_move, drag, left_mouse_down, left_mouse_up, extract○ (a11y | dom | console), screenshot○ (full_page valgfritt), set_viewport (min. 320×240), history, wait_for○ (velger, 0,1–30 s), clipboard_read○, clipboard_write.

Uttrukket sideinnhold returneres inngjerdet som ikke-klarerte data.

Nettleseren har nøyaktig én utklippstavle, så clipboard_read tar ingen selection. Begge utklippstavleverbene trenger en sikker kontekst: en side servert over ren http:// har ingen utklippstavle-API i det hele tatt, og verbet sier det i stedet for å rapportere en tom utklippstavle — bruk type der, som setter inn ved innsettingspunktet uten å gå via en utklippstavle.

mobile_use

tap, swipe (50–5000 ms), type, key (aliasene back, home, recents, enter, delete, backspace, tab, escape, search, menu, volume_up, volume_down, power, eller en hvilken som helst KEYCODE_*), screenshot○, ui_dump○, install_apk (begrenset til stasjonens worktree og serverens datamappe), start_app, stop_app, clear_app_data, uninstall_app, open_url og shell. shell tar en argv-liste og kjører inne i Android, aldri gjennom et vertsskall; den dekker utviklerdiagnostikk som logcat, dumpsys og pm grant.

mobile_use har ingen utklippstavleverb. Siden Android 10 er det bare appen med fokus som kan lese utklippstavlen.

ios_use

tap, swipe (50–5000 ms), type, key (enter, backspace, tab, escape, piltaster eller ett skrivbart tegn; valgfrie command-, control-, option- og shift-modifikatorer), home, lock, unlock, screenshot○, ui_dump○, install_app (en .app-mappe for simulatoren, begrenset til stasjonens worktree eller serverens datamappe), start_app, stop_app, uninstall_app, open_url og spawn. spawn tar argv og kjører inne i simulatoren gjennom simctl; den påkaller aldri et vertsskall.

Koordinater er iOS-skjermpunkter, ikke skjermbildepiksler. Sanntidsstrømmen beholder simulators faste størrelse og setter den i letterbox i stedet for å endre størrelsen på enheten. Tekstoverføring via utklippstavlen fra vert til simulator og fra simulator til vert bruker samme tillatelsespolicy per bruker og per retning som andre stasjoner; filer og bilder godtas ikke av iOS-utklippstavlebanen.

Hver stasjon oppretter en eid CoreSimulator-enhet og en WebDriverAgent-økt. Å lukke den stopper WebDriverAgent, slår av og sletter den enheten og fjerner registeroppføringen dens. iOS-stasjoner kjører bare på en macOS-server med Xcode, en installert iOS-kjøretid og den festede automatiseringsbroen. De gir ingen garanti for lyd, mikrofon, filslipp, vertsskall eller isolert nettverk.

Administrasjonsverktøy

Verktøy	Beskrivelse
rig_list	List opp et arbeidsområdes stasjoner med flate, status, skjerm og kontrollør
rig_close	Ødelegg en stasjon og forkast disken dens

Livssyklus

Fase	Betydning
provisioning	Starter opp; statusdetaljen gjengir gjeldende steg ordrett
ready	Tilgjengelig og tar imot handlinger
parked	Inaktivitets-parkert: vCPU-er stoppet, RAM fortsatt resident; neste handling vekker den
closing	Slår seg av
closed	Borte; raden består for revisjonssporet
failed	Døde eller kom aldri opp; skilles ut så brukergrensesnittet kan tilby nytt forsøk

Lukkegrunn	Utløses når
requested	En person eller agent ba om det
idleTimeout	Inaktiv utover 2× inaktivitetsvinduet, eller støtt ut på grunn av minne
ttlExpired	Den harde levetiden løp ut
conversationEnded	Samtalen som eier den, ble avsluttet
workspaceGone	Arbeidsområdet ble slettet, eller medlemskapet ble mistet
serverShutdown	Serveren stanser
backendFailure	Hypervisoren under den døde

Standardverdier og tak

Verdi	Terminal	Nettleser	Datamaskin	Mobil
Minne	512 MB	2048 MB (Chromium); 2560 MB (Firefox, WebKit)	4096 MB	4096 MB
vCPU-er	2	2	4	4
Hard TTL	8 t	2 t	2 t	2 t
Inaktivitetsvindu	45 min	15 min	15 min	15 min
Oppstartsvisning	—	1280×800	1280×800	1080×1920

• Stillbilder på agentbanen er begrenset til 1280×800; menneskebanen forhandler seg opp til 2560×1600.
• Vertens budsjett for resident minne for alle stasjoner er som standard 12 GB, målt i residente megabyte (en parkert VM holder fortsatt på RAM-en sin). Utstøting skjer etter minst nylig brukt og tar aldri en maskin som noen styrer, ser på eller har en terminal åpen i.
• En åpen terminal eller seerbane holder stasjonen fast mot parkering og inaktivitetsrydding; den harde TTL-en gjelder fortsatt.

Porter og utviklingsdomener

Port	Hvor	Reservert for
7911	Gjesten i terminalen	Portmultiplekseren all videresending går over
9222, 9223	Gjesten i nettleseren	Automatiseringsreléet og endepunktet (WebKit binder 9222 direkte og bruker ingen relé)
80, 443	Gjestens loopback i nettleseren	HTTP/HTTPS-banene for utviklingsdomener

• Oppdagelse poller gjestens lyttende TCP-porter i terminalen omtrent hvert 4. sekund, på serversiden.
• Høyst 16 porter videresendes automatisk per stasjon; flere listes opp i loggen, men videresendes ikke.
• Videresendingen på vertssiden binder loopback og foretrekker gjestens eget portnummer; Del på lokalt nettverk legger til en LAN-port tildelt av operativsystemet.
• Utviklingsdomener må samsvare med name.test eller name.localhost (med små bokstaver, etikett på maks 63 tegn). Ett domene mapper til én port.
• HTTPS for utviklingsdomener bruker en serverlokal CA (EC P-256, under <dataDir>/rigs/tls/, nøkler 0600 og aldri i en gjest) med ett jokertegnssluttblad for *.test / *.localhost. Ingen openssl på verten betyr ingen HTTPS-bane; ren HTTP rutes fortsatt.

Standardverdier for utgående trafikk

Flate	Standard tillatelsesliste
Terminal	Sandkassens utviklerbasislinje (kodeverter, pakkeregistre, modellleverandører) + Ubuntus apt-speil + worktreets egen kodevert
Nettleser	usectrl.dev (produktsiden) — pluss Debian-arkivene ved hver motors første oppstart, mens den installerer pakkene sine. Hjemmesiden er et lokalt file://-dokument og trenger ingen utgående trafikk
Datamaskin	Tom — avvis alt — til en kaller gir tillatelse til verter
Mobil	Ikke håndhevet (emulatorstyrt nettverk)

Hver mikro-VM får i tillegg bildets registerverter, bare for hentingen. Legitimasjonsmeglerens sett av tillatte verter utledes fra den samme tillatelseslisten: det utstedes ikke noe token for en vert gjesten ikke kan nå.

Utklippstavle og filoverføring

Begge retninger av kopier/lim inn, og å dra filer inn og ut. Tilgjengelig for en person som styrer en stasjon; en agent får utklippstavlen gjennom verbene ovenfor og ingen filoverføring i det hele tatt (den har allerede et skall inne i det isolerte miljøet).

Kryssing av utklippstavlen skjer per bruker og per retning. Lim inn fra vert til stasjon er tillatt som standard; kopiering fra stasjon til vert spør først (en tildeling på ti minutter, eller alltid tillat under Innstillinger → Server → Stasjoner → Tilgang til utklippstavle). De to valgene er uavhengige og er aldri en innstilling for arbeidsområdet.

Bane	Rute	Fraktet
Utklippstavle	GET/POST /rig/clipboard/<rigId>	Tekst, én PNG/JPEG (≤16 MB) og gjestestiene til filene på utklippstavlen
Filer	POST /rig/files/<rigId>	Opptil 64 filer, ≤256 MB hver og ≤512 MB per slipp, med et valgfritt slippunkt i gjestepiksler
Filer	GET /rig/files/<rigId>?p=<base64url path>	Bytedataene til én fil, tilbake ut

• HTTP, ikke RPC. RPC-sokkelen lukker en tilkobling ved en innkommende ramme over 256 KB — en DoS-vakt som er riktig for JSON-kommandoer og dødelig for et innlimt skjermbilde. Bytedata går over samme slags rute som stasjonsrammer og møtelyd allerede bruker.
• Autentisering er det signerte målet rig-files:<workspaceId>/<rigId> pluss medlemskap i arbeidsområdet — et eget mål, så en URL utstedt for å se på en maskin ikke også kan skrive filer inn i den.
• Overtakelse gjelder. Å skrive til utklippstavlen og å slippe filer er muterende og avvises mens noen andre har kontrollen; å lese utklippstavlen og å lese en fil ut er observasjon og er det ikke.
• Hvor slipp lander: ~/Drops (skrivebord), ~/drops (terminal — ved siden av worktreet, aldri inne i det, så et slipp aldri dukker opp som en usporet endring), /tmp/cc-drops (nettleser). Serveren velger mappen; en kaller kan ikke navngi den. Eksisterende filer overskrives aldri — en navnekollisjon lander som 2-name.ext.
• Hva gjesten får beskjed om: en nettside får en ekte slipphendelse på det angitte punktet (Input.dispatchDragEvent); et skrivebord får filene pluss URI-ene deres på utklippstavlen, fordi ingen vert kan syntetisere en XDND-dra-operasjon inn i et vilkårlig verktøysett uten en privilegert daemon i gjesten. Svaret oppgir hvilken av de to som skjedde.
• Å dra ut fungerer bare på skrivebordet og leser gjestens XdndSelection mens en dra-operasjon pågår. En nyttelast som er identisk med det gjesten allerede holdt da trykket begynte, behandles som en foreldet markering fra en avsluttet dra-operasjon, ikke en ny — X har ikke noe «dra-operasjonen er over»-steg.
• Bildekrav: skrivebordsbildet må være protokoll 2 eller nyere (bygget etter at utklippstavlestøtten kom). Et eldre bilde svarer 404, og appen sier at det må bygges på nytt i stedet for å rapportere en ødelagt maskin.
• Revisjonsloggen registrerer formen, aldri innholdet: radene clipboard_read, clipboard_write, drop_files og read_file bærer antall, størrelser og stier. En utklippstavle er der legitimasjon lever i noen sekunder av gangen, og ingenting av det skrives ned.

Tillatelsesregler, hendelser, lagring

• Stasjonsverktøy erklærer handlingsklassen enclosureControl (pluss networkEgress og processSpawn på bruksverktøyene; mobile_use og ios_use erklærer også packageInstall). rig_close erklærer enclosureControl; rig_list erklærer ingen. Tillatt som standard; skrivebeskyttede moduser avviser det kategorisk; autonomidreiet per område kan nedgradere det til å spørre først.
• Domenehendelser: RigClosedEvent (med lukkegrunnen sin), RigControlChanged (overtakelse / tilbakelevering), RigReaped (inaktivitets-, TTL- eller minneutstøting, med den styrende agenten). Å åpne en stasjon er ikke en hendelse. Se domenehendelser.
• Lagring: rig_sessions og rig_action_log i hver arbeidsområdedatabase. Handlingsloggen registrerer hver inndatahendelse med sin aktør og en monoton sekvens per stasjon; tekst som skrives inn, maskeres til en lengde og en hash før den skrives.
• Datamappe: rigs/images/ (importerte qcow2-bilder), rigs/smolvm/ (kjøretidstilstand per stasjon), rigs/smolvm-packs/ (forhåndsutpakkede maskinpakker), rigs/tls/ (CA-en for utviklingsdomener), rigs/run/ (QEMU-overlay og seed-filer).
• Ruter: sanntidsvisningen er en fane i en område- eller PR-side; /settings/server/rigs er innstillingsskjermen for stasjoner.