Externe executors

Geef een agent een echte computer om mee te werken: op Linux, macOS of Windows.

Wat een remote executor is

Een agent in Nessie heeft geen computer. Hij kan lezen wat er in Nessie staat, met mensen praten en verbonden tools over het netwerk aanroepen, maar hij kan geen bestand op een laptop openen, geen commando uitvoeren en geen pagina bekijken die alleen achter iemands login bestaat. Een remote executor is de manier om een agent een machine te geven om mee te werken.

Een executor is een kleine daemon die je installeert op een computer die je beheert. Hij koppelt zich naar buiten aan je Nessie-instantie, bewijst met een sleutel die de machine nooit verlaat welke machine hij is, en biedt daarna een vaste, benoemde set bewerkingen aan — niets meer. Werk komt binnen als afzonderlijke ondertekende commando’s; resultaten gaan terug als begrensde, gestructureerde ontvangstbevestigingen. De machine accepteert nooit een inkomende verbinding vanuit Nessie.

Het is goed om precies te zijn over wat een executor niet is, want de meeste tools voor toegang op afstand zijn een van deze dingen, en een executor is daar bewust geen van. Er is geen SSH, geen onbeperkte remote shell, geen koppeling aan een terminal-multiplexer die je al open hebt, geen standaardinvoer vanuit de cloud en geen algemene proxy voor het lokale netwerk. Het is geen MCP-server en ook geen container of cloud-uitvoeringsomgeving — Nessie heeft die al, en dat is iets anders. Een executor is een endpoint met eigen bevoegdheden en een gesloten lijst bewerkingen, en die lijst is het volledige oppervlak.

Van wie een executor is

Elke executor wordt met precies één scope aangemaakt, en die scope kan achteraf niet meer worden veranderd. Hij bepaalt wie de executor mag aanroepen en wie hem mag beheren.

Een privé-executor moet altijd minstens één actieve menselijke beheerder hebben. De laatste direct verwijderen lukt niet; als een offboarding-transactie er geen zou laten, stopt de executor met het aannemen van nieuw werk, maakt hij het werk dat hij al heeft af en trekt hij zichzelf in. Een organisatie-eigenaar heeft een noodtoegangsroute die alleen intrekt: die beëindigt een executor die hij niet zelf beheert, zonder de privé-ledenlijst, de sessies of de inhoud te tonen. Privétoegang wordt nooit stilzwijgend aan iemand anders overgedragen.

Wat een agent er echt mee kan doen

De set bewerkingen is vastgelegd in code en wordt niet per installatie ingesteld. Ze valt in twee delen uiteen, en dat bepaalt wat je moet installeren: sommige bewerkingen levert de daemon vanuit zijn eigen scratch-map zonder enige virtuele machine, de rest heeft een guest-VM per sessie op de host nodig.

De bewerkingen die geen guest nodig hebben vormen de workspace-bundel. Een host die geen guest kan starten is geen kapotte executor: hij koppelt gewoon, meldt zijn sandbox-backend als none en adverteert alleen de workspace-bundel, verder niets. Zo eindigt een Windows-editie zonder Hyper-V, of een Linux-machine waarvan de gebruiker geen gebruik kan maken van /dev/kvm, en de interface noemt dat in plaats van ergens obscuur te falen.

Browserwerk begint een agent nooit uit eigen beweging. De gewone route voor het binden van één bewerking weigert browser.open en browser.observe zonder meer; een browserrun wordt door een persoon vanuit een kanaal gestart, als één bundel van vier bewerkingen op een nieuwe run, en er kan daarna geen extra binding meer aan worden toegevoegd. Beheerde codeersessies werken op dezelfde manier.

Er bestaan nog twee groepen in de code die bewust niet beschikbaar zijn. Bewerkingen om een Chrome-tab te besturen waarin je al bent ingelogd hebben een volledige lokale implementatie en een native-messaging-extensie, maar het control plane adverteert ze niet zolang de server niet kan aantonen dat het oorspronkelijke gesprek privé was en niet kan vastleggen wie welke gegevens heeft gedeeld — de basis is bewust inert, en de extensie zit in geen van beide installers. En verschillende codeerbewerkingen — attach, prompt, interrupt en close — staan wel in het schema, maar hebben geen implementatie, dus ze kunnen niet worden toegekend.

