Remote-Executors

Geben Sie einem Agenten einen echten Computer zum Arbeiten – unter Linux, macOS oder Windows.

Was ein Remote-Executor ist

Ein Agent in Nessie hat keinen eigenen Rechner. Er kann lesen, was in Nessie steht, mit Personen sprechen und verbundene Werkzeuge über das Netzwerk aufrufen – er kann aber keine Datei auf einem Laptop öffnen, keinen Befehl ausführen und keine Seite ansehen, die nur hinter einer fremden Anmeldung existiert. Mit einem Remote-Executor geben Sie einem Agenten einen Rechner, an dem er arbeiten kann.

Ein Executor ist ein kleiner Daemon, den Sie auf einem Rechner installieren, den Sie kontrollieren. Er koppelt sich nach außen mit Ihrer Nessie-Instanz, weist nach, welcher Rechner er ist – mit einem Schlüssel, der den Rechner nie verlässt – und bietet danach eine feste, benannte Menge an Operationen an, sonst nichts. Aufgaben kommen als einzelne signierte Befehle an; Ergebnisse gehen als begrenzte, strukturierte Quittungen zurück. Der Rechner nimmt nie eine eingehende Verbindung von Nessie an.

Es lohnt sich, genau zu wissen, was ein Executor nicht ist, denn die meisten Werkzeuge für den Fernzugriff sind eines dieser Dinge, und ein Executor ist bewusst keines davon. Es gibt kein SSH, keine allgemeine Remote-Shell, kein Anhängen an einen bereits geöffneten Terminal-Multiplexer, keine Standardeingabe aus der Cloud und keinen allgemeinen Proxy für das lokale Netzwerk. Er ist kein MCP-Server und keine Container- oder Cloud-Ausführungsumgebung – Nessie hat solche bereits, und sie sind etwas anderes. Ein Executor ist ein Endpunkt mit eigener Berechtigung und einer geschlossenen Liste von Operationen, und diese Liste ist die gesamte Schnittstelle.

Wem ein Executor gehört

Jeder Executor wird mit genau einem Geltungsbereich angelegt, der sich danach nicht mehr ändern lässt. Er bestimmt, wer den Executor aufrufen und wer ihn verwalten darf.

Ein privater Executor braucht immer mindestens einen aktiven menschlichen Administrator. Wer den letzten entfernt, scheitert direkt; würde eine Offboarding-Transaktion keinen mehr übrig lassen, nimmt der Executor keine neuen Aufgaben mehr an, arbeitet die vorhandenen ab und widerruft sich selbst. Ein Inhaber der Organisation hat einen Notfallzugang, der nur widerrufen kann: Damit beendet er einen Executor, den er sonst nicht verwaltet, ohne dessen private Liste, Sitzungen oder Inhalte zu sehen. Privater Zugriff wird nie stillschweigend an jemand anderen übertragen.

Was ein Agent damit tatsächlich tun kann

Das Vokabular der Operationen ist im Code festgelegt, nicht pro Installation konfigurierbar. Es teilt sich in zwei Gruppen, und diese Aufteilung bestimmt, was Sie installieren müssen: Manche Operationen bedient der Daemon aus seinem eigenen Arbeitsverzeichnis, ganz ohne virtuelle Maschine. Die übrigen brauchen eine Gast-VM pro Sitzung auf dem Rechner.

Die Operationen, die keine Gast-VM brauchen, bilden das Arbeitsbereich-Paket. Ein Host, der keine Gast-VM starten kann, ist kein kaputter Executor: Er koppelt ganz normal, meldet sein Sandbox-Backend als none und bietet nur das Arbeitsbereich-Paket an. In diesem Zustand landet eine Windows-Edition ohne Hyper-V oder ein Linux-Rechner, dessen Benutzer nicht auf /dev/kvm zugreifen darf. Die Oberfläche benennt das, statt undurchsichtig zu scheitern.

Browserarbeit startet ein Agent nie aus eigenem Antrieb. Die gewöhnliche Route zum Binden einzelner Operationen lehnt browser.open und browser.observe rundweg ab. Ein Browserlauf wird von einer Person aus einem Kanal gestartet, als ein Paket aus vier Operationen in einem neuen Lauf, und danach kann ihm keine weitere Bindung mehr hinzugefügt werden. Verwaltete Coding-Sitzungen funktionieren genauso.

