Fjern-executors

Giv en agent en rigtig computer at arbejde på — på Linux, macOS eller Windows.

Hvad en fjern-executor er

En agent i Nessie har ingen computer. Den kan læse det, der står i Nessie, tale med folk og kalde forbundne værktøjer over netværket — men den kan ikke åbne en fil på en laptop, køre en kommando eller se en side, der kun findes bag nogens login. En fjern-executor er måden, du giver den en maskine at arbejde på.

En executor er en lille daemon, du installerer på en computer, du styrer. Den parrer sig udad med din Nessie-instans, beviser, hvilken maskine den er, med en nøgle, der aldrig forlader værten, og tilbyder derefter et fast, navngivet sæt handlinger — intet andet. Arbejde kommer som enkeltvise signerede kommandoer; resultater kommer tilbage som afgrænsede, strukturerede kvitteringer. Maskinen accepterer aldrig en indgående forbindelse fra Nessie.

Det er værd at være præcis om, hvad en executor ikke er, for de fleste fjernadgangsværktøjer er en af disse ting, og en executor er bevidst ingen af dem. Der er ingen SSH, ingen generel fjernshell, ingen tilslutning til en terminalmultiplexer, du allerede har åben, ingen standardinput fra skyen og ingen generel proxy til det lokale netværk. Den er ikke en MCP-server, og den er ikke en container eller et miljø til cloud-eksekvering — Nessie har allerede dem, og de er noget andet. En executor er et endepunkt, der selv bærer sine tilladelser, med en lukket liste af handlinger, og den liste er hele overfladen.

Hvem en executor tilhører

Hver executor oprettes med præcis ét omfang, og omfanget kan ikke ændres bagefter. Det afgør, hvem der må bruge executoren, og hvem der må administrere den.

En privat executor skal altid have mindst én aktiv menneskelig administrator. At fjerne den sidste direkte fejler. Hvis en offboarding-transaktion ville efterlade ingen, holder executoren op med at acceptere nyt arbejde, afslutter det, den har, og tilbagekalder sig selv. En organisationsejer har en nødadgangsvej, der kun kan tilbagekalde: den afslutter en executor, de ikke ellers administrerer, uden at vise dens private liste, sessioner eller indhold. Privat adgang overføres aldrig stille til en anden.

Hvad en agent faktisk kan gøre med den

Handlingsvokabularet er fast i koden og ikke konfigureret pr. installation. Det deler sig i to, og delingen afgør, hvad du skal installere: nogle handlinger betjenes af daemonen fra dens egen scratch-mappe uden nogen virtuel maskine, og resten kræver en gæst-VM pr. session på værten.

De handlinger, der ikke kræver en gæst, er arbejdsmappe-pakken. En vært, der ikke kan starte en gæst, er ikke en ødelagt executor: den parrer normalt, melder sin sandbox-backend som none og annoncerer kun arbejdsmappe-pakken og intet andet. Det er den tilstand, en Windows-udgave uden Hyper-V eller en Linux-maskine, hvis bruger ikke kan bruge /dev/kvm, ender i. Grænsefladen navngiver den i stedet for at fejle uklart.

Browserarbejde starter aldrig af sig selv på agentens eget initiativ. Den almindelige enkelt-handlingsbinding afviser browser.open og browser.observe uden undtagelse. En browserkørsel startes af en person fra en kanal, som ét bundt af fire handlinger på en ny kørsel, og der kan ikke tilføjes flere bindinger til den bagefter. Styrede kodningssessioner fungerer på samme måde.

To yderligere grupper findes i koden og er bevidst utilgængelige. Handlinger til at styre en Chrome-fane, du allerede er logget ind i, har en komplet lokal implementering og en native-messaging-udvidelse, men kontrolplanet nægter at annoncere dem, før serveren kan bevise, at den oprindelige samtale var privat, og registrere, hvem der videregav hvad. Fundamentet er bevidst inaktivt, og udvidelsen er ikke med i nogen af installationsprogrammerne. Og flere kodningshandlinger — attach, prompt, interrupt og close — er navngivet i skemaet, men har ingen implementering, så de kan ikke gives.