Hoe het werkt

De verbinding gaat altijd naar buiten

De daemon maakt uitgaande HTTPS- en WSS-verbindingen naar je Nessie-API, en naar niets anders. Nessie belt nooit een laptop, heeft nooit een adres voor er een en behandelt geen enkel catalogus-endpoint als machinetransport. Daarom werkt een executor vanaf een thuisnetwerk, achter NAT, op een zakelijk VPN, zonder portforwarding en zonder inkomende firewallregel — en daarom is stoppen van de daemon een volledige en directe verbreking.

De API-oorsprong moet HTTPS zijn. De enige uitzondering is een loopbackadres voor mensen die Nessie op hun eigen machine draaien, via een eigen omgevingsvariabele; geen gewone vlag maakt een productie-oorsprong tot gewoon HTTP.

Koppelen bewijst een machine, en een persoon bevestigt hem

Koppelen is een bewijs van twee kanten. Een bevoegd persoon maakt de executor in Nessie aan met zijn scope, en Nessie geeft een registratie uit: een willekeurige uitdaging van 256 bits, waarvan Nessie alleen een SHA-256-verificatiewaarde opslaat. Die is tien minuten geldig en kan één keer worden gebruikt.

Op de machine genereert de daemon een Ed25519-sleutelpaar, slaat het op in alleen-eigenaar-opslag die door het besturingssysteem wordt beschermd, en schrijft het exacte ondertekende verzoek naar schijf voordat hij een netwerkoproep doet — zodat een verloren antwoord opnieuw kan worden geprobeerd met dezelfde voorbereide sleutel, in plaats van stilzwijgend twee keer te koppelen. Daarna stuurt hij het registratie-id, de uitdaging, zijn publieke sleutel en een handtekening als bewijs. Nessie slaat de publieke sleutel en de fingerprint op. De private sleutel slaat het nooit op.

Nessie toont die fingerprint vervolgens aan een persoon, die hem bevestigt. Tot die bevestiging en een daarop volgend bewijs van bezit blijft de executor offline. Koppelen kan nooit worden afgerond via chattekst of een terminaltranscript: het vraagt een bewuste handeling van een mens in de web- of desktopinterface.

Een machine die zijn sleutel kwijt is, kan zijn executor-record niet terugclaimen. Het wordt ingetrokken en opnieuw als nieuwe executor geregistreerd. Sleutelrotatie daarentegen is één transactie die met zowel de oude als de nieuwe sleutel wordt ondertekend.

De descriptor is de ondertekende claim van de machine over zichzelf

Een gekoppelde daemon publiceert een descriptor: een ondertekende, monotoon oplopende verklaring die alleen structurele feiten bevat — welke operatieschema’s hij ondersteunt, zijn resource- en netwerklimieten, zijn platform en een digest van zijn lokale beleid. Er staan geen hostpaden in, en hij creëert geen autoriteit in de cloud.

Een nieuwe revisie wordt nooit meteen actief. Ze wordt in afwachting van beoordeling opgeslagen, en een bevoegd persoon moet haar zien en bevestigen voordat ze invloed heeft op wat beschikbaar is. Zo voorkom je dat een vernieuwing van de mogelijkheden stilzwijgend nieuwe bevoegdheden toekent: een nieuw geadverteerde bewerking begint geweigerd.

Wees duidelijk over wat de handtekening bewijst. Een descriptor die door een gekoppelde executorsleutel is ondertekend, bewijst dat die sleutel de claim heeft gedaan. Hij bewijst niet dat de host onaangetast is, en de interface moet dat zeggen.

Dispatch: kandidaat, binding, commando, ontvangstbevestiging

Een agent kiest nooit zelf een executor. Voordat een run er een kan gebruiken, zet Nessie de logische bewerking om in een ondoorzichtige, kortlevende beschikbaarheidskandidaat. Het antwoord bevat geen executor-id; de database bewaart alleen een digest van de handle, samen met wie en waarvoor die is opgevraagd. Modellen en clients krijgen een handle, geen machine om uit te kiezen.

Beschikbaarheid is één resolver, en die wordt op dezelfde manier gebruikt door de API, de worker, de UI en de assistent:

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

