OpenClaw Approvals erklärt: /approve, Sandboxing und Host-Exec ohne Blindflug

Wenn OpenClaw in einem produktiven Setup plötzlich /approve fordert, steckt fast nie “ein kaputter Bot” dahinter. Meist kollidieren drei Ebenen miteinander: Sandboxing für normale Tool-Läufe, Host-Exec-Policy für Befehle auf gateway oder node und eine lokale Approvals-Datei auf genau dem Host, der den Befehl tatsächlich ausführt.

Das ist der Punkt, an dem viele Setups kippen: Im Chat wirkt alles wie ein einziger Schalter, technisch sind es aber getrennte Sicherheitslagen. Sandboxing begrenzt, worauf ein Tool zugreifen kann, wenn ein Modell danebenliegt — den sogenannten Blast Radius eines Fehlers. Exec-Approvals kontrollieren Host-Befehle, und die effektive Policy ist die strengere Kombination aus tools.exec.* und den lokalen Approvals-Defaults auf dem Ausführungshost. Wenn du diesen Artikel durch hast, solltest du sauber unterscheiden können, ob ein Problem von der Sandbox, von /approve oder von einer zu strengen Host-Policy kommt.

Mehr Kontext zur Sicherheitsseite von OpenClaw findest du auch in unserem Guide zu Secrets und API-Keys mit SecretRef und in der Einordnung zu OpenClaw Desktop mit klaren Sicherheitsgrenzen.

Wenn /approve plötzlich auftaucht

Das typische Fehlerbild sieht so aus:

• ein Agent darf lesen, schreiben oder Logs sichten, aber Host-Befehle bleiben hängen
• ein Command läuft lokal durch, auf dem Gateway oder Node dagegen nicht
• ein Operator stellt tools.exec.mode um, bekommt aber weiter Prompts oder Denies
• ein Chat-Kanal zeigt Approval-Nachrichten, obwohl jemand den Modus schon auf “offen” gesetzt zu haben glaubt

OpenClaw trennt hier bewusst:

• Sandboxing betrifft normale Tool-Ausführung wie exec, read, write, edit, apply_patch oder process innerhalb einer isolierten Laufzeit.
• Exec-Approvals greifen erst dann, wenn ein gesandboxter oder hostnaher Agent auf einem echten Host ausführen will, also auf gateway oder node.
• Chat-Approvals sind nur die Bedienoberfläche für Freigaben. Die eigentliche Entscheidung fällt lokal auf dem Ausführungshost.

Das ist der wichtigste mentale Fix: /approve ist kein allgemeiner OpenClaw-Panikschalter. Es ist nur ein sichtbares Symptom dafür, dass ein Host-Befehl zusätzliche Freigabe braucht oder die lokale Host-Policy strenger ist als erwartet.

Sandboxing begrenzt Werkzeuge, nicht den ganzen Gateway

Sandboxing ist eine optionale Isolationsschicht für Tools. Aktiviert wird sie über agents.defaults.sandbox oder agentenspezifisch über agents.list[].sandbox. Ist sie aus, laufen Tools direkt auf dem Host. Ist sie aktiv, bleibt der Gateway-Prozess selbst auf dem Host; isoliert wird nur die eigentliche Tool-Ausführung.

Wichtig für die Praxis:

• Sandboxing ist keine perfekte Sicherheitsgrenze.
• Es reduziert aber Dateisystem- und Prozesszugriff deutlich, wenn ein Modell Unsinn produziert.
• Der Browser kann getrennt in der Sandbox laufen.
• Elevated-Exec ist die explizite Ausnahme von dieser Regel — ein Befehl, der bewusst außerhalb der Sandbox läuft und den konfigurierten Host-Pfad nutzt.

Für viele Troubleshooting-Fälle ist der Modus entscheidend. agents.defaults.sandbox.mode steuert, wann überhaupt gesandboxt wird:

• off: keine Sandbox
• non-main: nur Nicht-Haupt-Sessions laufen in der Sandbox
• all: jede Session läuft gesandboxt