Sådan virker det

Forbindelsen er altid udgående

Daemonen opretter udgående HTTPS- og WSS-forbindelser til din Nessie-API og ingen andre steder. Nessie ringer aldrig til en laptop, har aldrig en adresse for en, og behandler aldrig et katalogendepunkt som en maskintransport. Derfor virker en executor hjemmefra, bag NAT, på et firmanetværk eller VPN, uden portvideresendelse og uden indgående firewallregel. Og derfor er det at stoppe daemonen en komplet og øjeblikkelig afbrydelse.

API-oprindelsen skal være HTTPS. Den eneste undtagelse er en loopback-adresse for folk, der kører Nessie på deres egen maskine, styret af en egen miljøvariabel. Ingen almindelig flag gør en produktionsoprindelse til ren HTTP.

Parring beviser en maskine, og en person bekræfter den

Parring er et tosidet bevis. En berettiget person opretter executoren i Nessie med dens omfang, og Nessie udsteder en tilmelding: en tilfældig 256-bit-udfordring, hvoraf Nessie kun gemmer en SHA-256-verifikator. Den er gyldig i 10 minutter og kan bruges én gang.

På maskinen genererer daemonen et Ed25519-nøglepar, gemmer det i ejerprivat, OS-beskyttet lager og skriver den præcise signerede anmodning til disk før den foretager noget netværkskald. Så kan et tabt svar forsøges igen med den samme forberedte nøgle i stedet for stille at parre to gange. Derefter sender den tilmeldings-id'et, udfordringen, sin offentlige nøgle og en bevis-signatur. Nessie gemmer den offentlige nøgle og dens fingeraftryk. Den gemmer aldrig den private nøgle.

Nessie viser derefter fingeraftrykket til en person, som bekræfter det. Indtil den bekræftelse og et efterfølgende bevis for besiddelse er executoren offline. Parring kan aldrig fuldføres fra chattekst eller en terminaltranskription: det kræver en bevidst menneskelig handling i web- eller desktop-grænsefladen.

En maskine, der mister sin nøgle, kan ikke genskabe sin executor-post. Den tilbagekaldes og tilmeldes igen som en ny executor. Nøglerotation er derimod én transaktion, signeret både af den gamle og den nye nøgle.

Descriptoren er maskinens signerede udsagn om sig selv

En parret daemon offentliggør en descriptor: et signeret, monotont revideret udsagn om rene strukturelle fakta — hvilke handlingsskemaer den understøtter, dens ressource- og netværksgrænser, dens platform og et digest af dens lokale politik. Den indeholder ingen værtsstier og skaber ingen autoritet i skyen.

En ny revision aktiveres aldrig ved ankomst. Den gemmes som afventende gennemgang, og en berettiget person skal se den og bekræfte den, før den kan påvirke, hvad der er tilgængeligt. Det er det, der forhindrer, at en opdatering af egenskaber stille giver ny magt: en nyannonceret handling starter afvist.

Vær klar over, hvad signaturen beviser. En descriptor signeret af en parret executornøgle beviser, at nøglen fremsatte udsagnet. Den beviser ikke, at værten er ikke-kompromitteret, og grænsefladen skal sige det.

Afsendelse: kandidat, binding, kommando, kvittering

En agent navngiver aldrig en executor. Før en kørsel kan bruge en, omsætter Nessie den logiske handling til en ugennemsigtig, kortlivet tilgængelighedskandidat. Svaret indeholder intet executor-id. Databasen gemmer kun et digest af håndtaget sammen med, hvem og hvad det blev løst for. Modeller og klienter modtager et håndtag, ikke en maskine, de kan vælge.

Tilgængelighed er én resolver, brugt ens af API'en, workeren, grænsefladen og assistenten:

available(operation, human, agent, immutableRunContext) =
  human may discover executor
  ∩ exact executor-agent-operation grant allows operation
  ∩ stable logical tool grant allows operation
  ∩ scope matches immutable run context
  ∩ executor is online and descriptor is approved
  ∩ local policy permits operation