Wie de kandidaat verbruikt maakt een binding aan onder een databasevergrendeling die elk van die controles opnieuw uitvoert en een monotoon fence-nummer verhoogt. Dispatch controleert ze nogmaals. Gevolg: een ingetrokken grant, een ingeperkt beleid of een ingetrokken executor tussen twee stappen stopt het werk, in plaats van dat het pas achteraf wordt opgemerkt — en een nieuwe poging kan nooit op een andere machine landen dan die waaraan de run gebonden was.

Het commando zelf rijdt mee op Nessies gewone wachtrij-job en tool-call-lifecycle, in plaats van op een eigen tweede exemplaar. De daemon pollt voor werk via zijn geauthenticeerde control-kanaal; er wordt nooit naar hem gepusht. Een commando doorloopt vier ontvangstbevestigingen en geen andere:

leased → accepted → started → result-acknowledged

Elk frame bindt het commando-id, de herkomst van de run, het binding-fence-nummer, de capability-revisie, een vervaldatum, een idempotentiesleutel en digests van zowel de argumenten als de payload. De daemon weigert een frame dat niet overeenkomt, een verouderd beleid, een replay of een tweede resultaat voor een commando dat hij al heeft afgerond. Argumenten en eindresultaten worden in rust versleuteld met AES-256-GCM; de database bewaart begrensde ciphertext en canonieke digests, geen inhoud.

Als een bevestiging verloren gaat, neemt Nessie niet aan dat het gelukt is. Het commando wordt geregistreerd als een onbekende uitkomst, en de run volgt het gewone herstelpad. De daemon, die elk afgeleverd commando lokaal journaliseert voordat hij begint, herhaalt het neveneffect niet. Een late ontvangstbevestiging kan de onduidelijkheid alsnog eerlijk oplossen.

Vertrouwensgrens

Een executor installeren en koppelen

Installeer de Mac-CLI met Homebrew, de Mac-apps met Homebrew-casks, de Linux-CLI via APT of DNF, of de Windows-executor via WinGet. Elk gekoppeld team heeft eigen rechten, opgeslagen op de computer. Nessie beheert de toegang binnen het team; het kan lokale bronnen niet wijzigen.

De installatie- en koppelgids bevat de exacte commando’s, de tweezijdige code van acht cijfers, lokale instellingen, opstarten, updates en verwijderen.

Hoe ver elk platform daadwerkelijk bewezen is

De stand van de drie guest-sandboxes verschilt, en dat verschil is van belang. macOS is de backend met een werkend, getest guest-pad. De Firecracker-backend op Linux en de Hyper-V-backend op Windows zijn geïmplementeerd en gedekt door host-side tests — de startvolgorde, de schijfimages, de control- en egress-transporten, het conceptprotocol — maar in de continue integratie van dit project is nog geen guest op echte hardware opgestart. Dat vraagt een machine met KVM of Hyper-V, en de jobs die dat zouden moeten bewijzen hebben er nooit een gehad. De workspace-bundel, die geen guest nodig heeft, is van begin tot eind getest op Windows tegen een echte control-loop. Behandel guest-gebaseerde bewerkingen op Linux en Windows als niet-bewezen tot je ze op je eigen hardware hebt getest. Het koppelscherm in Nessie zegt hetzelfde, in eigen woorden.

Beveiliging en insluiting

Eén workspace-root, en het pad ervan blijft op de machine

Bij het koppelen wordt precies één canonieke workspace-root gekozen: één map, geen set mappen, en nooit hun dichtstbijzijnde gemeenschappelijke bovenliggende map. Nessie krijgt de basenaam van de root te zien, zodat een persoon de grens in de interface kan herkennen. Het volledige pad blijft in de alleen-eigenaar-status van de machine en wordt nooit geüpload. De root wijzigen kan, maar pas nadat elk lokaal concept en elke sandbox is verwijderd, en het levert een nieuwe descriptor-revisie op die door dezelfde menselijke beoordeling gaat als elke andere beleidswijziging. De root kan nooit stilzwijgend naar een bovenliggende map worden verbreed.

Bestandsbewerkingen accepteren alleen relatieve paden. Ze weigeren traversal en elk symbolische-linkonderdeel, controleren opnieuw dat de geconfigureerde root nog een gewone map is, en geven begrensde gestructureerde resultaten terug zonder hostpad.

