Exécuteurs à distance

Donnez à un agent un vrai ordinateur sur lequel travailler, sous Linux, macOS ou Windows.

Ce qu’est un exécuteur à distance

Un agent dans Nessie n’a pas d’ordinateur. Il peut lire ce qui se trouve dans Nessie, parler avec les personnes et appeler des outils connectés par le réseau, mais il ne peut ni ouvrir un fichier sur un ordinateur portable, ni exécuter une commande, ni consulter une page qui n’existe que derrière la connexion de quelqu’un. Un exécuteur à distance est le moyen de lui donner une machine sur laquelle travailler.

Un exécuteur est un petit démon que vous installez sur un ordinateur que vous contrôlez. Il s’appaire vers l’extérieur avec votre instance Nessie, prouve quelle machine il est grâce à une clé qui ne quitte jamais l’hôte, puis propose un ensemble fixe d’opérations nommées, et rien d’autre. Le travail arrive sous forme de commandes signées individuelles ; les résultats reviennent sous forme de comptes rendus structurés et bornés. La machine n’accepte jamais de connexion entrante venant de Nessie.

Il est utile de préciser ce qu’un exécuteur n’est pas, car la plupart des outils d’accès à distance relèvent de l’une de ces catégories, et un exécuteur est délibérément aucune d’elles. Il n’y a ni SSH, ni shell distant permanent, ni rattachement à un multiplexeur de terminal déjà ouvert, ni entrée standard côté cloud, ni proxy général du réseau local. Ce n’est pas un serveur MCP, et ce n’est pas un conteneur ni un environnement d’exécution dans le cloud : Nessie dispose déjà de ceux-ci, et ce sont des choses différentes. Un exécuteur est un point de terminaison porteur de capacités, avec une liste fermée d’opérations, et cette liste constitue à elle seule toute sa surface.

À qui appartient un exécuteur

Chaque exécuteur est créé avec un seul périmètre, qui ne peut plus être modifié ensuite. Ce périmètre détermine qui peut l’invoquer et qui peut l’administrer.

Un exécuteur privé doit toujours avoir au moins un administrateur humain actif. Supprimer directement le dernier échoue ; si une transaction de départ ne laisserait aucun administrateur, l’exécuteur cesse d’accepter de nouveaux travaux, termine ceux qu’il a déjà et se révoque lui-même. Un propriétaire d’organisation dispose d’une voie d’accès d’urgence, limitée à la révocation, qui met fin à un exécuteur qu’il ne gère pas par ailleurs, sans lui montrer sa liste privée, ses sessions ni son contenu. L’accès privé n’est jamais transféré en silence à quelqu’un d’autre.

Ce qu’un agent peut réellement faire avec lui

Le vocabulaire des opérations est fixé dans le code, et non configuré par déploiement. Il se divise en deux, et cette division détermine ce qu’il faut installer : certaines opérations, le démon les sert depuis son propre répertoire de travail, sans aucune machine virtuelle ; les autres ont besoin d’une machine virtuelle invitée par session, sur l’hôte.

Les opérations qui n’ont pas besoin d’invitée forment l’ensemble de l’espace de travail. Un hôte incapable de démarrer une invitée n’est pas un exécuteur défaillant : il s’appaire normalement, signale son moteur de bac à sable comme none, et n’annonce que l’ensemble de l’espace de travail, rien d’autre. C’est l’état dans lequel se retrouve une édition Windows sans Hyper-V, ou une machine Linux dont l’utilisateur ne peut pas utiliser /dev/kvm ; l’interface le nomme au lieu d’échouer de façon obscure.

Un travail sur le navigateur n’est jamais lancé par un agent de sa propre initiative. La route ordinaire de liaison d’une opération unique refuse browser.open et browser.observe sans condition ; une exécution de navigateur est lancée par une personne depuis un canal, sous forme d’un ensemble de quatre opérations sur une exécution neuve, et aucune autre liaison ne peut y être ajoutée ensuite. Les sessions de code gérées fonctionnent de la même manière.