Forbrug af kandidaten opretter en binding under et databaselås. Låsen tjekker alle disse betingelser igen og rykker en monoton fence frem. Afsendelse tjekker dem endnu en gang. Konsekvensen er, at en tilbagetrukket tilladelse, en indsnævret politik eller en tilbagekaldt executor mellem to trin stopper arbejdet i stedet for at blive bemærket bagefter. Og et nyt forsøg kan aldrig ende på en anden maskine end den, kørslen blev bundet til.

Selve kommandoen kører på Nessies almindelige kø-job og værktøjskald-livscyklus i stedet for en egen. Daemonen henter arbejde via sin godkendte kontrolkanal; der bliver aldrig skubbet til den. En kommando går gennem fire kvitteringer og ingen andre:

leased → accepted → started → result-acknowledged

Hver besked binder kommando-id, kørslens proveniens, bindingens fence, kapacitetsrevisionen, en udløbstid, en idempotensnøgle og digests af både argumenterne og payloaden. Daemonen afviser en uoverensstemmelse, en forældet politik, en gentagelse eller et andet resultat for en kommando, den allerede har afsluttet. Argumenter og endelige resultater krypteres med AES-256-GCM i hvile. Databasen gemmer afgrænset ciphertext og kanoniske digests, ikke indhold.

Hvis en kvittering går tabt, antager Nessie ikke succes. Kommandoen registreres som et ukendt resultat, og kørslen følger den normale genoprettelsesvej. Daemonen, som journalfører hver leveret kommando lokalt, før den begynder arbejdet, gentager ikke bivirkningen. En sen kvittering kan stadig løse tvetydigheden ærligt.

Tillidsgrænse

Installation og parring af en executor

Installer Mac-CLI'en med Homebrew, Mac-appene med Homebrew casks, Linux-CLI'en via APT eller DNF eller Windows-executoren via WinGet. Hvert parrede team har sine egne tilladelser, gemt på computeren. Nessie styrer adgang inden for teamet, men den kan ikke ændre lokale ressourcer.

Installations- og parringsvejledningen har præcise kommandoer, det tosidede otte-cifrede kodeflow, lokale indstillinger, opstart, opdateringer og afinstallation.

Hvor langt hver platform faktisk er bevist

Tilstanden for de tre gæst-sandkasser er forskellig, og forskellen er væsentlig. macOS er backenden med en fungerende, afprøvet gæstevej. Firecracker-backenden på Linux og Hyper-V-backenden på Windows er implementeret og dækket af tests på værtssiden — opstartssekvensen, diskbillederne, kontrol- og udgangstransporterne og kladdeprotokollen. Men ingen gæst er endnu startet på rigtig hardware i projektets kontinuerlige integration, fordi det kræver en maskine med KVM eller Hyper-V, og de jobs, der skulle bevise det, har aldrig haft en. Arbejdsmappe-pakken, som ikke kræver nogen gæst, er afprøvet fra ende til anden på Windows mod en rigtig kontrolloop. Behandl gæstebaserede handlinger på Linux og Windows som ubeviste, indtil du har bevist dem på din egen hardware. Parringsskærmen i Nessie siger det samme med sine egne ord.

Sikkerhed og indeslutning

Én arbejdsmappe-rod, og dens sti bliver på maskinen

Parring vælger præcis én kanonisk arbejdsmappe-rod: én mappe, ikke et sæt mapper og aldrig deres nærmeste fælles forælder. Nessie får at vide rodens basisnavn, så en person kan genkende grænsen i grænsefladen. Den fulde sti bliver i maskinens tilstand, som kun ejeren kan læse, og den uploades aldrig. Det er muligt at ændre roden, men først når alle lokale kladder og sandkasser er fjernet. Ændringen giver en ny descriptor-revision, der går gennem den samme menneskelige gennemgang som enhver anden politikændring. Den kan aldrig stille udvides til en forældermappe.

Filhandlinger accepterer kun relative stier. De afviser traversering og alle symbolske link-komponenter, kontrollerer igen, at den konfigurerede rod stadig er en almindelig mappe, og returnerer afgrænsede, strukturerede resultater uden værtssti.