Schrijfacties gaan naar een kopie, en alleen een persoon voert ze door

Een agent schrijft nooit naar je bestanden. file.write maakt een begrensde copy-on-write-boom aan onder de eigen statusmap van de daemon, gekoppeld aan de run, en latere lees- en lijstbewerkingen voor die run zien het concept. Werk in de guest, inclusief codeersessies, gebruikt dezelfde copy-on-write-scratch.

Een concept op de echte workspace toepassen is één bewerking — workspace.promote — en het is de enige schrijfactie naar de host in het systeem. Die heeft helemaal geen schema voor modellen: geen agent, geen assistent en geen door de aanroeper opgegeven pad kan een concept in een schrijfactie naar de host veranderen. In plaats daarvan opent een persoon Je beoordeelde concepten, drukt op Doorvoering beoordelen en bevestigt met zijn huidige wachtwoord. De server controleert dan opnieuw de bevestigde beoordelingsdigest, de manifestdigest, de oorspronkelijke run, gebruiker en agent, de autorisatierevisie, de bewerkingsgrant en het actieve lokale beleid, voordat hij het commando aanmaakt. Op de machine bouwt de daemon het manifest zelf opnieuw op en weigert hij een digest dat is veranderd — zodat een bewerking die na de beoordeling is gedaan niet met de goedkeuring van die beoordeling mee naar binnen kan.

Het toepassen zelf is descriptor-gebaseerd en gejournaliseerd. De native helper krijgt de workspace-root en het concept als al geopende mapdescriptors, nooit als paden. Hij valideert elk onderdeel met no-follow-bewerkingen, weigert symbolische links, harde links, speciale bestanden en mount-overgangen, en houdt een alles-of-herstel-journaal bij. Zo rondt een crash het gevalideerde manifest af of herstelt het het origineel, voordat er iets anders draait.

De guest heeft geen netwerk, en egress wordt afgedwongen

Wanneer een bewerking wel een guest nodig heeft, is dat een Linux-micro-VM per sessie, zonder host-home, zonder Docker-socket, zonder SSH-agent, zonder geërfde omgeving en zonder hostmount behalve de workspace-share. De uitvoerbare runtime-mount is alleen-lezen; de schrijfbare workspace-mount verbiedt uitvoering, zodat alles wat draait afkomstig is uit de geverifieerde runtime-payload en niet uit iets dat een agent heeft geschreven. De guest valt terug naar een onbevoegde identiteit voordat hij een socket opent, en een share met root-eigendom laat de boot mislukken in plaats van een geprivilegieerde workload te laten draaien.

Het belangrijkste: de guest heeft geen netwerkinterface. Op Linux configureert de startvolgorde er bewust nooit een, en wordt geen TAP-apparaat aangemaakt. Op Windows wordt de virtuele netwerkadapter die Hyper-V standaard toevoegt tijdens de installatie verwijderd. De enige route van de guest naar buiten is een loopback-proxy erin, getunneld over een virtuele socket naar een bridge op de host. Die geeft de bytes door aan de eigen gateway van de daemon: een alleen-eigenaar lokale socket-listener zonder TCP-listener en zonder algemene forwarding-modus. Op die gateway worden HTTP-, CONNECT-, WebSocket-, redirect-, origin-, download- en upload-beleid afgedwongen, met Nessies bestaande pinned-fetch-mechanisme in plaats van een tweede implementatie van dezelfde regels. Er is geen NAT-bridge en geen directe DNS-resolver: alternatieve DNS, ruw TCP, QUIC en proxy-omzeiling worden allemaal geweigerd.

De lijst met origins die die gateway afdwingt, wordt op de machine ingesteld door de eigenaar, en wordt bewust nooit geüpload. De interface benoemt die afwezigheid, in plaats van te doen alsof Nessie een editor voor origin-beleid is. Wat een browserexecutor mag bereiken, vraag je daarom aan de persoon die de machine bezit.

Credentials

Er wordt nooit een credentialopslag van de host in een guest gekoppeld. Niet de sleutelhanger, niet ~/.codex of ~/.claude, niet een globaal CLI-token, niet een omgevingsvariabele met een API-sleutel. De enige ondersteunde login voor een beheerde codeersessie is een alleen-eigenaar authenticatiebestand. De inhoud daarvan wordt uitsluitend gelezen door de initrd-builder die de eigenaar beheert — nooit door Nessie, nooit door de descriptor, nooit door een log of een commando-argument — en wordt eenmaal verplaatst naar een privé-home binnen de guest, dat met de VM wordt vernietigd. Die guest kan precies één origin bereiken.