Deux autres groupes existent dans le code et sont délibérément indisponibles. Les opérations de pilotage d’un onglet Chrome dans lequel vous êtes déjà connecté disposent d’une implémentation locale complète et d’une extension de messagerie native, mais le plan de contrôle refuse de les annoncer tant que le serveur ne peut pas prouver que la conversation d’origine était privée et enregistrer qui a divulgué quoi : la base est volontairement inerte, et l’extension n’est livrée dans aucun des deux installeurs. Par ailleurs, plusieurs opérations de code — rattacher, envoyer une consigne, interrompre et fermer — sont nommées dans le schéma mais n’ont pas d’implémentation, elles ne peuvent donc pas être accordées.

Fonctionnement

La connexion est toujours sortante

Le démon établit des connexions HTTPS et WSS sortantes vers votre API Nessie, et vers elle seule. Nessie ne contacte jamais un ordinateur portable, ne conserve jamais son adresse et ne traite jamais un point de terminaison du catalogue comme un transport vers une machine. C’est pourquoi un exécuteur fonctionne depuis un réseau domestique, derrière un NAT, sur un VPN d’entreprise, sans redirection de port ni règle de pare-feu entrante, et pourquoi arrêter le démon constitue une déconnexion complète et immédiate.

L’origine de l’API doit être en HTTPS. La seule exception est une adresse de boucle locale, destinée aux personnes qui exécutent Nessie sur leur propre machine et réglée par sa propre variable d’environnement ; aucun indicateur ordinaire ne transforme une origine de production en HTTP simple.

L’appairage prouve une machine, et une personne la confirme

L’appairage est une preuve à deux côtés. Une personne habilitée crée l’exécuteur dans Nessie avec son périmètre, et Nessie émet un enregistrement : un défi aléatoire de 256 bits, dont elle ne conserve qu’un vérificateur SHA-256, valable dix minutes et utilisable une seule fois.

Sur la machine, le démon génère une paire de clés Ed25519, la conserve dans un stockage protégé par le système d’exploitation et réservé au propriétaire, et écrit sur le disque la requête signée exacte avant tout appel réseau. Ainsi, une réponse perdue peut être réessayée avec la même clé préparée, au lieu d’un second appairage silencieux. Il soumet ensuite l’identifiant d’enregistrement, le défi, sa clé publique et une signature de preuve. Nessie conserve la clé publique et son empreinte. Elle ne conserve jamais la clé privée.

Nessie affiche ensuite cette empreinte à une personne, qui la confirme. Tant que cette confirmation et une preuve ultérieure de possession n’ont pas eu lieu, l’exécuteur reste hors ligne. L’appairage ne peut jamais être terminé à partir d’un texte de discussion ou d’une transcription de terminal : il exige une action humaine délibérée dans l’interface web ou de bureau.

Une machine qui perd sa clé ne peut pas récupérer son enregistrement d’exécuteur. Celui-ci est révoqué, et l’appairage recommence comme un nouvel exécuteur. La rotation de clé, en revanche, est une transaction unique, signée à la fois par l’ancienne clé et par la nouvelle.

Le descripteur est la déclaration signée de la machine sur elle-même

Un démon appairé publie un descripteur : une déclaration signée, à révision monotone, qui ne contient que des faits structurels — les schémas d’opérations qu’il prend en charge, ses limites de ressources et de réseau, sa plateforme et une empreinte de sa politique locale. Il ne contient aucun chemin d’hôte et ne crée aucune autorité dans le cloud.

Une nouvelle révision n’est jamais activée à réception. Elle est stockée en attente d’examen, et une personne habilitée doit la voir et la confirmer avant qu’elle puisse modifier ce qui est disponible. C’est ce qui empêche une actualisation des capacités d’accorder en silence de nouveaux pouvoirs : une opération nouvellement annoncée commence par être refusée.

Soyez clair sur ce que prouve la signature. Un descripteur signé par la clé d’un exécuteur appairé prouve que cette clé a fait cette déclaration. Il ne prouve pas que l’hôte est sain, et l’interface doit le dire.

Répartition : candidat, liaison, commande, accusé de réception

Un agent ne désigne jamais un exécuteur. Avant qu’une exécution puisse en utiliser un, Nessie résout l’opération logique en un candidat de disponibilité opaque et de courte durée. La réponse ne contient aucun identifiant d’exécuteur ; la base ne conserve qu’une empreinte du jeton de référence, avec la personne et l’action pour lesquelles il a été résolu. Les modèles et les clients reçoivent un jeton de référence, et non une machine sélectionnable.

La disponibilité repose sur un résolveur unique, utilisé de manière identique par l’API, le worker, l’interface et l’assistant :

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

