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

Die neueste OpenClaw-Version 2026.3.24 hat eine fundamentale Änderung eingeführt: Exec Approvals. Wenn dein Agent jetzt plötzlich /approve für Shell-Kommandos verlangt, ist das kein Bug – es ist ein bewusstes Sicherheitsfeature. Wir erklären dir, was sich geändert hat und wie du sauber damit arbeitest.

Warum jetzt? Das Sicherheits-Dilemma autonomer Agenten

OpenClaw-Agenten wurden immer mächtiger. Sie können auf deinen Gateway-Host und gepairte Nodes zugreifen, Dateien manipulieren, Prozesse starten – die klassische „Sandbox“ wurde durchlässig.

Das Problem: Ein fehlerhafter Prompt, ein Halluzination oder ein bösartiger Skill könnte ungewollte Kommandos ausführen. Bisher kontrollierte nur die Tool-Policy (tools.exec.*) und optionales Elevated-Gating den Zugriff.

Die Lösung: Exec Approvals als zweite Sicherheitsebene. Sie sind wie ein physischer Sicherheitsriegel zwischen deinem Agenten und deinem Host.

Was sind Exec Approvals genau?

Exec Approvals sind ein Companion-App / Node-Host Guardrail. Sie funktionieren wie ein Safety-Interlock: Ein Kommando darf nur dann ausgeführt werden, wenn drei Bedingungen erfüllt sind:

1. Policy (tools.exec.*) erlaubt es
2. Allowlist (falls konfiguriert) enthält das Kommando
3. User Approval (optional) wurde gegeben

Die effektive Policy ist immer die strengere von tools.exec.* und den Approval-Defaults. Fehlt ein Approval-Feld, wird der tools.exec-Wert verwendet.

Wo gelten Exec Approvals?

• Gateway Host → Der openclaw-Prozess auf deinem Gateway
• Node Host → macOS Companion App oder headless Node Host

Wichtig: Wenn die Companion-UI nicht verfügbar ist (z.B. headless-Setup), verwendet OpenClaw den Ask-Fallback – standardmäßig deny.

Was hat sich in 2026.3.24 konkret geändert?

Die Release-Notes von 2026.3.24 zeigen klare Sicherheitsverbesserungen:

1. Strengere Standard-Policy

Vorher konnten viele Kommandos ohne explizite Genehmigung laufen. Jetzt ist die Default-Einstellung restriktiver – besonders für gateway und node Hosts.

2. Canonical Execution Context Binding

OpenClaw bindet jetzt den exakten Ausführungskontext:

• Canonical cwd – das tatsächliche Arbeitsverzeichnis
• Exact argv – die genauen Kommandozeilenargumente
• Env Binding – wenn Environment-Variablen vorhanden sind
• Pinned Executable Path – der konkrete Pfad zum ausführbaren Programm

3. File Integrity Protection

Für Shell-Scripts und direkte Interpreter-Aufrufe versucht OpenClaw, eine konkrete lokale Datei zu binden. Ändert sich diese Datei nach der Genehmigung, muss das Kommando neu genehmigt werden. Das verhindert „Bait-and-Switch“-Angriffe.

4. Transparent Dispatch Wrapper

Die Security/Exec-Approvals behandeln time (und ähnliche Wrapper) nun als transparent – die Allowlist-Evaluation und allow-always-Persistenz bleiben konsistent.

Trust-Modell: Wer ist eigentlich „vertrauenswürdig“?

OpenClaw’s Exec Approvals setzen auf ein klares Trust-Modell:

• Gateway-authentifizierte Caller sind „trusted operators“ für diesen Gateway
• Gepairte Nodes erweitern diese Trusted-Operator-Fähigkeit auf den Node-Host
• Exec Approvals reduzieren Accidental-Execution-Risk – aber sie sind keine per-User-Authentifizierungsgrenze

Das bedeutet: Wenn du als Gateway-Operator authentifiziert bist, vertraut dir OpenClaw grundsätzlich. Die Approvals sollen hauptsächlich versehentliche Ausführungen verhindern, nicht böswillige Operatoren abwehren.