De browserexecutor is nog strenger: elke sessie krijgt een nieuw privé browserprofiel en weigert een profiel dat door de workspace is voorbereid. Zo begint hij zonder cookies, zonder extensies en zonder ingelogde staat uit de omgeving.

Ruwe lokale gegevens kunnen alleen binnen een expliciete, begrensde run bij een modelprovider terechtkomen. Wat Nessie bewaart zijn geredigeerde manifesten, digests van argumenten en beleid, digests van resultaten en gestructureerde status. Bestandsinhoud, terminaluitvoer, de browser-DOM, credentials en authenticatiefactoren zijn verboden in databaserecords, auditvermeldingen, logs, realtime-events en foutrapporten.

Wat een beheerder toekent en hoe hij dat weer intrekt

Toestemming om een executor te gebruiken is niet één schakelaar. Een agent kan een bewerking alleen aanroepen als hij een grant heeft voor die precieze executor en die precieze bewerking, én het gewone logische toolbeleid staat het toe, én de scope van de run past, én het lokale beleid van de machine staat het toe. Een bewerking op de ene executor toekennen geeft dus geen recht op een andere. En een vernieuwing van de mogelijkheden kan niets verruimen, omdat nieuwe bewerkingen geweigerd binnenkomen.

Toegang van agents en delen gaan beide meteen in op de pagina zelf, zonder goedkeuringsstap, wachtwoordprompt of nieuwe authenticatie. Op het tabblad Agents van de executor zet een beheerder de toegang van een agent tot de machine direct aan of uit. Op Delen geven ze een persoon Kan gebruiken of Admin, of breiden ze het gebruik uit naar een project of naar iedereen in het huidige team, op dezelfde manier. In je eigen assistentgesprek — alleen daar, nooit in een gedeeld kanaal, een geplande taak of de run van een andere agent — kan de assistent in plaats daarvan een wijziging van agenttoegang of toewijzing voorbereiden. Dat plaatst een bevestigingskaart in dat gesprek. Er verandert niets totdat je op die kaart op Toegang toestaan drukt, en chattekst telt nooit als bevestiging.

Drie wijzigingen vereisen nog steeds dat je op het moment van bevestigen je huidige wachtwoord opnieuw invoert: het activeren van een descriptor-revisie; een door de assistent voorbereide toewijzing die een persoon, in plaats van een agent, de machine geeft; en een permanent beleid dat collega’s toestaat commando’s op de machine te starten als eigenaar — het beleid voor onbeheerd ticketwerk. Het loskoppelen of verwijderen van een machine vraagt bewust geen van beide, omdat een noodstop nooit moeilijker bereikbaar mag zijn dan wat hij stopt. Het doorvoeren van een beoordeeld concept vraagt altijd om het wachtwoord. Het auditspoor registreert de handelende persoon en de betrokkenheid van de assistent afzonderlijk.

Een executor doorloopt een kleine, expliciete set toestanden:

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

Het menu Computer in de kop is waar een beheerder elke lifecycle-wijziging voorbereidt: pauzeren, hervatten zodra hij gepauzeerd is, ontkoppelen of verwijderen. Pauzeren laat een executor online, maar stopt hem met het aannemen van commando’s. Ontkoppelen maakt zijn clientcertificaten en elke openstaande kandidaat-handle ongeldig, en kan niet ongedaan worden gemaakt — een ontkoppelde executor wordt opnieuw als nieuwe executor gekoppeld. Verwijderen doet hetzelfde en haalt de executor ook van de lijst. Anders dan ontkoppelen wordt het aangeboden ongeacht de toestand van de executor, ook als het koppelen nog in behandeling is of hij al ontkoppeld is, omdat het de enige manier is waarop hij van de lijst verdwijnt. Leegtrekken — het afmaken van het werk dat hij al heeft voordat hij geen nieuw werk meer aanneemt — is in het protocol een echte derde toestand. De interface kan een computer daarin tonen, maar niets in dit document start die toestand; alleen een rechtstreekse API-aanroep doet dat. Elke bevestigde wijziging van toegang, elke descriptor-beoordeling en elke lifecycle-overgang, ook een leegtrekking, verhoogt bovendien de verbindingsepoch van de daemon. Zijn volgende control-poll, hooguit een seconde later, faalt dan, en elke live guest stopt voordat hij opnieuw kan verbinden. Intrekken is geen verzoek dat de machine mag negeren.