Zwei weitere Gruppen existieren im Code und sind bewusst nicht verfügbar. Operationen zum Steuern eines Chrome-Tabs, in dem Sie bereits angemeldet sind, sind lokal vollständig implementiert und haben eine Native-Messaging-Erweiterung. Die Steuerungsebene bietet sie jedoch nicht an, bis der Server nachweisen kann, dass die auslösende Unterhaltung privat war, und festhalten kann, wer welche Daten offengelegt hat. Die Grundlage ist mit Absicht inaktiv, und die Erweiterung wird in keinem der beiden Installationsprogramme ausgeliefert. Außerdem sind mehrere Coding-Operationen – Anhängen, Prompt, Unterbrechen und Schließen – im Schema benannt, haben aber keine Implementierung, weshalb sie sich nicht gewähren lassen.

So funktioniert es

Die Verbindung ist immer ausgehend

Der Daemon baut ausgehende HTTPS- und WSS-Verbindungen zu Ihrer Nessie-API auf und zu nichts sonst. Nessie wählt nie einen Laptop an, speichert keine Adresse dafür und behandelt keinen Katalog-Endpunkt als Übertragungsweg zu einem Rechner. Deshalb funktioniert ein Executor aus dem Heimnetz, hinter NAT oder im Firmen-VPN – ohne Portweiterleitung und ohne eingehende Firewall-Regel. Und deshalb ist das Stoppen des Daemons eine vollständige, sofortige Trennung.

Der API-Ursprung muss HTTPS sein. Einzige Ausnahme ist eine Loopback-Adresse für Personen, die Nessie auf ihrem eigenen Rechner betreiben; sie wird über eine eigene Umgebungsvariable aktiviert. Kein gewöhnliches Flag macht einen Produktionsursprung zu einfachem HTTP.

Die Kopplung weist einen Rechner nach, und eine Person bestätigt ihn

Die Kopplung ist ein zweiseitiger Nachweis. Eine berechtigte Person legt den Executor mit seinem Geltungsbereich in Nessie an, und Nessie stellt eine Registrierung aus: eine zufällige 256-Bit-Challenge, von der Nessie nur einen SHA-256-Verifizierer speichert. Sie ist zehn Minuten gültig und nur einmal verwendbar.

Auf dem Rechner erzeugt der Daemon ein Ed25519-Schlüsselpaar, legt es im nur für den Eigentümer zugänglichen, vom Betriebssystem geschützten Speicher ab und schreibt die genau signierte Anfrage auf die Festplatte, bevor er einen Netzwerkaufruf macht. So kann eine verlorene Antwort mit demselben vorbereiteten Schlüssel wiederholt werden, statt dass sich der Rechner still ein zweites Mal koppelt. Danach sendet er die Registrierungs-ID, die Challenge, seinen öffentlichen Schlüssel und einen Signaturnachweis. Nessie speichert den öffentlichen Schlüssel und seinen Fingerabdruck. Den privaten Schlüssel speichert Nessie nie.

Nessie zeigt diesen Fingerabdruck dann einer Person, die ihn bestätigt. Bis zu dieser Bestätigung und einem anschließenden Besitznachweis bleibt der Executor offline. Eine Kopplung lässt sich nie aus Chat-Text oder einem Terminalprotokoll abschließen; sie erfordert eine bewusste menschliche Handlung in der Web- oder Desktop-Oberfläche.

Ein Rechner, der seinen Schlüssel verliert, kann seinen Executor-Eintrag nicht zurückholen. Er wird widerrufen und als neuer Executor erneut registriert. Eine Schlüsselrotation dagegen ist eine einzige Transaktion, die sowohl vom alten als auch vom neuen Schlüssel signiert wird.

Der Deskriptor ist die signierte Aussage des Rechners über sich selbst

Ein gekoppelter Daemon veröffentlicht einen Deskriptor: eine signierte, monoton erhöhte Aussage ausschließlich über strukturelle Fakten – welche Operationsschemata er unterstützt, seine Ressourcen- und Netzwerkgrenzen, seine Plattform und einen Digest seiner lokalen Richtlinie. Er enthält keine Host-Pfade und begründet in der Cloud keine Berechtigung.

Eine neue Revision wird bei Eingang nie sofort aktiviert. Sie wird als ausstehend gespeichert, und eine berechtigte Person muss sie sehen und bestätigen, bevor sie wirken kann, was verfügbar ist. Dadurch kann eine Aktualisierung der Fähigkeiten nicht stillschweigend neue Befugnisse gewähren: Eine neu angekündigte Operation beginnt verweigert.