Skrivninger går til en kopi, og kun en person kan anvende dem

En agent skriver aldrig til dine filer. file.write opretter et afgrænset copy-on-write-træ under daemonens egen tilstandsmappe, nøglet til kørslen. Senere læsninger og lister for den kørsel ser kladden. Arbejde i gæsten, herunder kodningssessioner, bruger den samme copy-on-write-scratch.

At anvende en kladde på den rigtige arbejdsmappe er en enkelt handling — workspace.promote — og det er den eneste skrivning til værten i systemet. Den har slet intet skema, der vender mod modellen. Ingen agent, ingen assistent og ingen sti leveret af kalderen kan gøre en kladde til en skrivning på værten. I stedet åbner en person Dine gennemgåede kladder, trykker Gennemgå anvendelse og bekræfter med sin nuværende adgangskode. Serveren kontrollerer så det bekræftede gennemgangsdigest, manifest-digestet, den oprindelige kørsel, bruger og agent, autorisationsrevisionen, handlingstilladelsen og den aktive lokale politik, før den opretter kommandoen. På maskinen genopbygger daemonen selv manifestet og afviser et digest, der har ændret sig. En redigering foretaget efter gennemgangen kan dermed ikke snige sig med på gennemgangens godkendelse.

Selve anvendelsen er descriptor-baseret og journalført. Den native hjælper modtager arbejdsmappens rod og kladden som allerede åbne mappe-deskriptorer, aldrig som stier. Den validerer hver komponent med operationer uden at følge links, afviser symbolske links, hårde links, specialfiler og mount-krydsninger og har en alt-eller-gendan-journal. Et nedbrud fuldfører derfor enten det validerede manifest eller gendanner originalen, før noget andet kører.

Gæsten har intet netværk, og udgående trafik tvinges

Når en handling har brug for en gæst, er det en Linux-mikro-VM pr. session uden hjemmemappe fra værten, ingen Docker-socket, ingen SSH-agent, intet nedarvet miljø og ingen værtsmontering ud over arbejdsmappe-delingen. Den kørbare runtime-montering er skrivebeskyttet. Den skrivbare arbejdsmappe-montering forbyder eksekvering, så alt, der kører, kommer fra den verificerede runtime-payload og ikke fra noget, en agent har skrevet. Gæsten skifter til en uprivilegeret identitet, før den åbner nogen socket, og en root-ejet deling får opstarten til at fejle i stedet for at efterlade en privilegeret arbejdsbyrde kørende.

Vigtigst er det, at gæsten ingen netværksgrænseflade har. På Linux konfigurerer opstartssekvensen bevidst aldrig en, og der oprettes ingen TAP-enhed. På Windows fjernes det virtuelle netværkskort, Hyper-V tilføjer som standard, under installationen. Gæstens eneste rute ud af maskinen er en loopback-proxy inde i den, tunneleret over en virtuel socket til en bro på værten. Broen giver bytes videre til daemonens egen gateway, en lytter på en owner-only lokal socket uden TCP-lytter og uden generel videresendelsestilstand. Det er her, HTTP-, CONNECT-, WebSocket-, redirect-, oprindelses-, download- og upload-politikken håndhæves, med Nessies eksisterende pinned-fetch-mekanisme i stedet for en ny implementering af de samme regler. Der er ingen NAT-bro og ingen direkte DNS-resolver. Alternativ DNS-trafik, rå TCP, QUIC og proxy-omgåelse er alt sammen nægtet.

Oprindelseslisten, som gatewayen håndhæver, konfigureres på maskinen af dens ejer og uploades bevidst aldrig. Grænsefladen siger det klart i stedet for at lade som om, Nessie er en editor for oprindelsespolitik. For at vide, hvad en browser-executor må nå, skal du spørge den person, der ejer maskinen.

Legitimationsoplysninger