Een executor beheren

Controleren of hij gezond is

Nessies eigen antwoord is liveness. Een daemon ondertekent een heartbeat, en een executor waarvan de laatste geauthenticeerde activiteit ouder is dan zestig seconden, wordt duurzaam als offline gemarkeerd voordat hij kan worden getoond, geselecteerd of ernaartoe gedispatcht. Een executor die online staat, heeft zich de afgelopen minuut bewezen.

Er is geen health-endpoint op de machine — de daemon luistert bewust op geen enkele poort die bedoeld is voor de beheerder. Op macOS en Linux vraag je het de CLI rechtstreeks:

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

Op macOS meldt de status de launchd-agent van elk team. Het systemctl-commando is alleen voor Linux. Op Windows is het pictogram in het systeemvak het antwoord in één oogopslag, het menu noemt de reden en het servicelog bevat de details. Op beide platforms toont het tabblad Overzicht van de executor in Nessie zijn goedgekeurde profielen, zijn databegrenzing, wanneer hij voor het laatst is gezien, en eventuele lokale beleidsvoorstellen die op beoordeling wachten.

Logs

Elke weigering waar een persoon iets mee kan doen, komt daar terecht: een niet-ondertekende of gemanipuleerde runtime, een statusmap die niet veilig in te stellen is, of een executor die niet bij het opstarten van de machine is gestart. Een koppelingsuitdaging, een sleutel of de uitvoer van een kindproces komt er nooit terecht. Er is geen loglevel-instelling om hoger te zetten, omdat er niets uitgebreiders is om aan te zetten.

De Mac-CLI schrijft het servicelog van elk team naar ~/Library/Logs/NessieExecutor/<executorId>.log.

Bijwerken

Werk de CLI bij via Homebrew, APT of DNF, en start daarna de service van elk team opnieuw met disable, gevolgd door enable. WinGet werkt de Windows-executor bij. Directe Nessie Desktop-installers bieden ondertekende updates in de app aan; MSI- en Debian-installaties gebruiken hun pakketbeheerder. Koppelingen en lokale rechten blijven behouden bij updates.

Stoppen en verwijderen

Stoppen is een nette route die de daemon zelf beheert, geen kill. Hij ontvangt een beëindigingssignaal, stopt elke guest-sessie, geeft zijn lease vrij en stopt. Op Linux wacht de unit vijftien seconden op een opruimbudget van tien seconden, en escaleert hij bewust nooit naar een niet-opvangbare kill. Een daemon die midden in het opruimen wordt gekilld, laat een micro-VM en een workspace-overlay achter zonder proces dat ze nog kan opruimen. Een stop die blijft hangen is daarom zichtbaar in systemctl --user status, in plaats van stil. Escaleren is een expliciete menselijke beslissing.

Om het Linux-pakket te verwijderen:

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

Op Windows stopt en verwijdert msiexec /x de service, de registervermeldingen en het opstartitem van het systeemvak. Op beide platforms blijft de gekoppelde status bewust achter — ~/.local/state/nessie-executor/ op Linux en %ProgramData%\Nessie Executor op Windows. Een koppeling is een machinesleutel en een ondertekende beleidsrevisie. Een programma verwijderen is geen verzoek om die te vernietigen; na herinstallatie staan ze gewoon op hun plek. Verwijder de map handmatig om een koppeling te vergeten, en trek de executor in Nessie in om hem van de andere kant te beëindigen.

Het systeemvak van Windows en de desktopcompanion bieden beide Koppeling op deze computer vergeten aan als volwaardige actie. Die stopt de lokale daemon, verwijdert de machinesleutel en de mapselectie, en verwijdert na één bevestiging door het systeem de lokale conceptkopieën definitief. De executor op de server en zijn auditgeschiedenis blijven staan, zodat een eigenaar ze kan behouden of intrekken.

Veelvoorkomende storingen