Seien Sie klar darüber, was die Signatur beweist. Ein Deskriptor, der mit dem Schlüssel eines gekoppelten Executors signiert ist, belegt nur, dass dieser Schlüssel die Aussage gemacht hat. Er belegt nicht, dass der Rechner unversehrt ist, und die Oberfläche muss genau das sagen.

Zustellung: Kandidat, Bindung, Befehl, Quittung

Ein Agent wählt nie einen Executor aus. Bevor ein Lauf einen nutzen kann, löst Nessie die logische Operation in einen undurchsichtigen, kurzlebigen Verfügbarkeitskandidaten auf. Die Antwort enthält keine Executor-ID; die Datenbank speichert nur einen Digest des Handles zusammen mit der Person und dem Zweck, für den es aufgelöst wurde. Modelle und Clients erhalten ein Handle, keinen auswählbaren Rechner.

Die Verfügbarkeit wird von einem einzigen Resolver berechnet, den API, Worker, Oberfläche und Assistent gleichermaßen verwenden:

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

Das Verbrauchen des Kandidaten erzeugt unter einer Datenbanksperre eine Bindung. Dabei werden alle diese Schranken ein zweites Mal geprüft, und ein monotoner Fence-Zähler wird erhöht. Die Zustellung prüft sie noch einmal. Die Folge: Eine entzogene Berechtigung, eine verschärfte Richtlinie oder ein widerrufener Executor zwischen zwei Schritten beendet die Arbeit, statt erst nachträglich bemerkt zu werden – und ein Wiederholungsversuch kann nie auf einem anderen Rechner landen als dem, an den der Lauf gebunden war.

Der Befehl selbst läuft über die gewöhnliche Warteschlangen-Aufgabe und den Lebenszyklus von Werkzeugaufrufen in Nessie, nicht über eine eigene zweite Warteschlange. Der Daemon fragt über seinen authentifizierten Steuerkanal nach Arbeit ab; ihm wird nie etwas gesendet. Ein Befehl durchläuft vier Quittungen und keine weiteren:

leased → accepted → started → result-acknowledged

Jede Nachricht bindet die Befehls-ID, die Herkunft des Laufs, den Bindungs-Fence, die Fähigkeitsrevision, ein Ablaufdatum, einen Idempotenzschlüssel sowie Digests sowohl der Argumente als auch der Nutzlast. Der Daemon lehnt eine Abweichung, eine veraltete Richtlinie, eine Wiederholung oder ein zweites Ergebnis für einen bereits abgeschlossenen Befehl ab. Argumente und Endergebnisse werden im Ruhezustand mit AES-256-GCM verschlüsselt; die Datenbank speichert begrenzte Chiffrate und kanonische Digests, nicht den Inhalt.

Geht eine Bestätigung verloren, nimmt Nessie nicht an, dass der Befehl erfolgreich war. Der Befehl wird als unbekanntes Ergebnis erfasst, und der Lauf folgt dem üblichen Wiederherstellungspfad. Der Daemon, der jeden zugestellten Befehl lokal protokolliert, bevor er mit der Arbeit beginnt, wiederholt die Nebenwirkung nicht. Eine späte Quittung kann die Unklarheit trotzdem ehrlich auflösen.

Vertrauensgrenze

Einen Executor installieren und koppeln

Installieren Sie die Mac-CLI mit Homebrew, die Mac-Apps mit Homebrew Casks, die Linux-CLI über APT oder DNF oder den Windows-Executor über WinGet. Jedes gekoppelte Team hat eigene Berechtigungen, die auf dem Computer gespeichert sind. Nessie steuert den Zugriff innerhalb des Teams; lokale Ressourcen kann Nessie nicht ändern.

Die Anleitung zur Installation und Kopplung enthält genaue Befehle, den zweiseitigen Ablauf mit dem achtstelligen Code, die lokalen Einstellungen, den Start, Aktualisierungen und die Deinstallation.

Wie weit jede Plattform tatsächlich erprobt ist

