Exec-Approvals-Policy: Warum OpenClaw 2026.3.24 plötzlich /approve verlangt

Mit der Version 2026.3.24 führt OpenClaw sogenannte Exec Approvals ein. Wenn ein Agent plötzlich über /approve die Freigabe für Shell-Kommandos verlangt, greift hier eine neue Sicherheitsebene. Diese Funktion schützt Host-Systeme gezielt vor ungewollten Ausführungen durch fehlerhafte Prompts oder kompromittierte Skills.

Hintergrund und Funktionsweise

Bisher regelte primär die Tool-Policy (tools.exec.*) den Zugriff auf Gateway-Hosts und gepairte Nodes. Exec Approvals fungieren nun als zusätzlicher Sicherheitsriegel zwischen dem Agenten und dem Host.

Ein Kommando wird nur dann ausgeführt, wenn die Policy es erlaubt, es in einer eventuell konfigurierten Allowlist steht und der Nutzer – falls erforderlich – zustimmt. Fehlt ein spezifisches Approval-Feld, greift der Wert aus der regulären Policy. Diese Mechanismen greifen sowohl auf dem Gateway-Host als auch auf Node-Hosts, wie etwa der macOS Companion App. Ist keine Benutzeroberfläche verfügbar, greift ein Ask-Fallback, der standardmäßig auf deny steht und die Ausführung blockiert.

Neuerungen in Version 2026.3.24

Die aktuelle Version bringt laut den offiziellen Release Notes mehrere Verschärfungen mit sich. Die Standard-Policy ist nun restriktiver voreingestellt. Zudem bindet OpenClaw den exakten Ausführungskontext: Das Arbeitsverzeichnis, die genauen Kommandozeilenargumente, Umgebungsvariablen und der Pfad zum Programm werden fest erfasst.

Besonders relevant ist der neue Schutz der Dateiintegrität. Wenn sich ein Shell-Skript nach der Freigabe ändert, muss das Kommando neu genehmigt werden. Dies verhindert nachträgliche Manipulationen. Wrapper wie time werden dabei transparent behandelt, sodass die Allowlist-Auswertung konsistent bleibt.

Das Trust-Modell

Das System geht davon aus, dass am Gateway authentifizierte Nutzer vertrauenswürdige Operatoren sind. Gepairte Nodes weiten dieses Vertrauen auf den Node-Host aus. Die Exec Approvals dienen primär dazu, versehentliche Ausführungen zu stoppen. Sie fungieren nicht als harte Grenze gegen böswillige, bereits authentifizierte Operatoren.

Konfiguration in der Praxis

Wenn das System nach einer Freigabe fragt, stehen Optionen wie allow-once (einmalig), allow-always (dauerhaft in die Allowlist aufnehmen) oder deny (ablehnen) zur Verfügung.

Die Steuerung erfolgt über die OpenClaw-Konfiguration (~/.openclaw/config.json5). Dort lässt sich das Verhalten präzise einstellen:

{
  "tools": {
    "exec": {
      "security": "allowlist", // Alternativen: "full", "deny"
      "ask": "on-miss",        // Alternativen: "always", "off"
      "allowlist": [
        "ls -la",
        "git status",
        "python3 scripts/*.py"
      ]
    }
  }
}

Für Headless-Setups ohne Benutzeroberfläche empfiehlt sich die Nutzung des Ask-Fallbacks, um blockierende Abfragen zu vermeiden. Alle getroffenen Entscheidungen dokumentiert OpenClaw zudem im Log unter ~/.openclaw/logs/exec-approvals.log.

Fehlerbehebung im Alltag

Wenn ein Agent scheinbar hängt, wartet er oft auf eine Freigabe im Hintergrund. In Headless-Umgebungen sollte daher die Konfiguration entsprechend auf automatische Ablehnung oder Erlaubnis (nur in sicheren Umgebungen) angepasst werden.

Ein weiteres häufiges Phänomen: Dauerhafte Freigaben (allow-always) scheinen nicht zu greifen. Da OpenClaw den exakten Kontext bindet, führt schon eine minimale Änderung der Argumente oder des Verzeichnisses zu einer erneuten Abfrage. Hier helfen Wildcards in der Allowlist. Auch bei Skripten, die sich während der Entwicklung häufig ändern, greift der Integritätsschutz. In solchen Fällen ist die Arbeit in einem als sicher definierten Verzeichnis ratsam.

Einordnung

Die Einführung der Exec Approvals unterstreicht die zunehmende Ausrichtung von OpenClaw auf produktive Umgebungen. In Multi-User-Szenarien und regulierten Industrien sind solche Audit-Trails und Guardrails zwingend erforderlich, um die Integrität der Sandbox zu gewährleisten – besonders, wenn die Anzahl verfügbarer Skills und Plugins kontinuierlich wächst.

Fazit

Die zusätzlichen Freigabeanfragen dienen der Systemsicherheit und sollten nicht durch Workarounds umgangen werden. Durch eine saubere Konfiguration von Allowlists für Routine-Aufgaben und den bewussten Einsatz von dauerhaften Freigaben lässt sich der Workflow effizient anpassen. Autonome Agenten behalten ihre Leistungsfähigkeit, agieren aber in einem kontrollierteren und sichereren Rahmen.