Der Computer führt aus. Die Entscheidung bleibt bei mir.
In pi-os möchte ich „lösch das“ sagen können und der Computer erledigt es. Aber ich muss sehen, was er löschen will, und entscheiden können, ob das richtig ist. Deshalb habe ich Jeffrey Emanuels Destructive Command Guard geforkt. Mein Fork ergänzt einen nativen macOS-Freigabedialog und gemerkte Freigaben für geprüfte Skripte.
Ein Computer, der Anweisungen ausführt, braucht auch Rechte für Dinge, die sich nicht einfach rückgängig machen lassen. Verwechselt er das Ziel, sind die Dateien weg. Jeden Aufruf zu blockieren würde pi-os für diese Arbeit unbrauchbar machen. Alles still durchzuwinken wäre schlimmer. Ich brauche einen Punkt, an dem ich den tatsächlichen Eingriff prüfen und dafür die Verantwortung übernehmen kann.
dcg prüft Shell-Aufrufe, bevor der Agent sie ausführt. Mein Fork zeigt den Befehl, das Projekt, den Arbeitsordner, aufgelöste ausführbare Dateien und verfügbare Informationen zu den Zielen in einem nativen Dialog. Mit Touch ID gebe ich den angezeigten Geltungsbereich frei. Reichen die Informationen nicht für eine Prüfung, bleibt der Aufruf blockiert, statt einen Fehler als Zustimmung zu behandeln.
Im Dialog sehe ich, welcher Agent anfragt, welcher Befehl ausgeführt werden soll und in welchem Ordner. Die Details zeigen die verfügbaren Belege und Auszüge der geprüften Skripte. Der Geltungsbereich sagt mir, ob ich einen einzelnen Aufruf oder einen wiederverwendbaren Eintrag freigebe.
Bei dafür geeigneten Skriptprüfungen bestätige ich „Skripte prüfen und merken“ mit Touch ID. Der approved_scripts-Eintrag bindet Befehl, Projektordner, aufgelöste Skripte samt Inhalt und Rechten, ausführbare Dateien und geerbten Preload-Kontext. Andere Projektdateien darf ich ändern, ohne wieder gefragt zu werden. Ändert sich ein gebundener Bestandteil, ist eine neue Prüfung nötig. Über die Allowlist kann ich den Eintrag widerrufen.
Bei der Arbeit am Fork sind Fehlalarme und übersehene destruktive Befehle aufgefallen. Ich habe sie als #562 und #570 gemeldet. Jeffrey Emanuel hat den Fall mit konstanten Python-Argumenten, die vollständige Auswertung verschachtelt gequoteter Inline-Programme und Deno/Bun-Prozessaufrufe auf upstream main behoben. Für #570 hat er die Fixes ausdrücklich selbst implementiert, nicht meine Commits gemergt; der Fork hat ihm beim Vergleich geholfen. Der native Dialog bleibt eine Funktion meines Forks.
Native Ansicht aus dem produktiven Dialogcode mit synthetischen pi-os-Beispieldaten. Die Aufnahme ist eine UI-Vorschau: Kein Befehl ist ausgeführt worden, Touch ID war inaktiv und keine Freigabe ist gespeichert worden.
Dieselbe native Ansicht mit geöffneten Skriptdetails und dem Geltungsbereich approved_scripts. Pfade und Skript sind synthetische Beispiele; gezeigt wird weder eine erteilte Freigabe noch ein erfolgreicher Skriptlauf.
Die öffentliche Dokumentation des Forks erklärt, was eine gemerkte Skriptfreigabe umfasst, wann sie ungültig wird und wie ich sie widerrufe. Das ist Dokumentation auf GitHub, keine eigene Produktwebsite.
Freigabe-Dokumentation lesen github.com/tjansn/destructive_command_guard/blob/main/docs/learned-approvals.md#approved-scripts