Der Stand der drei Gast-Sandboxes unterscheidet sich, und der Unterschied ist wesentlich. macOS ist das Backend mit einem funktionierenden, getesteten Gastpfad. Das Firecracker-Backend unter Linux und das Hyper-V-Backend unter Windows sind implementiert und durch Tests auf Host-Seite abgedeckt – Startablauf, Festplattenabbilder, Steuer- und Transporte für ausgehenden Verkehr, das Entwurfsprotokoll. Doch in der kontinuierlichen Integration dieses Projekts ist noch kein Gast auf echter Hardware gestartet, weil dafür ein Rechner mit KVM oder Hyper-V nötig ist und die Aufträge, die das belegen würden, nie einen hatten. Das Arbeitsbereich-Paket, das keinen Gast braucht, ist auf Windows gegen eine echte Steuerschleife durchgängig erprobt. Behandeln Sie gastgestützte Operationen unter Linux und Windows als nicht erprobt, bis Sie sie auf eigener Hardware nachgewiesen haben. Der Kopplungsbildschirm in Nessie sagt dasselbe mit eigenen Worten.

Sicherheit und Eindämmung

Ein Wurzelverzeichnis für den Arbeitsbereich, und sein Pfad bleibt auf dem Rechner

Beim Koppeln wird genau ein kanonisches Wurzelverzeichnis des Arbeitsbereichs gewählt: ein einzelnes Verzeichnis, keine Ordnermenge und nie deren nächstgelegener gemeinsamer übergeordneter Ordner. Nessie erfährt nur den Basisnamen des Wurzelverzeichnisses, damit Personen die Grenze in der Oberfläche erkennen. Der vollständige Pfad bleibt im nur für den Eigentümer lesbaren Zustand des Rechners und wird nie hochgeladen. Das Wurzelverzeichnis lässt sich ändern, aber erst, nachdem alle lokalen Entwürfe und Sandboxen entfernt wurden; die Änderung erzeugt eine neue Deskriptor-Revision, die dieselbe menschliche Prüfung durchläuft wie jede andere Richtlinienänderung. Es kann nie stillschweigend auf ein übergeordnetes Verzeichnis erweitert werden.

Dateioperationen akzeptieren nur relative Pfade. Sie lehnen Traversierung und jede symbolische Verknüpfung in einem Pfadbestandteil ab, prüfen erneut, dass das konfigurierte Wurzelverzeichnis weiterhin ein gewöhnliches Verzeichnis ist, und liefern begrenzte, strukturierte Ergebnisse ohne Host-Pfad zurück.

Schreibvorgänge landen in einer Kopie, und nur eine Person übernimmt sie

Ein Agent schreibt nie in Ihre Dateien. file.write legt eine begrenzte Copy-on-Write-Struktur im eigenen Statusverzeichnis des Daemons an, die dem Lauf zugeordnet ist; spätere Lese- und Auflistungsvorgänge dieses Laufs sehen den Entwurf. Gastarbeit, einschließlich Coding-Sitzungen, nutzt denselben Copy-on-Write-Speicher.

Einen Entwurf auf den echten Arbeitsbereich anzuwenden ist eine einzige Operation – workspace.promote – und sie ist der einzige Schreibvorgang auf dem Host im System. Sie hat gar kein Schema für Modelle: Kein Agent, kein Assistent und kein vom Aufrufer angegebener Pfad kann einen Entwurf in einen Schreibvorgang auf dem Host verwandeln. Stattdessen öffnet eine Person Ihre geprüften Entwürfe, drückt Übernahme prüfen und bestätigt mit ihrem aktuellen Passwort. Der Server prüft dann den bestätigten Prüf-Digest, den Manifest-Digest, den Ursprungslauf, Benutzer und Agenten, die Autorisierungsrevision, die Operationsberechtigung und die aktive lokale Richtlinie, bevor er den Befehl erstellt. Auf dem Rechner erstellt der Daemon das Manifest selbst neu und lehnt einen Digest ab, der sich geändert hat – so kann eine Änderung nach der Prüfung nicht mit der Genehmigung der Prüfung durchrutschen.

Die Anwendung selbst ist deskriptorbasiert und wird protokolliert. Das native Hilfsprogramm erhält das Wurzelverzeichnis des Arbeitsbereichs und den Entwurf als bereits geöffnete Verzeichnisdeskriptoren, niemals als Pfade. Es prüft jede Komponente mit Operationen ohne Symlink-Folgung, lehnt symbolische und harte Verknüpfungen, Sonderdateien und Mount-Übergänge ab und führt ein Journal, das entweder die Übernahme des geprüften Manifests vollendet oder das Original wiederherstellt, bevor irgendetwas anderes läuft.

