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

Wenn OpenClaw in einem produktiven Setup ploetzlich /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 am Ende ausfuehren soll.

Das ist der Punkt, an dem viele Setups kippen: Im Chat wirkt alles wie ein einziger Schalter, technisch sind es aber getrennte Sicherheitslagen. Die OpenClaw-Doku ist an dieser Stelle klar. Sandboxing begrenzt den Blast Radius von Tool-Ausfuehrung, Exec-Approvals kontrollieren Host-Befehle, und die effektive Policy ist immer die strengere Kombination aus OpenClaw-Konfiguration und hostlokaler Approval-Regel. 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 ploetzlich 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-Ausfuehrung wie exec, read, write, edit, apply_patch oder process innerhalb einer isolierten Laufzeit.
• Exec-Approvals greifen erst dann, wenn ein gesandboxter Agent auf einem echten Host ausfuehren will, also auf gateway oder node.
• Chat-Approvals sind nur die Bedienoberflaeche für Freigaben. Die eigentliche Entscheidung faellt lokal auf dem Ausfuehrungshost.

Das ist der wichtigste mentale Fix: /approve ist kein allgemeiner OpenClaw-Panikschalter. Es ist nur ein sichtbares Symptom dafuer, dass ein Host-Befehl zusaetzliche Freigabe braucht.

Sandboxing begrenzt Werkzeuge, nicht den ganzen Gateway

Die Doku beschreibt Sandboxing als 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 die eigentliche Tool-Ausfuehrung.

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 und nutzt standardmaessig ein eigenes Docker-Netz statt des globalen bridge.

Für viele Troubleshooting-Faelle ist der Modus entscheidend. Laut Doku steuert agents.defaults.sandbox.mode, wann ueberhaupt 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. Die Doku ordnet den Modus 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 laut Doku 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 fuehlt sich dasselbe Setup auf zwei Maschinen manchmal widerspruechlich an. Die Freigabe lebt nicht nur in der Chat-Oberflaeche und auch nicht nur in der JSON-Konfiguration. Der lokale Approval-Zustand auf dem Ausfuehrungshost zählt mit.

Die Doku nennt noch eine zweite harte Grenze: Exec-Approvals sind kein Mehrbenutzer-Schutz und keine Read-only-Isolation. Sobald ein Host-Befehl genehmigt ist, kann er Dateien im Rahmen der gewaehlten Host- oder Sandbox-Rechte ändern. Wer “Approvals aktiv” mit “damit kann nichts passieren” verwechselt, baut sich nur ein falsches Sicherheitsgefuehl.

Diagnose: Welche Policy gilt wirklich?

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

1. Erwartung klaeren

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?
• 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

Die Doku empfiehlt dafuer zwei Kommandos:

openclaw approvals get
openclaw exec-policy show

Damit bekommst du nicht nur die gewuenschte Policy aus tools.exec.*, sondern auch die hostseitige Regel und das zusammengefuehrte 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 gewuenschten 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 standardmaessig auf den lokalen Host. Für verteilte Setups ist das oft die falsche Stelle. Die CLI-Doku nennt dafuer die 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 ausfuehrt.

4. 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 dafuer existiert die zweite Sicherung. Umgekehrt bedeutet ein entspanntes Host-Approval nicht, dass Sandboxing ploetzlich aus ist. Beide Ebenen loesen unterschiedliche Probleme.

Welche Modi für Host-Exec sinnvoll sind

Die Permission-Modes-Doku fasst die typischen Ziele recht sauber zusammen:

• 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 ggf. Menschen fragen
• full: Host-Exec ohne Approval-Stopps

Für die meisten produktiven Setups ist allowlist oder ask der vernuenftigere Start. full ist kein Bug, aber eine bewusste Vertrauensentscheidung. Die Doku sagt explizit: 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 laut CLI-Doku 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. Die CLI-Doku sieht genau dafuer Allowlist-Helper vor.

3. 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.

4. Ask-Fallback ernst nehmen

Die Exec-Approvals-Doku nennt als Default für fehlende UI-Freigaben einen deny-basierten Fallback. Wenn keine Companion-App oder kein passender Approval-Kanal verfuegbar ist, bleibt der Befehl also häufig konsequent geblockt. Dann hilft keine Diskussion über Chat-Reaktionen; du brauchst eine erreichbare Freigabestrecke oder eine passend konfigurierte Host-Policy.

Reality Check für echte Betriebsfragen

Bevor du Approvals “entschaerfst”, 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 Ausfuehrungshost personengebunden und vertraut, oder hängt dort mehr Infrastruktur dran?
• Kannst du im Fehlerfall sehen, welcher Host einen Befehl ausgefuehrt hat?
• Weisst du, ob ein Block von Sandboxing, Exec-Approvals oder Chat-Freigabe stammt?

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

Was Exec-Approvals nicht für dich loesen

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

• Host-Haertung
• saubere Rechte auf Dateien und Diensten
• Trennung von Test- und Produktiv-Hosts
• Secret-Hygiene
• eine vernuenftige Tool-Policy für Agenten selbst

Besonders wichtig: ACPX- oder Harness-Permissions loesen Host-Exec nicht auf. Die Permission-Modes-Doku trennt diese Ebenen ausdruecklich. 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.

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 gewuenschte 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.
• Elevated-Exec nur als Ausnahme behandeln, weil laut Doku full die Approval-Sperre ueberspringen kann.
• Approval-Kanäle nur als Bedienoberflaeche sehen, nicht als Source of Truth für die Host-Policy.

Wenn du genau diese Trennung sauber einhältst, wirken /approve, Sandboxing und Host-Exec ploetzlich nicht mehr widerspruechlich. Dann wird aus einem nervigen Sicherheitsdialog ein verstaendlicher Betriebsmechanismus.