# Atomic Self-Close für Herdr-Spezialisten Status: am 01.09.2026 auf blunix live getestet. Dieses Dokument hält die freigegebene Sicherheitsgrenze, die beiden Laufzeitpfade und die bestätigte Evidenz fest. Die frühere Empfehlung für ausschließlich orchestrator-getriebenes Ernten ist durch die Nutzerentscheidung für echtes Self-Close überholt. ## Geltungsbereich Self-Close gilt für die sichtbaren Rollen `graphics`, `administrator`, `agent-manager` und `orga`. Der Reviewer bleibt ausdrücklich ausgeschlossen: Seine Rolle ist read-only, seine Claude-Settings enthalten kein Self-Close-Recht und seine Pane wird bei Bedarf durch den Orchestrator geschlossen. Nachträglich um `planner` erweitert (siehe `agents/planner.md`): gleicher Wrapper, gleiche drei Bedingungen, gleiche Claude-Allowlist-Struktur. Die oben beschriebene Codex-Live-Evidenz vom 01.09.2026 bezieht sich ausschließlich auf die vier ursprünglichen Rollen; für `planner` liegt kein eigener Codex-Test vor, dafür aber inzwischen ein erfolgreicher Claude-E2E-Test (siehe Abschnitt "Claude-Laufzeitpfad" unten) — für die anderen vier Rollen bleibt der Claude-Pfad weiterhin nur konfiguriert, nicht E2E-verifiziert. Die Capability erlaubt ausschließlich das Schließen der eigenen Pane. Sie ist keine Freigabe, fremde Panes zu starten, zu fokussieren, zu ersetzen oder zu schließen. Insbesondere bleibt ein freier Aufruf von `herdr pane close ` für Spezialisten verboten. ## Gemeinsames Sicherheitsprimitive Der Wrapper `/etc/scripts/close-my-pane.sh` ist auf blunix live. Er bezieht die Ziel-ID ausschließlich aus `$HERDR_PANE_ID` der aufrufenden Pane und ignoriert alle Argumente. Ein Test aus einer rohen Herdr-Shell bestätigte, dass er nur die eigene Pane schließt. Vor jedem Aufruf müssen alle Bedingungen gleichzeitig erfüllt sein: 1. Die letzte sichtbare Übergabe endet mit `COMPLETE`; es gibt keine offene Rückfrage und keinen `BLOCKED: …`-Zustand. 2. Das vollständige Ergebnis steht vor dem Schließen lesbar im letzten Turn. 3. Der Orchestrator hat das Ergebnis nachweislich gelesen und den Spezialisten ausdrücklich zum Self-Close freigegeben. Fehlt eine Bedingung, bleibt der Spezialist idle. Der Wrapper wird nie als Teil einer Befehlskette und nie mit Argumenten aufgerufen. Das Schließen ist der unwiderrufliche letzte Schritt; Pane und Kontext sind danach nicht mehr verfügbar. ## Codex-Laufzeitpfad (0.145) Codex unter `workspace-write` blockiert den direkten Wrapper-Aufruf. Deshalb muss Codex als einzigen Befehl exakt `/etc/scripts/close-my-pane.sh` mit `sandbox_permissions=require_escalated` aufrufen. Shell-Präfixe, Argumente, Umleitungen oder verkettete Befehle gehören nicht zu diesem Pfad. Beim bestätigten Test wurde die angebotene Prefix-Rule nativ über Option `p` gespeichert. Codex schrieb sie in `~/.codex/rules/default.rules`; sie erlaubt genau den Wrapper außerhalb der Sandbox. Danach schloss das Testpane `w5:pQ` erfolgreich, während der Orchestrator bestehen blieb. Für Codex 0.145 nicht wirksam waren separat bereitgestellte Rule-Dateien unter `/etc/codex/rules` sowie symlinked User-Rules. Sie dürfen deshalb weder als Voraussetzung noch als erfolgreiche Konfiguration dokumentiert werden. Die native Prefix-Rule ist Laufzeitkonfiguration außerhalb des Repositorys; der Rollentest prüft nur den dokumentierten Aufrufvertrag und setzt keine Datei im Home-Verzeichnis voraus. ### Wiederherstellung nach Verlust der Prefix-Rule `~/.codex/rules/default.rules` liegt außerhalb dieses Repositorys und wird von keiner Nix-Aktivierung erzeugt oder gesichert. Ein frisches Home-Verzeichnis (Neuaufsetzen von blunix, Fork, versehentliches Löschen) verliert die Regel kommentarlos — Codex fällt dann wieder auf das blockierte Verhalten unter `workspace-write` zurück, ohne Fehlermeldung im Rollenvertrag selbst. Erkennbar daran, dass ein sonst korrekt vorbereiteter Self-Close-Aufruf ohne sichtbaren Grund hängen bleibt oder eine Sandbox-Eskalationsabfrage auslöst, die vorher nicht kam. Wiederherstellung: den Wrapper-Aufruf einmal regulär auslösen (Bedingungen aus dem Abschlussprotokoll oben erfüllt), die von Codex angebotene Prefix-Rule über Option `p` erneut bestätigen. Der erwartete Regelinhalt ist als deklarative Referenz in `hosts/globalServices/herdr-self-close.nix` unter `/etc/codex/rules/herdr-self-close.rules` hinterlegt — Codex 0.145 liest diese Datei nicht selbst (siehe oben), sie dient ausschließlich als Repo-Referenz, mit welchem exakten Wortlaut die interaktive Bestätigung übereinstimmen muss. ## Claude-Laufzeitpfad Claude ruft exakt `Bash(/etc/scripts/close-my-pane.sh)` auf. Die fünf rollenspezifischen Allowlist-Einträge sind vorhanden: - `agents/claude-settings/administrator.json` - `agents/claude-settings/agent-manager.json` - `agents/claude-settings/grafiker.json` - `agents/claude-settings/orga.json` - `agents/claude-settings/planner.json` Jeder Claude-Start und jedes Resume muss weiterhin die katalogisierte Settings-Datei explizit per `--settings` laden. Ein nacktes Resume erbt die Rollen-Allowlist nicht zuverlässig. Beim ersten Claude-E2E-Test der Rolle `planner` wurde nicht Bash generell gesperrt: Der abgelehnte Aufruf war eine Diagnose-Befehlskette (`echo ...; echo ...; ls ...`) statt eines Versuchs des erlaubten exakten Einzelbefehls. Bash war im selben Session-Verlauf zuvor mehrfach für andere Befehle nutzbar (Transkript-Zeilen 38–46 gegenüber 173–177 in `/home/drone/.claude/projects/-home-drone-nixos-config/923d939a-07b7-4c58-8d7c-085a8f4017ea.jsonl`). Der Planner schloss daraus voreilig auf einen generellen Lockout, statt den tatsächlich erlaubten Befehl zu versuchen. Beobachtung/Hypothese zum Permission-Matching (nicht als verifizierter Plattform-Fakt): Die schmale Exact-Match-Bash-Regel lehnt offenbar jede Nicht-Exact-Nutzung desselben benannten Pfads ab, statt auf ein generisches Safe-Read-Verhalten zurückzufallen. **Nachtest bestanden (01.09.2026, Rolle `planner`, Testpane `w5:pY`):** Mit dem korrigierten Rollenvertrag (nur der exakte Einzelbefehl, keine Vorab-Diagnose per Bash) erreichte `planner` COMPLETE und schloss nach Orchestrator-Freigabe erfolgreich selbst — die Pane verschwand sofort ohne erneute Ablehnung. Der Claude-Pfad ist damit für `planner` **live E2E-verifiziert**. Für Administrator, Agent-Manager, Grafiker und Orga steht ein eigener Claude-E2E-Lauf weiterhin aus; für diese vier bleibt der Pfad "konfiguriert, aber nicht live E2E-verifiziert". ## Bestätigte Regressionen und Restgrenze Die statischen Rollentests sichern: - Rollenheader und `agents/catalog.json` stimmen für die fünf Self-Close-Rollen überein. - Alle fünf Rollen nennen den exakten Codex-Aufruf einschließlich `sandbox_permissions=require_escalated`, sowie das Verbot von Befehlsketten/Vorab-Diagnosen für den Claude-Pfad. - Die fünf Claude-Allowlist-Einträge erlauben exakt den Wrapper, kein breites `Bash(*)` und kein freies Herdr-Pane-Recht. - Reviewer-Rolle und Reviewer-Settings bleiben frei von Self-Close. - Der Harness liest keine externen Home- oder System-Rule-Dateien. Der offene Nachweis ist der Claude-E2E-Lauf für die verbleibenden vier Rollen (Administrator, Agent-Manager, Grafiker, Orga) — für `planner` liegt er inzwischen vor (siehe oben). Ein Nachweis erweitert keine Berechtigung und erfordert keine weitere NixOS-Aktivierung. Bis er für eine Rolle erfolgreich ausgeführt wurde, muss jede Dokumentation für diese Rolle zwischen „Allowlist vorhanden“ und „E2E bestätigt“ unterscheiden.