Gerade non-main ist ein typischer Stolperstein. Wer erwartet, dass nur delegierte Spezial-Agenten betroffen sind, liest die Einstellung zu eng. Der Modus richtet sich an session.mainKey, nicht an der Agent-ID aus. Gruppen- oder Channel-Sessions zählen dadurch ebenfalls als Nicht-Haupt-Sessions und landen in der Sandbox.

Exec-Approvals greifen erst auf dem echten Host

Exec-Approvals sind die Host-Grenze für Befehle auf gateway oder node. Ein Command ist nur dann erlaubt, wenn Policy, Allowlist und optional eine Benutzerfreigabe zusammenpassen. Das gilt lokal auf dem Zielhost:

• Gateway-Host: der openclaw-Prozess auf der Gateway-Maschine
• Node-Host: der Node-Runner, etwa als Companion-App oder headless Node

Genau deshalb fühlt sich dasselbe Setup auf zwei Maschinen manchmal widersprüchlich an. Die Freigabe lebt nicht nur in der Chat-Oberfläche und auch nicht nur in der JSON-Konfiguration. Der lokale Approval-Zustand auf dem Ausführungshost zählt mit.

Dabei gelten zwei harte Grenzen:

• Exec-Approvals sind kein Mehrbenutzer-Schutz.
• Exec-Approvals sind keine Read-only-Isolation.

Sobald ein Host-Befehl genehmigt ist, kann er Dateien im Rahmen der gewählten Host- oder Sandbox-Rechte ändern. Wer “Approvals aktiv” mit “damit kann nichts passieren” verwechselt, baut sich nur ein falsches Sicherheitsgefühl.

Diagnose: Welche Policy gilt wirklich?

Wenn Host-Exec blockiert oder dauernd nachfragt, brauchst du keine Theorie, sondern eine kurze Kommandoleiter.

1. Erwartung klären

Prüfe zuerst, was du eigentlich willst:

• Soll der Agent nur in der Sandbox arbeiten?
• Soll Host-Exec nur für eine kleine Befehlsmenge erlaubt sein?
• Soll für jede neue Command-Form nachgefragt werden?
• Soll auto erst den OpenClaw-Auto-Reviewer prüfen lassen und nur bei Unsicherheit an Menschen eskalieren?
• Oder willst du für einen bewusst vertrauensvollen Host nie wieder einen Prompt sehen?

Ohne diese Vorentscheidung schraubst du nur blind an Schaltern.

2. Effektive Policy sichtbar machen

Dafür reichen zwei Kommandos:

openclaw approvals get
openclaw exec-policy show

Damit bekommst du nicht nur die gewünschte Policy aus tools.exec.*, sondern auch die hostseitige Regel und das zusammengeführte Ergebnis. Genau hier taucht der häufigste Aha-Moment auf: Ein lokaler oder hostseitiger Wert kann weiter strenger sein als die Session- oder Config-Vorgabe.

Expected: Nach einer Lockerung verschwinden Prompts oder Denies für den gewünschten Host-Pfad.

Actual bei vielen Fehlersuchen: tools.exec.mode wurde angepasst, aber die hostlokale Approval-Datei steht weiter auf einer strengeren Ask- oder Deny-Variante.

3. Host-Ziel sauber unterscheiden

openclaw approvals get ohne Ziel bezieht sich standardmäßig auf den lokalen Host. Für verteilte Setups ist das oft die falsche Stelle. Dafür gibt es zwei Zieloptionen:

openclaw approvals get --gateway
openclaw approvals get --node <id|name|ip>

Wenn ein Befehl auf dem Node scheitert, hilft dir eine lokale Lockerung auf dem Laptop oder Admin-Host gar nichts. Du musst die Policy auf dem Host prüfen, der den Befehl wirklich ausführt.

4. Ask-Fallback mitdenken