Der Gast hat kein Netzwerk, und ausgehender Verkehr wird erzwungen

Wenn eine Operation tatsächlich einen Gast braucht, ist das eine Linux-Mikro-VM pro Sitzung ohne Home-Verzeichnis des Hosts, ohne Docker-Socket, ohne SSH-Agent, ohne geerbte Umgebung und ohne Host-Mount außer der Arbeitsbereich-Freigabe. Die ausführbare Laufzeit ist schreibgeschützt eingebunden; der beschreibbare Arbeitsbereich-Mount verbietet Ausführung. So stammt alles Ausführbare aus der geprüften Laufzeit-Nutzlast und nicht aus etwas, das ein Agent geschrieben hat. Der Gast wechselt zu einer unprivilegierten Identität, bevor er einen Socket öffnet, und eine root-eigene Freigabe lässt den Start scheitern, statt eine privilegierte Last laufen zu lassen.

Am wichtigsten: Der Gast hat keine Netzwerkschnittstelle. Unter Linux konfiguriert der Startablauf bewusst keine, und es wird kein TAP-Gerät erzeugt; unter Windows wird der virtuelle Netzwerkadapter, den Hyper-V standardmäßig hinzufügt, während der Einrichtung entfernt. Die einzige Route des Gasts vom Rechner weg ist ein Loopback-Proxy in ihm, der über einen virtuellen Socket zu einer Brücke auf dem Host getunnelt wird. Diese übergibt die Bytes an das eigene Gateway des Daemons – ein Socket-Listener für den Eigentümer, ohne TCP-Listener und ohne allgemeinen Weiterleitungsmodus. Dort werden die Richtlinien für HTTP, CONNECT, WebSocket, Weiterleitungen, Ursprünge, Downloads und Uploads durchgesetzt, und zwar mit dem bestehenden gepinnten Fetch-Mechanismus von Nessie statt mit einer zweiten Umsetzung derselben Regeln. Es gibt keine NAT-Brücke und keinen direkten DNS-Resolver: Alternatives DNS, rohes TCP, QUIC und das Umgehen des Proxys sind alle verboten.

Die Liste erlaubter Ursprünge, die das Gateway durchsetzt, legt der Eigentümer des Rechners fest, und sie wird bewusst nie hochgeladen. Die Oberfläche benennt diese Lücke, statt so zu tun, als sei Nessie ein Editor für Ursprungsrichtlinien. Wenn Sie wissen wollen, was ein Browser-Executor erreichen darf, fragen Sie die Person, der der Rechner gehört.

Zugangsdaten

Kein Zugangsdaten-Speicher des Hosts wird je in einen Gast eingebunden. Weder der Schlüsselbund noch ~/.codex oder ~/.claude, kein globales CLI-Token und keine Umgebungsvariable mit einem API-Schlüssel. Die einzige unterstützte Anmeldung für eine verwaltete Coding-Sitzung ist eine nur für den Eigentümer lesbare Authentifizierungsdatei. Ihren Inhalt liest allein der vom Eigentümer kontrollierte initrd-Builder – nie Nessie, nie der Deskriptor, nie ein Protokoll oder ein Befehlsargument. Die Datei wird einmal in ein privates Home-Verzeichnis im Gast verschoben, das mit der VM zerstört wird. Dieser Gast kann genau einen Ursprung erreichen.

Der Browser-Executor ist noch strenger: Jede Sitzung erhält ein frisches, privates Browserprofil und lehnt ein vom Arbeitsbereich vorbereitetes Profil ab. Sie beginnt daher ohne Cookies, ohne Erweiterungen und ohne bestehende Anmeldung.

Rohe lokale Daten erreichen einen Modellanbieter nur innerhalb eines ausdrücklichen, begrenzten Laufs. Nessie speichert nur bereinigte Manifeste, Digests von Argumenten und Richtlinien, Ergebnis-Digests und strukturierten Status. Dateiinhalte, Terminalausgaben, das Browser-DOM, Zugangsdaten und Authentifizierungsfaktoren sind in Datenbankeinträgen, Audit-Einträgen, Protokollen, Echtzeit-Ereignissen und Fehlerberichten verboten.

Was ein Betreiber gewährt und wie er es wieder entzieht