Consommer le candidat crée une liaison sous un verrou de base de données, qui revérifie une seconde fois chacun de ces contrôles et fait avancer un compteur monotone (fence). La répartition les revérifie encore. Il en résulte qu’une autorisation retirée, une politique restreinte ou un exécuteur révoqué entre deux étapes arrête le travail au lieu d’être constaté après coup — et qu’une nouvelle tentative ne peut jamais aboutir sur une autre machine que celle à laquelle l’exécution était liée.

La commande elle-même emprunte la file d’attente ordinaire de Nessie et le cycle de vie des appels d’outils, au lieu d’en avoir une propre. Le démon interroge le canal de contrôle authentifié pour récupérer le travail ; il n’est jamais poussé. Une commande ne passe que par quatre accusés de réception, et aucun autre :

leased → accepted → started → result-acknowledged

Chaque trame lie l’identifiant de commande, la provenance de l’exécution, le compteur de liaison, la révision de capacité, une échéance, une clé d’idempotence et les empreintes des arguments et de la charge utile. Le démon refuse une incohérence, une politique périmée, une rejouabilité ou un second résultat pour une commande déjà terminée. Les arguments et les résultats finaux sont chiffrés au repos avec AES-256-GCM ; la base conserve un chiffré borné et des empreintes canoniques, et non le contenu.

Si un accusé de réception se perd, Nessie ne suppose pas la réussite. La commande est enregistrée avec un résultat inconnu, et l’exécution suit le chemin de reprise normal ; le démon, qui journalise localement chaque commande livrée avant de commencer le travail, ne répétera pas l’effet de bord. Un accusé tardif peut encore lever l’ambiguïté, honnêtement.

Frontière de confiance

Installer et appairer un exécuteur

Installez la CLI Mac avec Homebrew, les applications Mac avec les casks Homebrew, la CLI Linux via APT ou DNF, ou l’exécuteur Windows via WinGet. Chaque équipe appairée dispose de permissions distinctes, stockées sur l’ordinateur. Nessie contrôle les accès au sein de l’équipe ; elle ne peut pas modifier les ressources locales.

Le guide d’installation et d’appairage donne les commandes exactes, le déroulement à deux côtés avec le code à huit chiffres, les réglages locaux, le démarrage, les mises à jour et la désinstallation.

Degré de validation réel de chaque plateforme

L’état des trois bacs à sable invités diffère, et cette différence est importante. macOS est le moteur doté d’un chemin invité fonctionnel et éprouvé. Le moteur Firecracker sous Linux et le moteur Hyper-V sous Windows sont implémentés et couverts par des tests côté hôte — la séquence de lancement, les images disque, les transports de contrôle et de sortie, le protocole de brouillon — mais aucune invitée n’a encore démarré sur du matériel réel dans l’intégration continue de ce projet, car cela exige une machine dotée de KVM ou de Hyper-V, et les tâches qui le prouveraient n’en ont jamais eu une. L’ensemble de l’espace de travail, qui n’a pas besoin d’invitée, est exercé de bout en bout sous Windows avec une véritable boucle de contrôle. Considérez les opérations avec invitée sous Linux et Windows comme non validées tant que vous ne les avez pas éprouvées sur votre propre matériel. L’écran d’appairage de Nessie le précise aussi, avec ses propres mots.

Sécurité et confinement

Une seule racine d’espace de travail, dont le chemin reste sur la machine

L’appairage sélectionne exactement une racine d’espace de travail canonique : un seul répertoire, et non un ensemble de dossiers, ni jamais leur plus proche parent commun. Nessie reçoit le nom de base de la racine, afin qu’une personne puisse reconnaître la limite dans l’interface ; le chemin complet reste dans l’état de la machine, réservé au propriétaire, et n’est jamais envoyé. Il est possible de changer de racine, mais seulement après la suppression de tous les brouillons et bacs à sable locaux ; ce changement produit une nouvelle révision de descripteur, qui passe par le même examen humain que toute autre modification de politique. Elle ne peut jamais s’élargir en silence à un répertoire parent.

Les opérations sur fichiers n’acceptent que des chemins relatifs. Elles rejettent les traversées et chaque composant de lien symbolique, revérifient que la racine configurée est toujours un répertoire ordinaire, et renvoient des résultats structurés et bornés, ne contenant aucun chemin d’hôte.