Für fehlende oder nicht erreichbare UI-Freigaben gilt standardmäßig askFallback: deny. Wenn eine Freigabe nötig wäre, aber keine Companion-App oder kein passender Approval-Kanal erreichbar ist, wird der Befehl also standardmäßig geblockt.

Das ist ein häufiger Irrtum: Nicht jede blockierte Freigabe ist ein Fehler im Chat-Client. Manchmal ist die Policy korrekt, aber die erreichbare Freigabestrecke fehlt.

5. Sandboxing und Host-Exec nicht vermischen

Wenn ein Dateizugriff oder Prozess in der Sandbox funktioniert, ein Host-Befehl aber nicht, ist das kein Widerspruch. Genau dafür existiert die zweite Sicherung. Umgekehrt bedeutet ein entspanntes Host-Approval nicht, dass Sandboxing plötzlich aus ist. Beide Ebenen lösen unterschiedliche Probleme.

Welche Modi für Host-Exec sinnvoll sind

Die typischen Ziele lassen sich auf fünf Modi zusammenfassen:

• deny: Host-Befehle komplett blockieren
• allowlist: nur bekannte sichere Kommandos erlauben
• ask: für neue Command-Formen eine Freigabe verlangen
• auto: erst automatischen Review laufen lassen, dann gegebenenfalls Menschen fragen
• full: Host-Exec ohne Approval-Stopps

Für die meisten produktiven Setups ist allowlist, ask oder auto der vernünftigere Start. auto ist dabei kein Synonym für „offen“, sondern allowlist plus on-miss — die Rückfrage kommt also nur, wenn ein Kommando noch nicht auf der Liste steht —, ergänzt um OpenClaws nativen Auto-Reviewer. full ist kein Bug, aber eine bewusste Vertrauensentscheidung.

Wenn du Host-Exec wirklich ohne Stopps willst, müssen sowohl die OpenClaw-Konfiguration als auch die hostseitige Approvals-Datei dazu passen.

Das führt direkt zum nächsten Stolperstein: Ein YOLO-Setup auf dem lokalen Rechner ändert nicht automatisch Gateway- oder Node-Hosts. openclaw exec-policy ist ausdrücklich lokal gedacht. Für entfernte Hosts bleibst du bei gezielten approvals-Kommandos auf --gateway oder --node.

Recovery ohne YOLO-Schalter

Wenn Approvals im Alltag nerven, ist der schlechteste Reflex der globale Sicherheitsabriss. Besser ist diese Reihenfolge:

1. Erst die enge Stelle finden

Prüfe, ob das Problem wirklich Host-Exec ist oder nur eine falsch verstandene Sandbox-Regel. Viele Wartungs- oder Analyse-Jobs brauchen gar keinen Escape auf den Host.

2. Dann gezielt reduzieren

Wenn ein Workflow immer dieselben bekannten Kommandos braucht, ist allowlist stabiler als dauerndes Ad-hoc-Bestätigen. Dafür gibt es direkte Helper:

openclaw approvals allowlist add "~/Projects/**/bin/rg"
openclaw approvals allowlist add --agent main --node <id|name|ip> "/usr/bin/uptime"

3. Für lokale Maschinen mit Presets arbeiten

Wenn du lokal schneller zwischen strenger und lockerer Policy wechseln willst, sind die exec-policy-Presets sauberer als Halb-Manöver:

openclaw exec-policy preset cautious
openclaw exec-policy preset yolo

cautious setzt lokal host=gateway, security=allowlist, ask=on-miss und askFallback=deny. yolo setzt lokal security=full, ask=off und askFallback=full.

Wichtig: Diese Presets sind lokal-only. Sie synchronisieren nicht automatisch Gateway- oder Node-Hosts.

4. Nur für den richtigen Host lockern

Ein Node mit produktivem Dateizugriff sollte nicht dieselbe Approval-Politik bekommen wie ein Test-Gateway. Gerade in Multi-Host-Setups lohnt sich getrennte Schwere.

Wenn du bewusst eine Host-Policy setzen willst, nutze die Zieloptionen explizit:

openclaw approvals set --gateway --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "on-miss",
    askFallback: "deny"
  }
}
EOF

Oder für einen Node:

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "on-miss",
    askFallback: "deny"
  }
}
EOF

5. YOLO wirklich als Sonderfall behandeln

Wenn du Host-Exec auf einem vertrauensvollen Host bewusst nie wieder stoppen willst, brauchst du beide Ebenen offen:

• die gewünschte OpenClaw-Policy in tools.exec.*
• die passende hostlokale Approvals-Datei

Lokal geht das schnell mit:

openclaw exec-policy preset yolo

Für Gateway oder Node dagegen musst du gezielt die Host-Approvals setzen. Und selbst dann bleibt der Punkt wichtig: YOLO regelt Approvals, nicht Routing. tools.exec.host=auto heißt weiter “Sandbox wenn vorhanden, sonst Gateway”.

Reality Check für echte Betriebsfragen

Bevor du Approvals “entschärfst”, beantworte diese Fragen ehrlich:

• Arbeitet der Agent in einer Testumgebung oder an echten Projektdateien?
• Soll er nur lesen, oder auch Pakete, Services und Produktionskonfiguration anfassen?
• Ist der Ausführungshost personengebunden und vertraut, oder hängt dort mehr Infrastruktur dran?
• Kannst du im Fehlerfall sehen, welcher Host einen Befehl ausgeführt hat?
• Weißt du, ob ein Block von Sandboxing, Exec-Approvals, askFallback oder Chat-Freigabe stammt?

Wenn du hier zweimal raten musst, ist full fast sicher zu früh.

Was Exec-Approvals nicht für dich lösen

Exec-Approvals sind eine gute Leitplanke für Operator-Intent. Sie ersetzen aber nicht:

• Host-Härtung
• saubere Rechte auf Dateien und Diensten
• Trennung von Test- und Produktiv-Hosts
• Secret-Hygiene
• eine vernünftige Tool-Policy für Agenten selbst

Besonders wichtig: Berechtigungen, die eine IDE oder ein Editor-Harness zusätzlich zu OpenClaw durchsetzt — etwa ACPX-Permissions bei angebundenen Editoren — lösen Host-Exec nicht auf. Diese Ebenen bleiben strikt getrennt. Wenn ein Command trotz angepasster Harness-Permissions weiter fragt oder blockiert, musst du wieder auf openclaw approvals get und openclaw exec-policy show zurück.

Genauso wichtig ist die zweite Grenze: Elevated-Exec ist nicht einfach „noch ein bisschen mehr Erlaubnis“. Es läuft außerhalb der Sandbox, und Elevated full kann die normalen Exec-Approvals überspringen. Das ist eine bewusste Break-Glass-Funktion, keine Standard-Reparatur für nervige Prompts.

Betriebs-Checkliste

Vor einem länger laufenden Setup solltest du mindestens diese Punkte abarbeiten:

• Mit openclaw approvals get prüfen, welche effektive Policy lokal, auf dem Gateway und gegebenenfalls auf Nodes gilt.
• Mit openclaw exec-policy show kontrollieren, ob gewünschte Config und hostlokale Regel wirklich zusammenpassen.
• agents.defaults.sandbox.mode gegen die tatsächliche Session-Struktur prüfen, vor allem bei Gruppen-, Channel- und Nicht-Haupt-Sessions.
• askFallback prüfen, wenn Prompts ausbleiben oder Kommandos ohne sichtbare Freigabe direkt geblockt werden.
• Elevated-Exec nur als Ausnahme behandeln, weil es Sandboxing umgehen kann und Elevated full normale Approval-Sperren überspringen kann.
• Approval-Kanäle nur als Bedienoberfläche sehen, nicht als Source of Truth für die Host-Policy.

Fazit

Wenn du genau diese Trennung sauber einhältst, wirken /approve, Sandboxing und Host-Exec plötzlich nicht mehr widersprüchlich. Dann wird aus einem nervigen Sicherheitsdialog ein verständlicher Betriebsmechanismus.