Die Berechtigung, einen Executor zu nutzen, ist kein einzelner Schalter. Ein Agent darf eine Operation nur aufrufen, wenn er eine Berechtigung für genau diesen Executor und genau diese Operation hält, und die gewöhnliche logische Werkzeugrichtlinie es erlaubt, und der Geltungsbereich des Laufs passt, und die eigene lokale Richtlinie des Rechners es zulässt. Eine Operation auf einem Executor zu gewähren, erlaubt also nichts auf einem anderen. Eine Aktualisierung der Fähigkeiten kann ebenfalls nichts erweitern, weil neu hinzugekommene Operationen verweigert beginnen.

Agentenzugriff und Freigabe wirken beide sofort auf der Seite selbst, ohne Genehmigungsschritt, Passwortabfrage oder erneute Authentifizierung. Auf dem Tab Agents des Executors schaltet eine Verwaltung den Zugriff eines Agenten auf den Rechner direkt ein oder aus. Unter Freigabe geben sie einer Person Nutzen oder Admin, oder erweitern die Nutzung auf ein Projekt oder auf alle im aktuellen Team, auf dieselbe Weise. In Ihrer eigenen Assistenten-Unterhaltung – nur dort, nie in einem gemeinsamen Kanal, einem geplanten Auftrag oder dem Lauf eines anderen Agenten – kann der Assistent stattdessen eine Änderung des Agentenzugriffs oder der Zuweisung vorbereiten, die eine Bestätigungskarte in dieser Unterhaltung einstellt. Nichts ändert sich, bis Sie auf dieser Karte Zugriff erlauben drücken; Chat-Text gilt nie als Bestätigung.

Drei Änderungen verlangen weiterhin, dass Sie im Moment der Bestätigung Ihr aktuelles Passwort erneut eingeben: das Aktivieren einer Deskriptor-Revision; eine vom Assistenten vorbereitete Zuweisung, die einer Person statt einem Agenten den Rechner gibt; und eine dauerhafte Richtlinie, die Kolleginnen und Kollegen erlaubt, als Eigentümer Befehle auf dem Rechner zu starten – die Richtlinie für unbeaufsichtigte Ticketarbeit. Das Trennen oder Löschen eines Rechners verlangt bewusst keines davon, denn ein Not-Aus darf nie schwerer zu erreichen sein als das, was er stoppt. Die Übernahme eines geprüften Entwurfs verlangt es immer. Das Audit-Protokoll erfasst die handelnde Person und die Beteiligung des Assistenten getrennt.

Ein Executor durchläuft eine kleine, klar festgelegte Menge an Zuständen:

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

Das Menü Computer in der Kopfzeile ist der Ort, an dem eine Verwaltung jede Lebenszyklus-Änderung vorbereitet: anhalten, nach dem Anhalten wieder fortsetzen, trennen oder löschen. Ein Anhalten lässt den Executor online, doch er nimmt keine Befehle mehr an. Trennen widerruft seine Client-Zertifikate und alle offenen Kandidaten-Handles und lässt sich nicht rückgängig machen – ein getrennter Executor wird als neuer erneut gekoppelt. Löschen bewirkt dasselbe und entfernt den Executor zusätzlich aus der Liste. Anders als beim Trennen ist es unabhängig vom Zustand des Executors verfügbar, auch wenn die Kopplung noch aussteht oder er bereits getrennt ist, weil es der einzige Weg ist, ihn aus der Liste zu entfernen. Auslaufen – die bereits vorhandene Arbeit fertig abschließen, bevor keine weitere mehr angenommen wird – ist im Protokoll ein echter dritter Zustand, und die Oberfläche kann einen Computer darin anzeigen. Gestartet wird er hier aber nicht: Das geht nur über einen direkten Aufruf der API. Jede bestätigte Zugriffsänderung, Deskriptor-Prüfung und jeder Lebenszyklus-Übergang, einschließlich des Auslaufens, erhöht außerdem die Verbindungsepoche des Daemons. Dessen nächste Steuerabfrage – höchstens eine Sekunde später – schlägt dann fehl und stoppt jeden laufenden Gast, bevor er sich wieder verbinden kann. Ein Widerruf ist keine Anfrage, die der Rechner ignorieren darf.

Einen Executor betreiben

Prüfen, ob er einwandfrei läuft