Les écritures vont vers une copie, et seule une personne peut les appliquer

Un agent n’écrit jamais dans vos fichiers. file.write crée une arborescence bornée en copie à l’écriture sous le répertoire d’état du démon, rattachée à l’exécution ; les lectures et listages ultérieurs de cette exécution voient le brouillon. Le travail en invitée, y compris les sessions de code, utilise le même espace de travail temporaire en copie à l’écriture.

Appliquer un brouillon à l’espace de travail réel est une opération unique — workspace.promote — et c’est la seule écriture sur l’hôte dans le système. Elle n’a aucun schéma exposé aux modèles : aucun agent, aucun assistant et aucun chemin fourni par l’appelant ne peut transformer un brouillon en écriture sur l’hôte. À la place, une personne ouvre Vos brouillons examinés, appuie sur Examiner la promotion et confirme avec son mot de passe actuel. Le serveur revérifie alors l’empreinte d’examen reconnue, l’empreinte du manifeste, l’exécution d’origine, l’utilisateur et l’agent, la révision d’autorisation, l’autorisation d’opération et la politique locale active, avant de créer la commande. Sur la machine, le démon reconstruit lui-même le manifeste et refuse une empreinte modifiée : une modification faite après l’examen ne peut donc pas profiter de l’approbation de l’examen.

L’application elle-même repose sur des descripteurs et est journalisée. Le composant natif reçoit la racine de l’espace de travail et le brouillon déjà sous forme de descripteurs de répertoires ouverts, jamais de chemins ; il valide chaque composant par des opérations sans suivi de liens, refuse les liens symboliques, les liens physiques, les fichiers spéciaux et les franchissements de points de montage, et tient un journal tout-ou-rien récupérable : en cas de plantage, soit le manifeste validé est achevé, soit l’original est restauré avant toute autre opération.

L’invitée n’a pas de réseau, et la sortie est forcée

Lorsqu’une opération a besoin d’une invitée, il s’agit d’une micro-VM Linux par session, sans répertoire personnel de l’hôte, sans socket Docker, sans agent SSH, sans environnement hérité et sans montage de l’hôte autre que le partage de l’espace de travail. Le montage exécutable de l’environnement d’exécution est en lecture seule ; le montage de l’espace de travail accessible en écriture interdit l’exécution, si bien que tout ce qui s’exécute provient de la charge utile de l’environnement d’exécution vérifiée, et non de quelque chose qu’un agent aurait écrit. L’invitée abandonne une identité non privilégiée avant d’ouvrir le moindre socket, et un partage appartenant à root fait échouer le démarrage plutôt que de laisser une charge de travail privilégiée en marche.

Le point le plus important : l’invitée n’a aucune interface réseau. Sous Linux, la séquence de lancement ne configure délibérément aucune interface et ne crée aucun périphérique TAP ; sous Windows, la carte réseau virtuelle que Hyper-V ajoute par défaut est supprimée pendant l’installation. La seule route de l’invitée vers l’extérieur est un proxy de boucle locale à l’intérieur de l’invitée, tunnelisé par un socket virtuel vers un pont sur l’hôte, qui transmet les octets à la passerelle propre du démon — un écouteur à socket local réservé au propriétaire, sans écouteur TCP ni mode de redirection générale. C’est dans cette passerelle que s’appliquent les politiques HTTP, CONNECT, WebSocket, de redirection, d’origine, de téléchargement et de téléversement, à l’aide du mécanisme de requête épinglée déjà en place dans Nessie, plutôt que d’une seconde implémentation de ces mêmes règles. Il n’existe ni pont NAT ni résolveur DNS direct : le DNS alternatif, le TCP brut, QUIC et le contournement du proxy sont tous refusés.

La liste d’origines appliquée par cette passerelle est configurée sur la machine par son propriétaire et n’est délibérément jamais envoyée. L’interface signale cette absence, au lieu de prétendre que Nessie est un éditeur de politique d’origines : pour savoir ce qu’un exécuteur de navigateur peut atteindre, demandez à la personne qui possède la machine.

Identifiants

