Commandes libres et accord « ne plus demander »

Par défaut, aucune commande n’est libre : chaque commande que l’agent propose vous est présentée, et vous la validez ou la refusez. Deux décisions de l’administrateur de projet réduisent le nombre de demandes (livre blanc sécurité V3, section 5.1) :

• il liste des commandes libres, exécutées sans validation ;
• il vous autorise à ne pas revalider une commande que vous avez déjà validée, ou il interdit cette dispense.

Cette page décrit ces deux décisions, la façon de donner l’accord « ne plus demander » sur une commande, et ce qui reste soumis à votre validation dans tous les cas.

Ce que l’administrateur peut libérer

L’administrateur de projet peut libérer de la validation (livre blanc sécurité V3, section 5.1) :

• les commandes usuelles de compilation, de tests unitaires, de formatage et d’analyse ;
• la lecture de fichiers du dépôt ouvert ;
• toute commande qu’il liste.

Cette liste s’écrit dans la politique, depuis la console d’administration, et la passerelle l’évalue avant chaque exécution. Elle ne se règle pas depuis le poste : ni un drapeau du terminal ni un fichier du poste ne libère une commande que la politique ne liste pas.

Dans le document de politique, les commandes libres sont les règles allow du champ permissions, écrites comme des motifs d’outil :

{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(make *)"]
  }
}

L’écriture de la politique est décrite dans Régler la politique des postes depuis la console.

La dispense de revalidation se règle au même endroit, sur la ligne Remembered approvals (“don’t ask again”) de la section Session rules. Sur Forbidden, la politique écrit allowRememberedGrants à false : l’accord « ne plus demander » n’est ni proposé ni honoré.

Donner l’accord sur une commande

Quand l’agent appelle l’outil Bash, le terminal affiche la commande exacte et trois choix :

Validate
Validate + don't ask again
No, and tell Lemniscate what to do differently

Les touches Tab (valider), Shift+Tab (valider sans plus demander) et Esc (refuser) mènent aux mêmes réponses que les flèches et Entrée. Les touches y et n valident ou refusent l’appel en cours.

1. Choisissez Validate + don’t ask again. Aucun accord n’est enregistré à ce stade : un second écran, titré Don't ask again — what will be recorded, s’ouvre.
2. Sur ce second écran, la ligne Scope: porte This exact command, sélectionnée par défaut. La ligne du dessous montre la commande verbatim, sous la forme command = "git status" (verbatim).
3. Les lignes Project: et Until: disent où et jusqu’à quand l’accord vaut. La phrase du bas le résume : not another command, not another project, not another session.
4. Entrée ou y enregistre l’accord. Toute autre touche revient à la liste des trois choix sans rien enregistrer ; l’appel en cours reste à valider ou à refuser.

L’accord prend effet à l’appel suivant, sans redémarrer le terminal.

Ce que l’accord couvre

L’accord porte sur la commande que vous venez de valider, et sur elle seule. Il tient dans trois bornes, qui ne se règlent pas :

Borne	Valeur
Projet	le répertoire de travail dans lequel lemni a été lancé
Session	la session qui a donné l’accord
Durée	une heure après l’enregistrement

Hors de ces bornes, l’accord ne produit aucune règle : dans un autre répertoire, dans la session suivante ou une heure plus tard, la même commande demande à nouveau.

La commande est comparée par égalité, après retrait des espaces aux extrémités. git status n’ouvre ni git status --short, ni git remote set-url, ni une commande dont git status est le préfixe. Un * dans la commande approuvée est un caractère comme un autre, pas un motif.

L’accord ne couvre aucun autre outil, et il ne dispense pas de la validation des écritures : chaque écriture retenue vous est présentée sous forme de différence (livre blanc sécurité V3, section 5.4).

Où l’accord est enregistré

L’accord est écrit dans permissions.yaml, dans le répertoire de configuration du produit : ~/.lemniscate par défaut, ou le répertoire que désigne LEMNISCATE_GLOBAL_DIR. Ce répertoire est hors de la copie de travail du dépôt : l’agent ne peut pas modifier ce fichier.

Les accords vivent sous la clé accords. Chaque entrée porte l’outil, la commande, le projet, la session et l’échéance :

accords:
  - tool: Bash
    arguments:
      command: git status
    project: /home/vous/projets/exemple
    session: 5f0c2b1e-7d4a-4c1b-9e2f-3a8b6c4d0e11
    expiresAt: 2026-09-25T15:04:05.000Z

Chaque enregistrement réécrit le fichier et retire au passage les accords dont l’échéance est passée. Un fichier illisible n’est pas écrasé : l’enregistrement est refusé, et l’appel en cours reste validé.

Quand la politique interdit la dispense, le premier écran l’annonce et ne propose pas Validate + don’t ask again. Les accords déjà écrits restent dans le fichier et ne sont pas honorés tant que l’interdiction dure.

Retirer un accord

Un accord s’éteint de lui-même à la fin de la session qui l’a donné, ou une heure après son enregistrement, selon ce qui vient en premier. Pour l’éteindre avant :

1. Ouvrez permissions.yaml dans le répertoire de configuration du produit.
2. Supprimez l’entrée sous accords.
3. Enregistrez le fichier. Il est relu à l’appel suivant.

Ce qui reste soumis à validation

Quatre familles d’actions vous sont toujours soumises, quels que soient la liste de l’administrateur et vos accords (livre blanc sécurité V3, sections 5.1, 5.3 et 5.4) :

• toute commande absente de la liste de l’administrateur, tant que vous ne l’avez pas validée ;
• toute écriture retenue, présentée sous forme de différence ;
• tout outil que la politique marque sensible. Dans la console, ce sont les outils de la section Tools that ask every time ;
• toute modification d’un fichier exécuté par un tiers : configuration d’intégration continue, script de build, hook du gestionnaire de versions, manifeste de dépendances ou fichier de verrouillage. Elle est interdite par défaut ou soumise à une validation dédiée, distincte de la validation ordinaire et signalée comme telle.

Le terminal ajoute un contrôle propre aux commandes shell. Le premier écran l’annonce sous la commande : Dangerous commands will be blocked regardless of your preference. L’analyseur de commandes (@lemniscate/terminal-security) lit chaque commande au moment de l’appel et peut durcir un accord, sans l’assouplir :

• une commande qu’il classe « à confirmer » demande à chaque appel, même après un accord This exact command. C’est le cas des clients réseau (curl, wget, ssh), de l’installation de paquets (npm install, pip install), des interpréteurs qui reçoivent un script (python, node, sh, bash), des écritures git (add, commit, checkout), de rm, et des commandes qu’il ne connaît pas ;
• une commande qu’il classe « critique » est refusée sans question : sudo, su, doas, rm -rf sur un chemin système, mkfs, dd vers un périphérique, chmod 777 ou +s, chown root, eval et exec, le chargement de modules noyau et iptables.

Validée ou non, une commande réseau n’atteint rien : le bac à sable n’a pas d’interface réseau. git fetch et git push n’aboutissent pas non plus : l’agent n’a ni réseau ni identité sur la forge (livre blanc sécurité V3, sections 4.1 et 4.3).