Intet værts-legitimationslager monteres nogensinde i en gæst. Hverken nøglering, ~/.codex eller ~/.claude, ikke et globalt CLI-token og ikke en miljøvariabel med en API-nøgle. Det eneste understøttede login for en styret kodningssession er en ejerprivat godkendelsesfil. Dens indhold læses kun af den ejerkontrollerede initrd-bygger — aldrig af Nessie, aldrig af descriptoren, aldrig af en log eller en kommandoargument. Filen flyttes én gang til et privat hjem inde i gæsten, som destrueres sammen med VM'en. Den gæst kan nå præcis én oprindelse.

Browser-executoren er endnu strengere: hver session får en frisk, privat browserprofil og afviser en, arbejdsmappen har forberedt. Den starter derfor uden cookies, uden udvidelser og uden nogen nedarvet indlogget tilstand.

Rådata kan kun nå en modeludbyder inden for en eksplicit, afgrænset kørsel. Det Nessie gemmer, er redigerede manifester, digests af argumenter og politik, resultat-digests og struktureret status. Filindhold, terminaloutput, browser-DOM, legitimationsoplysninger og autentificeringsfaktorer er forbudt i databaseposter, revisionsposter, logs, realtidshændelser og fejlrapporter.

Hvad en operatør giver, og hvordan de tager det tilbage

Tilladelse til at bruge en executor er ikke én enkelt afbryder. En agent kan kun kalde en handling, når den har en tilladelse til den præcise executor og den præcise handling, og den almindelige logiske værktøjspolitik tillader det, og kørslens omfang matcher, og maskinens egen lokale politik tillader det. At give én executor en handling giver derfor ingen adgang på en anden. Og en opdatering af egenskaber kan ikke udvide noget, fordi nye handlinger ankommer nægtet.

Agentadgang og deling træder begge i kraft med det samme på selve siden, uden godkendelsesfortsættelse, adgangskodeprompt eller nyt login-trin. På executorens fane Agenter tænder eller slukker en administrator direkte en agents adgang til maskinen. Under Deling giver de en person Kan bruge eller Admin, eller udvider brugen til et projekt eller til alle i det aktuelle team, på samme måde. I din egen assistentsamtale — kun der, aldrig i en delt kanal, et planlagt job eller en anden agents kørsel — kan assistenten i stedet forberede en ændring af agentadgang eller tildeling. Den poster et bekræftelseskort i samtalen. Intet ændres, før du trykker Tillad adgang på det, og chattekst er aldrig en bekræftelse.

Tre ændringer kræver stadig, at du indtaster din nuværende adgangskode i det øjeblik, du bekræfter: aktivering af en descriptor-revision, en assistent-forberedt tildeling, der giver en person, ikke en agent, maskinen, og en stående politik, der lader kolleger starte kommandoer på den som dens ejer, den uovervågede ticket-arbejdspolitik. Frakobling eller sletning af en maskine beder bevidst om ingen af delene, da en nødstopskontakt aldrig må være sværere at nå end det, den stopper. Anvendelse af en gennemgået kladde kræver altid adgangskoden. Revisionssporet registrerer den handlende person og assistentens involvering hver for sig.

En executor bevæger sig gennem et lille, eksplicit sæt tilstande:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

Hovedmenuen Computer er, hvor en administrator forbereder hver livscyklusændring: sæt den på pause, genoptag den, når den er sat på pause, afbryd forbindelsen eller slet den. Pause efterlader en executor online, men stopper den i at acceptere kommandoer. Afbrydelse ugyldiggør dens klientcertifikater og alle udestående kandidathåndtag, og den kan ikke fortrydes — en afbrudt executor parres igen som en ny. Slet gør det samme og fjerner også executoren fra listen. I modsætning til afbrydelse tilbydes den uanset executorens tilstand, også afventende parring og allerede afbrudt, fordi det er den eneste måde, en executor forlader listen på. Tømning — at færdiggøre det arbejde, den allerede har, før den stopper med at tage mere — er en reel tredje tilstand i protokollen. Grænsefladen kan vise en computer i den, men intet her starter en. Kun et direkte kald til API'en gør det. Hver bekræftet adgangsændring, gennemgang af descriptor og livscyklusovergang, også en tømning, rykker desuden daemonens forbindelsesepoke frem. Dens næste kontrolforespørgsel — højst et sekund senere — fejler lukket og stopper alle kørende gæster, før den kan genoptage forbindelsen. Tilbagekaldelse er ikke en anmodning, som maskinen kan ignorere.