Aucun magasin d’identifiants de l’hôte n’est jamais monté dans une invitée. Ni le trousseau, ni ~/.codex ou ~/.claude, ni un jeton CLI global, ni une variable d’environnement portant une clé d’API. La seule connexion prise en charge pour une session de code gérée est un fichier d’authentification privé au propriétaire, dont le contenu n’est lu que par le générateur d’initrd contrôlé par le propriétaire — jamais par Nessie, jamais par le descripteur, jamais par un journal ni par un argument de commande — puis déplacé une seule fois dans un répertoire personnel privé à l’intérieur de l’invitée, détruit avec la VM. Cette invitée ne peut atteindre qu’une seule origine.

L’exécuteur de navigateur est encore plus strict : chaque session obtient un profil de navigateur privé neuf et refuse un profil préparé par l’espace de travail, si bien qu’il démarre sans cookies, sans extensions et sans état de connexion ambiant.

Les données locales brutes ne peuvent atteindre un fournisseur de modèle qu’à l’intérieur d’une exécution explicite et bornée. Nessie ne persiste que des manifestes expurgés, des empreintes d’arguments et de politique, des empreintes de résultats et un état structuré. Le contenu des fichiers, la sortie des terminaux, le DOM du navigateur, les identifiants et les facteurs d’authentification sont interdits dans les enregistrements de base, les entrées d’audit, les journaux, les événements temps réel et les rapports d’erreur.

Ce qu’un opérateur accorde, et comment il le retire

L’autorisation d’utiliser un exécuteur n’est pas un simple interrupteur. Un agent ne peut invoquer une opération que s’il détient une autorisation pour cet exact exécuteur et cette exacte opération, et la politique logique ordinaire de l’outil l’autorise, et le périmètre de l’exécution correspond, et la politique locale de la machine le permet. Accorder une opération à un exécuteur n’autorise donc rien sur un autre, et une actualisation des capacités ne peut rien élargir, car les nouvelles opérations arrivent refusées.

L’accès des agents et le partage prennent effet immédiatement sur la page elle-même, sans étape d’approbation, sans demande de mot de passe ni nouvelle authentification. Dans l’onglet Agents de l’exécuteur, un gestionnaire active ou désactive directement l’accès d’un agent à la machine ; dans Partage, il accorde à une personne le droit d’utilisation ou d’administration, ou étend l’utilisation à un projet ou à toute l’équipe actuelle, de la même façon. Dans votre propre conversation avec votre assistant — uniquement là, jamais dans un canal partagé, une tâche planifiée ou l’exécution d’un autre agent — l’assistant peut plutôt préparer une modification d’accès d’agent ou d’affectation, qui affiche une carte de confirmation dans cette conversation ; rien ne change tant que vous n’appuyez pas sur Autoriser l’accès, et un texte de discussion n’est jamais une confirmation.

Trois modifications exigent encore que vous ressaisissiez votre mot de passe actuel au moment de la confirmation : l’activation d’une révision de descripteur ; une affectation préparée par l’assistant qui donne la machine à une personne plutôt qu’à un agent ; et une politique permanente permettant aux collègues de lancer des commandes sur la machine en tant que son propriétaire, à savoir la politique de travail sur tickets sans surveillance. La déconnexion ou la suppression d’une machine ne demandent délibérément ni l’un ni l’autre, car un coupe-circuit ne doit jamais être plus difficile d’accès que ce qu’il arrête. La promotion d’un brouillon examiné l’exige toujours. La piste d’audit enregistre séparément la personne qui agit et l’implication de l’assistant.

Un exécuteur passe par un petit ensemble d’états explicites :

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

Le menu Ordinateur de l’en-tête est l’endroit où un gestionnaire prépare chaque changement de cycle de vie : le mettre en pause, le reprendre une fois en pause, le déconnecter ou le supprimer. La pause laisse l’exécuteur en ligne, mais l’empêche d’accepter des commandes. La déconnexion invalide ses certificats client et chaque jeton de candidat en attente, et ne peut pas être annulée : un exécuteur déconnecté doit être réappairé comme un nouvel exécuteur. La suppression fait de même et retire en plus l’exécuteur de la liste ; contrairement à la déconnexion, elle est proposée quel que soit l’état de l’exécuteur, y compris l’appairage en attente et l’exécuteur déjà déconnecté, car c’est le seul moyen de le retirer de la liste. La vidange — terminer le travail déjà reçu avant de cesser d’en accepter davantage — est un troisième état réel du protocole, et l’interface peut afficher une machine dans cet état, mais rien ici ne le déclenche : seul un appel direct à l’API le fait. Chaque changement d’accès confirmé, chaque examen de descripteur et chaque transition de cycle de vie, vidange comprise, fait aussi avancer l’époque de connexion du démon : sa prochaine interrogation de contrôle, au plus une seconde plus tard, échoue en mode fermé et arrête chaque invitée active avant qu’elle puisse se reconnecter. La révocation n’est pas une demande que la machine peut ignorer.

