Exec-Tool
Shell-Befehle im Workspace ausführen. Unterstützt Vordergrund- + Hintergrundausführung über process.
Wenn process nicht erlaubt ist, läuft exec synchron und ignoriert yieldMs/background.
Hintergrundsitzungen sind pro Agent begrenzt; process sieht nur Sitzungen des gleichen Agenten.
Parameter
command(erforderlich)workdir(Standard: cwd)env(Key/Value-Überschreibungen)yieldMs(Standard 10000): nach Verzögerung automatisch in den Hintergrundbackground(bool): sofort in den Hintergrundtimeout(Sekunden, Standard 1800): bei Ablauf beendenpty(bool): in einem Pseudo-Terminal ausführen, wenn verfügbar (TTY-only CLIs, Coding-Agenten, Terminal-UIs)host(sandbox | gateway | node): wo ausgeführt wirdsecurity(deny | allowlist | full): Durchsetzungsmodus fürgateway/nodeask(off | on-miss | always): Genehmigungsprompts fürgateway/nodenode(string): Node-ID/Name fürhost=nodeelevated(bool): Elevated-Modus anfordern (Gateway-Host);security=fullwird nur erzwungen, wenn Elevated zufullaufgelöst wird
Hinweise:
hostist standardmäßigsandbox.elevatedwird ignoriert, wenn Sandboxing aus ist (Exec läuft bereits auf dem Host).gateway/node-Genehmigungen werden durch~/.openclaw/exec-approvals.jsongesteuert.nodeerfordert einen gepaarten Node (Companion App oder Headless Node Host).- Wenn mehrere Nodes verfügbar sind, setze
exec.nodeodertools.exec.node, um einen auszuwählen. - Auf Nicht-Windows-Hosts verwendet Exec
SHELL, wenn gesetzt; wennSHELLfishist, bevorzugt esbash(odersh) ausPATH, um fish-inkompatible Skripte zu vermeiden, und fällt dann aufSHELLzurück, wenn keines existiert. - Auf Windows-Hosts bevorzugt Exec PowerShell 7 (
pwsh) Discovery (Program Files, ProgramW6432, dann PATH), dann Fallback auf Windows PowerShell 5.1. - Host-Ausführung (
gateway/node) lehntenv.PATHund Loader-Überschreibungen (LD_*/DYLD_*) ab, um Binary-Hijacking oder injizierten Code zu verhindern. - OpenClaw setzt
OPENCLAW_SHELL=execin der Umgebung des gespawnten Befehls (einschließlich PTY- und Sandbox-Ausführung), damit Shell-/Profil-Regeln den Exec-Tool-Kontext erkennen können. - Wichtig: Sandboxing ist standardmäßig aus. Wenn Sandboxing aus ist und
host=sandboxexplizit konfiguriert/angefordert wird, schlägt Exec jetzt geschlossen fehl, anstatt stillschweigend auf dem Gateway-Host zu laufen. Aktiviere Sandboxing oder verwendehost=gatewaymit Genehmigungen. - Script-Preflight-Checks (für häufige Python/Node-Shell-Syntaxfehler) inspizieren nur Dateien innerhalb der
effektiven
workdir-Grenze. Wenn ein Script-Pfad außerhalb vonworkdiraufgelöst wird, wird der Preflight für diese Datei übersprungen.
Konfiguration
tools.exec.notifyOnExit(Standard: true): wenn true, reihen beendete Hintergrund-Exec-Sitzungen ein Systemereignis ein und fordern einen Heartbeat an.tools.exec.approvalRunningNoticeMs(Standard: 10000): einmalige „running”-Benachrichtigung senden, wenn ein genehmigungsgesteuerter Exec länger als dies läuft (0 deaktiviert).tools.exec.host(Standard:sandbox)tools.exec.security(Standard:denyfür Sandbox,allowlistfür Gateway + Node wenn nicht gesetzt)tools.exec.ask(Standard:on-miss)tools.exec.node(Standard: nicht gesetzt)tools.exec.pathPrepend: Liste von Verzeichnissen, diePATHfür Exec-Läufe vorangestellt werden (nur Gateway + Sandbox).tools.exec.safeBins: Stdin-only Safe Binaries, die ohne explizite Allowlist-Einträge laufen können. Für Verhaltensdetails siehe Safe Bins.tools.exec.safeBinTrustedDirs: Zusätzliche explizite Verzeichnisse, die fürsafeBins-Pfadprüfungen als vertrauenswürdig gelten.PATH-Einträge werden nie automatisch als vertrauenswürdig eingestuft. Eingebaute Standards sind/binund/usr/bin.tools.exec.safeBinProfiles: Optionale benutzerdefinierte argv-Policy pro Safe Bin (minPositional,maxPositional,allowedValueFlags,deniedFlags).
Beispiel:
{
tools: {
exec: {
pathPrepend: ["~/bin", "/opt/oss/bin"],
},
},
}
PATH-Behandlung
host=gateway: mergt dein Login-Shell-PATHin die Exec-Umgebung.env.PATH-Überschreibungen werden für Host-Ausführung abgelehnt. Der Daemon selbst läuft mit minimalemPATH:- macOS:
/opt/homebrew/bin,/usr/local/bin,/usr/bin,/bin - Linux:
/usr/local/bin,/usr/bin,/bin
- macOS:
host=sandbox: führtsh -lc(Login-Shell) im Container aus, sodass/etc/profilePATHzurücksetzen kann. OpenClaw stelltenv.PATHnach Profile-Sourcing über eine interne Env-Variable voran (keine Shell-Interpolation);tools.exec.pathPrependgilt hier ebenfalls.host=node: nur nicht-blockierte Env-Überschreibungen, die du übergibst, werden an den Node gesendet.env.PATH-Überschreibungen werden für Host-Ausführung abgelehnt und von Node Hosts ignoriert. Wenn du zusätzliche PATH-Einträge auf einem Node benötigst, konfiguriere die Node-Host-Service-Umgebung (systemd/launchd) oder installiere Tools an Standard-Orten.
Pro-Agent Node-Bindung (verwende den Agent-Listen-Index in der Konfiguration):
openclaw config get agents.list
openclaw config set agents.list[0].tools.exec.node "node-id-or-name"
Control UI: Der Nodes-Tab enthält ein kleines „Exec Node Binding”-Panel für die gleichen Einstellungen.
Sitzungsüberschreibungen (/exec)
Verwende /exec, um pro-Sitzungs-Standardwerte für host, security, ask und node zu setzen.
Sende /exec ohne Argumente, um die aktuellen Werte anzuzeigen.
Beispiel:
/exec host=gateway security=allowlist ask=on-miss node=mac-1
Autorisierungsmodell
/exec wird nur für autorisierte Absender berücksichtigt (Kanal-Allowlists/Pairing plus commands.useAccessGroups).
Es aktualisiert nur den Sitzungsstatus und schreibt keine Konfiguration. Um Exec hart zu deaktivieren, verweigere es über Tool-
Policy (tools.deny: ["exec"] oder pro-Agent). Host-Genehmigungen gelten weiterhin, es sei denn, du setzt explizit
security=full und ask=off.
Exec-Genehmigungen (Companion App / Node Host)
Gesandboxte Agenten können eine pro-Anfrage-Genehmigung erfordern, bevor exec auf dem Gateway- oder Node-Host läuft.
Siehe Exec-Genehmigungen für die Policy, Allowlist und den UI-Flow.
Wenn Genehmigungen erforderlich sind, kehrt das Exec-Tool sofort mit
status: "approval-pending" und einer Genehmigungs-ID zurück. Nach Genehmigung (oder Ablehnung / Timeout)
sendet das Gateway Systemereignisse (Exec finished / Exec denied). Wenn der Befehl noch
nach tools.exec.approvalRunningNoticeMs läuft, wird eine einmalige Exec running-Benachrichtigung gesendet.
Allowlist + Safe Bins
Manuelle Allowlist-Durchsetzung matcht nur aufgelöste Binary-Pfade (keine Basename-Matches). Wenn
security=allowlist, werden Shell-Befehle nur automatisch erlaubt, wenn jedes Pipeline-Segment
allowlisted oder ein Safe Bin ist. Verkettung (;, &&, ||) und Umleitungen werden im
Allowlist-Modus abgelehnt, es sei denn, jedes Top-Level-Segment erfüllt die Allowlist (einschließlich Safe Bins).
Umleitungen bleiben nicht unterstützt.
autoAllowSkills ist ein separater Komfortpfad in Exec-Genehmigungen. Er ist nicht dasselbe wie
manuelle Pfad-Allowlist-Einträge. Für striktes explizites Vertrauen halte autoAllowSkills deaktiviert.
Verwende die beiden Steuerungen für verschiedene Aufgaben:
tools.exec.safeBins: kleine, stdin-only Stream-Filter.tools.exec.safeBinTrustedDirs: explizite zusätzliche vertrauenswürdige Verzeichnisse für Safe-Bin-Executable-Pfade.tools.exec.safeBinProfiles: explizite argv-Policy für benutzerdefinierte Safe Bins.- Allowlist: explizites Vertrauen für Executable-Pfade.
Behandle safeBins nicht als generische Allowlist und füge keine Interpreter/Runtime-Binaries hinzu (zum Beispiel python3, node, ruby, bash). Wenn du diese brauchst, verwende explizite Allowlist-Einträge und halte Genehmigungsprompts aktiviert.
openclaw security audit warnt, wenn Interpreter/Runtime-safeBins-Einträge ohne explizite Profile vorhanden sind, und openclaw doctor --fix kann fehlende benutzerdefinierte safeBinProfiles-Einträge scaffolden.
Für vollständige Policy-Details und Beispiele siehe Exec-Genehmigungen und Safe Bins versus Allowlist.
Beispiele
Vordergrund:
{ "tool": "exec", "command": "ls -la" }
Hintergrund + Polling:
{"tool":"exec","command":"npm run build","yieldMs":1000}
{"tool":"process","action":"poll","sessionId":"<id>"}
Keys senden (tmux-Stil):
{"tool":"process","action":"send-keys","sessionId":"<id>","keys":["Enter"]}
{"tool":"process","action":"send-keys","sessionId":"<id>","keys":["C-c"]}
{"tool":"process","action":"send-keys","sessionId":"<id>","keys":["Up","Up","Enter"]}
Submit (nur CR senden):
{ "tool": "process", "action": "submit", "sessionId": "<id>" }
Einfügen (standardmäßig mit Bracket):
{ "tool": "process", "action": "paste", "sessionId": "<id>", "text": "line1\nline2\n" }
apply_patch (experimentell)
apply_patch ist ein Untertool von exec für strukturierte Multi-Datei-Bearbeitungen.
Explizit aktivieren:
{
tools: {
exec: {
applyPatch: { enabled: true, workspaceOnly: true, allowModels: ["gpt-5.2"] },
},
},
}
Hinweise:
- Nur für OpenAI/OpenAI Codex-Modelle verfügbar.
- Tool-Policy gilt weiterhin;
allow: ["exec"]erlaubt implizit auchapply_patch. - Konfiguration liegt unter
tools.exec.applyPatch. tools.exec.applyPatch.workspaceOnlyist standardmäßigtrue(auf Workspace beschränkt). Setze es nur auffalse, wenn du bewusst möchtest, dassapply_patchaußerhalb des Workspace-Verzeichnisses schreibt/löscht.