Drift af en executor

Kontrollér, at den er sund

Nessies eget svar er liveness. En daemon signerer et heartbeat, og en executor, hvis seneste autentificerede aktivitet er ældre end 60 sekunder, markeres varigt som offline, før den kan listes, vælges eller få arbejde sendt. En executor, der vises som online, har bevist sig selv inden for det seneste minut.

Der er intet sundhedsendepunkt på maskinen. Daemonen lytter slet ikke på en port, der er åben for operatøren, og det er bevidst. På macOS og Linux spørger du CLI'en direkte:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

På macOS rapporterer status hver teams launchd-agent. systemctl-kommandoen gælder kun Linux. På Windows er ikonet i systembakken det hurtige svar, dets menu nævner årsagen, og servicelogfilen indeholder detaljerne. På begge platforme viser executorens fane Oversigt i Nessie dens godkendte profiler, dens dataafgrænsning, hvornår den sidst blev set, og eventuelle afventende lokale politikforslag, der venter på gennemgang.

Logs

Hver afvisning, en person kan handle på, havner der: en usigneret eller manipuleret runtime, en tilstandsmappe, der ikke kan sikres, eller en executor, der ikke startede ved opstart. Det, der aldrig havner der, er en parringsudfordring, en nøgle eller et barneprocesses output. Der er ingen logniveau-indstilling at hæve, fordi der ikke er mere detaljeret logning at slå til.

Mac-CLI'en skriver hvert teams servicelog til ~/Library/Logs/NessieExecutor/<executorId>.log.

Opgradering

Opgrader CLI'en via Homebrew, APT eller DNF, og genstart derefter hvert teams service med disable efterfulgt af enable. WinGet opgraderer Windows-executoren. Direkte Nessie Desktop-installationsprogrammer tilbyder signerede opdateringer i appen. MSI- og Debian-installationer bruger deres pakkehåndtering. Parringer og lokale tilladelser overlever opgraderinger.

Stop og fjernelse

Et stop er en kontrolleret nedlukning, som daemonen selv styrer, ikke en tvungen afbrydelse. Den modtager et afslutningssignal, stopper alle gæstesessioner, frigiver sin lease og afslutter. På Linux venter enheden 15 sekunder på et nedlukningsbudget på 10 sekunder og eskalerer bevidst aldrig til en tvungen afbrydelse, som ikke kan fanges. Grunden er, at en daemon, der dræbes midt i nedlukningen, efterlader en mikro-VM og et arbejdsområde-overlay uden nogen proces tilbage til at rydde op. Et stop, der hænger, er derfor synlig i systemctl --user status i stedet for stille. Eskalering er en udtrykkelig menneskelig beslutning.

Sådan fjerner du Linux-pakken:

nessie-executor disable <executorId>   # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger                # only if your user manager should stop running at boot too

På Windows stopper og fjerner msiexec /x servicen, dens registreringsposter og opstartsposten for systembakken. På begge platforme efterlades den parrede tilstand bevidst — ~/.local/state/nessie-executor/ på Linux og %ProgramData%\Nessie Executor på Windows. En parring er en maskinnøgle og en signeret politikrevision, og afinstallation af et program er ikke en anmodning om at ødelægge dem. Geninstallation finder dem, hvor de var. Slet mappen manuelt for at glemme en parring, og tilbagekald executoren i Nessie for at afslutte den fra den anden side.

Windows-systembakken og desktop-companionen tilbyder begge Glem parringen på denne computer som en førsteklasses handling. Den stopper den lokale daemon, fjerner maskinnøglen og mappevalget og sletter de lokale kladdekopier permanent efter én native bekræftelse. Den server-side executor og dens revisionshistorik efterlades, så en ejer kan beholde eller tilbagekalde den.

Almindelige fejl