Exploiter un exécuteur

Vérifier qu’il fonctionne

Ce que vérifie Nessie elle-même, c’est la présence en ligne. Le démon signe un signal de présence, et un exécuteur dont la dernière activité authentifiée remonte à plus de soixante secondes est marqué durablement hors ligne avant de pouvoir être listé, sélectionné ou recevoir du travail. Un exécuteur affiché en ligne a prouvé qu’il était actif au cours de la dernière minute.

Il n’existe aucun point de terminaison de santé sur la machine : le démon n’écoute sur aucun port destiné à l’opérateur, par conception. Sous macOS et Linux, interrogez directement la CLI :

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

Sous macOS, le statut indique l’agent launchd de chaque équipe. La commande systemctl est réservée à Linux. Sous Windows, l’icône de la zone de notification donne la réponse d’un coup d’œil, son menu indique la raison, et le journal du service contient le détail. Sur les deux plateformes, l’onglet Vue d’ensemble de l’exécuteur dans Nessie affiche ses profils approuvés, sa frontière de données, la date de sa dernière activité et toute proposition de politique locale en attente d’examen.

Journaux

Chaque refus sur lequel une personne peut agir est consigné à cet endroit : un environnement d’exécution non signé ou altéré, un répertoire d’état qui ne peut pas être sécurisé, un exécuteur qui n’a pas démarré au lancement du système. Ne sont jamais consignés ici un défi d’appairage, une clé, ni la sortie d’un processus enfant. Il n’existe aucun réglage de niveau de journalisation à augmenter, car il n’y a rien de plus détaillé à activer.

La CLI Mac écrit le journal de service de chaque équipe dans ~/Library/Logs/NessieExecutor/<executorId>.log.

Mise à jour

Mettez à jour la CLI via Homebrew, APT ou DNF, puis redémarrez le service de chaque équipe avec disable suivi de enable. WinGet met à jour l’exécuteur Windows. Les installeurs directs de Nessie Desktop proposent des mises à jour signées dans l’application ; les installations MSI et Debian utilisent leur gestionnaire de paquets. Les appairages et les permissions locales survivent aux mises à jour.

Arrêt et suppression

L’arrêt est une voie propre, gérée par le démon, et non une interruption brutale. Le démon reçoit un signal de terminaison, arrête chaque session invitée, libère son bail et se termine. Sous Linux, l’unité attend quinze secondes pour un budget de nettoyage de dix secondes, et n’escalade jamais vers un arrêt forcé non interceptable — car un démon tué au milieu du nettoyage laisserait une micro-VM et une superposition d’espace de travail orphelines, sans processus pour les nettoyer. Un arrêt qui reste bloqué est donc visible dans systemctl --user status au lieu d’être silencieux, et l’escalade reste une décision humaine explicite.

Pour supprimer le paquet Linux :

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

Sous Windows, msiexec /x arrête et supprime le service, ses entrées de registre et l’entrée de démarrage de l’icône. Sur les deux plateformes, l’état appairé est délibérément conservé — ~/.local/state/nessie-executor/ sous Linux et %ProgramData%\Nessie Executor sous Windows. Un appairage est une clé de machine et une révision de politique signée, et désinstaller un programme n’est pas une demande de les détruire : la réinstallation les retrouve là où elles étaient. Supprimez le répertoire à la main pour oublier un appairage, et révoquez l’exécuteur dans Nessie pour y mettre fin depuis l’autre côté.

L’icône de la zone de notification Windows et le compagnon de bureau proposent tous deux Oublier l’appairage sur cet ordinateur comme action de premier plan : elle arrête le démon local, supprime la clé de la machine et le choix du dossier, et supprime définitivement les copies locales des brouillons après une confirmation native, tout en laissant à un propriétaire le soin de conserver ou de révoquer l’exécuteur côté serveur, ainsi que son historique d’audit.

Pannes courantes