Praxistipps: So arbeitest du sauber mit Exec Approvals

1. Verstehe die /approve-Befehlsstruktur

Wenn OpenClaw nach Approval fragt, siehst du sowas:

/approve allow-once "ls -la /etc"
/approve allow-always "ls -la"
/approve deny "rm -rf /"

• allow-once – Nur dieses eine Kommando erlauben
• allow-always – Dieses Kommando dauerhaft zur Allowlist hinzufügen
• deny – Kommando ablehnen

2. Konfiguriere deine tools.exec Policy

In deiner OpenClaw-Config (~/.openclaw/config.yaml oder ähnlich):

tools:
  exec:
    security: "allowlist"  # oder "full"/"deny"
    ask: "on-miss"         # oder "always"/"off"

3. Nutze den Ask-Fallback für Headless-Setups

Für automatisierte Workflows ohne UI:

tools:
  exec:
    ask: "on-miss"
    # Bei fehlender UI → automatisch deny

4. Allowlist für häufig verwendete Kommandos

Wenn bestimmte Kommandos immer erlaubt sein sollen:

tools:
  exec:
    security: "allowlist"
    allowlist:
      - "ls -la"
      - "git status"
      - "python3 scripts/*.py"

5. Monitor die Approval-Logs

OpenClaw protokolliert alle Approval-Entscheidungen. Prüfe regelmäßig:

tail -f ~/.openclaw/logs/exec-approvals.log

Die 3 häufigsten Probleme – und ihre Lösungen

Problem 1: “Mein Agent hängt und wartet auf Approval”

Lösung: Prüfe, ob die Companion-UI läuft. Für headless: Config auf ask: "off" setzen (nur wenn sicher!).

Problem 2: “Allow-always wird nicht persistent gespeichert”

Lösung: OpenClaw 2026.3.24 bindet den canonical context. Wenn sich cwd oder argv minimal ändern, zählt es als neues Kommando. Nutze Wildcards in der Allowlist.

Problem 3: “Script-Änderungen erfordern neue Approval”

Lösung: Das ist beabsichtigt! File Integrity Protection. Für Entwicklungs-Scripts: Allowlist mit Wildcard (scripts/*.py) oder in Safe-Verzeichnis arbeiten.

Warum diese Änderung wichtig ist

Exec Approvals markieren einen Wendepunkt in der OpenClaw-Entwicklung:

1. Production-Readiness – Agenten werden zunehmend in produktiven Umgebungen eingesetzt. Safety-First ist kein Nice-to-have mehr.

2. Multi-User-Szenarien – Wenn Teams OpenClaw nutzen, braucht es klare Verantwortlichkeiten und Audit-Trails.

3. Regulatorische Compliance – Für bestimmte Industrien (Finanz, Healthcare) sind solche Guardrails essentiell.

4. Ecosystem-Trust – Je mehr Skills und Plugins verfügbar sind, desto wichtiger wird Sandbox-Integrität.

Fazit: Nicht umgehen – verstehen und konfigurieren

Die /approve-Anfragen mögen zunächst störend wirken, aber sie sind ein Zeichen von Reife. OpenClaw 2026.3.24 entscheidet sich bewusst für Safety over Convenience.

Die richtige Reaktion: Nicht nach Workarounds suchen, sondern deine Workflows anpassen. Konfiguriere Allowlists für Routine-Kommandos, nutze allow-always für vertrauenswürdige Tools, und behalte den Ask-Fallback für kritische Umgebungen im Kopf.

OpenClaw-Agenten werden nicht weniger mächtig – sie werden nur sicherer kontrolliert. Und das ist genau das, was wir für eine nachhaltige Agenten-Ökologie brauchen.

---

Weiterführende Links:

• OpenClaw Exec Approvals Dokumentation
• OpenClaw 2026.3.24 Release Notes
• OpenClaw GitHub Repository