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

Ein Agent soll git status ausführen, doch statt einer Antwort wartet die Session auf /approve. In einer Headless-Umgebung sieht das schnell wie ein Hänger aus. Tatsächlich kann hier eine Sicherheitsgrenze greifen.

OpenClaw führte Exec Approvals mit Version 2026.3.24 ein.¹ Die Einführung gehört zum damaligen Release-Kontext. Für aktuelle Policy-Details zählt immer die laufende OpenClaw-Dokumentation und die Konfiguration deiner Installation.

Warum ein harmloser Befehl blockiert

Vor Exec Approvals regelte vor allem die Tool-Policy (tools.exec.*) den Zugriff auf Gateway-Hosts und gepairte Nodes. Exec Approvals legen eine weitere Prüfung zwischen Agent und Host.

Ein Kommando läuft nur, wenn die Policy es erlaubt, es gegebenenfalls in einer Allowlist steht und eine erforderliche Freigabe vorliegt. Fehlt ein spezifischer Approval-Wert, greift der Wert aus der regulären Policy.¹

Das betrifft Gateway-Hosts und Nodes, etwa eine macOS-Companion-Umgebung. Ohne erreichbare Benutzeroberfläche greift ein Ask-Fallback. Steht dieser auf deny, wird die Ausführung blockiert. Das ist kein Defekt. Es ist das erwartete Sicherheitsverhalten.

Was bei einer Freigabe gebunden wird

Die damalige Einführung band den Ausführungskontext eng an die Entscheidung: Arbeitsverzeichnis, Kommandozeilenargumente, Umgebungsvariablen und Programmpfad.¹ Eine dauerhafte Freigabe für git status in einem Verzeichnis muss daher nicht für einen ähnlichen Befehl an einem anderen Ort gelten.

Auch Änderungen an einem bereits freigegebenen Shell-Skript können eine neue Bestätigung auslösen. Das schützt vor dem Fall, dass ein unauffälliger Aufruf später auf veränderten Inhalt zeigt. Wrapper wie time behandelt die Policy laut Dokumentation transparent.¹

Diese Genauigkeit kostet Komfort. Sie verhindert aber, dass eine Freigabe stillschweigend auf einen anderen Kontext übergeht.

Konfiguration mit einer kleinen Allowlist beginnen

Für Routineaufgaben ist eine kleine, überprüfbare Allowlist meist sinnvoller als eine breite Ausnahme. Die Konfiguration liegt in der OpenClaw-Konfigurationsdatei; ein mögliches Muster sieht so aus:

{
  "tools": {
    "exec": {
      "security": "allowlist",
      "ask": "on-miss",
      "allowlist": [
        "git status",
        "python3 scripts/*.py"
      ]
    }
  }
}

Welche Optionen deine Version unterstützt, prüfst du vor einer Änderung in der aktuellen Exec-Approvals-Dokumentation.¹ Eine breite Freigabe spart zwar Klicks, vergrößert aber auch die Wirkung eines falschen Prompts oder eines kompromittierten Skills.

Wenn eine Headless-Session scheinbar hängt

Prüfe zuerst, ob der Agent auf eine Approval-Entscheidung wartet. Danach klärst du drei Fragen:

1. Passt der konkrete Befehl zur Policy und zur Allowlist?
2. Hat sich Arbeitsverzeichnis, Argument oder Skriptinhalt gegenüber einer früheren Freigabe geändert?
3. Ist für die Umgebung ein sicherer Ask-Fallback konfiguriert?

In einer unbeaufsichtigten Umgebung sollte eine fehlende Freigabe nicht still zur Erlaubnis werden. Besser ist eine kontrollierte Ablehnung mit einem sichtbaren Hinweis im Log. Passe die Allowlist erst an, nachdem du den konkreten, wiederkehrenden Befehl geprüft hast.

Der Prüfstein im Betrieb

Exec Approvals sollen nicht umgangen werden, wenn sie einen Workflow bremsen. Sie zeigen, dass der Workflow eine Entscheidung über Rechte braucht.

Für mich ist die Mindestregel einfach: Routinekommandos bekommen eine enge Allowlist, riskante Aktionen bleiben bestätigungspflichtig, und Headless-Fallbacks lehnen im Zweifel ab. So bleibt ein Agent handlungsfähig, ohne dass jede neue Shell-Ausführung automatisch Host-Rechte erhält.

Für den Einstieg in Policies und Setup passt dazu unser OpenClaw-Tutorial.

Footnotes

1. https://docs.openclaw.ai/tools/exec-approvals ↩ ↩² ↩³ ↩⁴ ↩⁵