Die Antwort von Nessie selbst ist die Erreichbarkeitsprüfung. Ein Daemon signiert einen Heartbeat, und ein Executor, dessen letzte authentifizierte Aktivität älter als sechzig Sekunden ist, wird dauerhaft als offline markiert, bevor er aufgelistet, ausgewählt oder beliefert werden kann. Ein Executor, der als online angezeigt wird, hat sich in der letzten Minute nachweislich gemeldet.

Auf dem Rechner gibt es keinen Health-Endpunkt – der Daemon hört aus Konstruktionsgründen auf gar keinem Port, der für Bediener sichtbar wäre. Unter macOS und Linux fragen Sie die CLI direkt ab:

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

Unter macOS meldet der Status den launchd-Agenten jedes Teams. Der systemctl-Befehl gilt nur unter Linux. Unter Windows ist das Tray-Symbol die schnelle Antwort; sein Menü nennt den Grund, und das Dienstprotokoll enthält die Einzelheiten. Auf beiden Plattformen zeigt der Reiter Übersicht des Executors in Nessie die genehmigten Profile, seine Datengrenze, wann er zuletzt gesehen wurde und alle ausstehenden lokalen Richtlinienvorschläge, die auf Prüfung warten.

Protokolle

Jede Ablehnung, auf die eine Person reagieren kann, landet dort: ein nicht signiertes oder manipuliertes Laufzeitpaket, ein Statusverzeichnis, das sich nicht absichern lässt, ein Executor, der beim Systemstart nicht gestartet ist. Niemals landen dort eine Kopplungs-Challenge, ein Schlüssel oder die Ausgabe eines Kindprozesses. Eine Protokollstufe, die man erhöhen könnte, gibt es nicht, weil es nichts Ausführlicheres gibt, das man einschalten könnte.

Die Mac-CLI schreibt das Dienstprotokoll jedes Teams nach ~/Library/Logs/NessieExecutor/<executorId>.log.

Aktualisierung

Aktualisieren Sie die CLI über Homebrew, APT oder DNF und starten Sie danach den Dienst jedes Teams neu, indem Sie disable und anschließend enable ausführen. WinGet aktualisiert den Windows-Executor. Direkte Installationsprogramme für Nessie Desktop bieten signierte Aktualisierungen innerhalb der App an; MSI- und Debian-Installationen nutzen ihren Paketmanager. Kopplungen und lokale Berechtigungen bleiben bei Aktualisierungen erhalten.

Beenden und Entfernen

Das Beenden ist ein geordneter Weg, den der Daemon selbst steuert, kein Abbruch. Er empfängt ein Beendigungssignal, stoppt jede Gast-Sitzung, gibt seine Lease frei und beendet sich. Unter Linux wartet die Unit fünfzehn Sekunden auf ein Zeitbudget von zehn Sekunden für den Abbau und eskaliert bewusst nie zu einem nicht abfangbaren Kill. Ein während des Abbaus getöteter Daemon ließe nämlich eine Mikro-VM und ein Arbeitsbereich-Overlay zurück, ohne Prozess, der sie aufräumen könnte. Ein hängendes Beenden ist deshalb in systemctl --user status sichtbar statt still, und das Eskalieren ist eine ausdrückliche menschliche Entscheidung.

So entfernen Sie das Linux-Paket:

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

Unter Windows beendet und entfernt msiexec /x den Dienst, seine Registry-Einträge und den Autostart-Eintrag des Tray-Symbols. Auf beiden Plattformen bleibt der gekoppelte Zustand bewusst erhalten – unter Linux ~/.local/state/nessie-executor/, unter Windows %ProgramData%\Nessie Executor. Eine Kopplung besteht aus einem Rechnerschlüssel und einer signierten Richtlinienrevision, und das Deinstallieren eines Programms ist keine Aufforderung, sie zu vernichten; nach einer Neuinstallation findet man sie dort, wo sie war. Löschen Sie das Verzeichnis von Hand, um eine Kopplung zu vergessen, und widerrufen Sie den Executor in Nessie, um ihn von der anderen Seite zu beenden.

Das Tray-Symbol unter Windows und die Desktop-Begleitanwendung bieten beide Kopplung auf diesem Computer vergessen als eigenständige Aktion an: Sie stoppt den lokalen Daemon, entfernt den Rechnerschlüssel und die Ordnerauswahl und löscht nach einer nativen Bestätigung die lokalen Entwurfskopien dauerhaft. Der serverseitige Executor und sein Audit-Verlauf bleiben dabei erhalten, damit ein Inhaber sie behalten oder widerrufen kann.

Häufige Fehler