Exec tool
기준일: 2026-07-26
난이도: 중급
공식 기준: Exec tool
개요
이 페이지는 OpenClaw Exec tool 도구(파라미터, 권한, 설정, CLI)를 공식 문서 기준으로 정리합니다.
공식 요약: Exec tool usage, stdin modes, and TTY support
도구 가시성은 profile / allow·deny policy / sandbox / channel 권한에 따라 달라집니다. 최신 스키마는 항상 공식 문서를 우선합니다.
공식 문서 기반 상세
아래는 공식 tools/exec 문서를 정리한 내용입니다. 코드 블록, 파라미터 이름, 기본값은 원문 그대로입니다.
Run shell commands in the workspace. exec is a mutating shell surface: commands can create, edit, or delete files wherever the selected host or sandbox filesystem permits. Disabling OpenClaw filesystem tools such as write, edit, or apply_patch does not make exec read-only.
Supports foreground and background execution via process. If process is disallowed, exec runs synchronously and ignores yieldMs/background. Background sessions are scoped per agent; process only sees sessions from the same agent.
파라미터
command(string) (required): Shell command to run.workdir(string) · default:cwd: Working directory for the command.env(object): Key/value environment overrides merged on top of the inherited environment.yieldMs(number) · default:10000: Auto-background the command after this delay (ms).background(boolean) · default:false: Background the command immediately instead of waiting foryieldMs.timeout(number) · default:tools.exec.timeoutSeconds: Override the configured exec timeout for this call, in seconds. Applies to foreground, background,yieldMs, gateway, sandbox, and nodesystem.runexecution.timeout: 0disables the exec process timeout for that call.pty(boolean) · default:false: Run in a pseudo-terminal when available. Use for TTY-only CLIs, coding agents, and terminal UIs.host('auto' | 'sandbox' | 'gateway' | 'node') · default:auto: Where to execute.autoresolves tosandboxwhen a sandbox runtime is active andgatewayotherwise.security('deny' | 'allowlist' | 'full'): Ignored for normal tool calls.gateway/nodesecurity is derived fromtools.exec.modeand the host approvals file; elevated mode can force full access only when the operator explicitly grants elevated access.ask('off' | 'on-miss' | 'always'): The baseline ask mode is derived fromtools.exec.modeand host approvals. For channel-origin model calls, per-callaskis ignored when the effective host ask isoff; otherwise it can only harden to a stricter mode.node(string): Node id/name whenhost=node.elevated(boolean) · default:false: Request elevated mode: escape the sandbox onto the configured host path.security=fullis forced only when elevated resolves tofull.
Notes:
hostonly acceptsauto,sandbox,gateway, ornode. It is not a hostname selector; hostname-like values are rejected before the command runs.- Per-call
host=nodeis allowed fromauto; per-callhost=gatewayis only allowed when no sandbox runtime is active. - With no extra config,
host=autostill "just works": no sandbox means it resolves togateway; a live sandbox means it stays in the sandbox. elevatedescapes the sandbox onto the configured host path:gatewayby default, ornodewhentools.exec.host=node(or the session default ishost=node). It is only available when elevated access is enabled for the current session/provider.gateway/nodeapprovals are controlled by the host approvals file.noderequires a paired node (companion app or headless node host). If multiple nodes are available, setexec.nodeortools.exec.nodeto select one.exec host=nodeis the only shell-execution path for nodes; the legacynodes.runwrapper has been removed.- On non-Windows hosts, exec uses
SHELLwhen set; ifSHELLisfish, it prefersbash(orsh) fromPATHto avoid fish-incompatible bashisms, then falls back toSHELLif neither exists. - On Windows hosts, exec prefers PowerShell 7 (
pwsh) discovery (Program Files, ProgramW6432, then PATH), then falls back to Windows PowerShell 5.1. - On non-Windows gateway hosts, bash and zsh exec commands use a startup snapshot. OpenClaw captures sourceable aliases/functions and a small safe environment set from shell startup files into
$OPENCLAW_STATE_DIR/cache/shell-snapshots/, then sources that snapshot before each exec command. Secret-looking variables are excluded; sandbox and node exec do not use this snapshot. SetOPENCLAW_EXEC_SHELL_SNAPSHOT=0in the Gateway process environment to disable this snapshot path. - Host execution (
gateway/node) rejectsenv.PATHand loader overrides (LD_*/DYLD_*) to prevent binary hijacking or injected code. - OpenClaw sets
OPENCLAW_SHELL=execin the spawned command environment (including PTY and sandbox execution) so shell/profile rules can detect exec-tool context. - For channel-origin runs, OpenClaw also exposes a narrow sender/chat identity JSON payload in
OPENCLAW_CHANNEL_CONTEXTwhen the channel provided those ids. execcannot runopenclaw channels loginor/approveshell commands:openclaw channels loginis an interactive channel-auth flow, and/approveneeds to go through the approval command handler, not a shell. Run channel login in a terminal on the gateway host, or use a channel-specific login agent tool when one exists (for examplewhatsapp_login).- Important: sandboxing is off by default. If sandboxing is off, implicit
host=autoresolves togateway. Explicithost=sandboxstill fails closed instead of silently running on the gateway host. Enable sandboxing or usehost=gatewaywith approvals. - Script preflight checks (for common Python/Node shell-syntax mistakes) only inspect files inside the effective
workdirboundary. If a script path resolves outsideworkdir, preflight is skipped for that file. Preflight also skips entirely whenhost=gatewayand the effective policy issecurity=fullwithask=off. - For long-running work that starts now, start it once and rely on automatic completion wake when it is enabled and the command emits output or fails. Use
processfor logs, status, input, or intervention; do not emulate scheduling with sleep loops, timeout loops, or repeated polling. - Agent-started background commands appear in the Web, iOS, and Android background-task views until they finish. The task ledger is finalized before the completion heartbeat wakes the agent again.
- For work that should happen later or on a schedule, use cron instead of
execsleep/delay patterns.
Config
| Key | Default | Notes |
|---|---|---|
tools.exec.timeoutSeconds |
1800 |
Default per-command exec timeout in seconds. Per-call timeout overrides it; per-call timeout: 0 disables the exec process timeout. |
tools.exec.host |
auto |
Resolves to sandbox when a sandbox runtime is active, gateway otherwise. |
tools.exec.mode |
host-derived | Canonical policy knob. See Modes below. |
tools.exec.reviewer.model |
configured agent primary | Optional provider/model override for mode=auto review. |
tools.exec.reviewer.timeoutMs |
30000 |
Per-stage timeout for reviewer model preparation and completion before human fallback. |
tools.exec.node |
unset | |
tools.exec.notifyOnExit |
true |
When true, backgrounded exec sessions enqueue a system event and request a heartbeat on exit. |
tools.exec.approvalRunningNoticeMs |
10000 |
Emit a single "running" notice when an approval-gated exec runs longer than this (0 disables). |
tools.exec.strictInlineEval |
false |
See Inline eval. |
tools.exec.commandHighlighting |
false |
When true, approval prompts can highlight parser-derived command spans in the command text. Set globally or per agent; does not change approval policy. |
tools.exec.pathPrepend |
unset | List of directories to prepend to PATH for exec runs (gateway + sandbox only). |
tools.exec.safeBins |
unset | Stdin-only safe binaries that can run without explicit allowlist entries. See Safe bins. |
tools.exec.safeBinTrustedDirs |
/bin, /usr/bin |
Additional explicit directories trusted for safeBins path checks. PATH entries are never auto-trusted. |
tools.exec.safeBinProfiles |
unset | Optional custom argv policy per safe bin (minPositional, maxPositional, allowedValueFlags, deniedFlags). |
No-approval host exec is the default for gateway and node (mode=full) — this comes from the host-policy defaults, not from host=auto. If you want approvals/allowlist behavior, set tools.exec.mode and tighten the host approvals file; see Exec approvals. To force gateway or node routing regardless of sandbox state, set tools.exec.host or use /exec host=....
Example:
{
tools: {
exec: {
pathPrepend: ["~/bin", "/opt/oss/bin"],
},
},
}
Modes
tools.exec.mode is the canonical persisted policy knob. Runtime security and approval behavior are derived from it.
| Mode | security | ask | Behavior |
|---|---|---|---|
deny |
deny |
off |
Exec is denied. |
allowlist |
allowlist |
off |
Only allowlisted/safe-bin commands run; nothing else is asked. |
ask |
allowlist |
on-miss |
Allowlist matches run directly; everything else asks a human. |
auto |
allowlist |
on-miss |
Allowlist/safe-bin matches run directly; everything else routes through OpenClaw's native auto reviewer before asking a human. |
full |
full |
off |
No approval gate. |
Per-session /exec ask=always still asks a human every time regardless of the persisted mode.
Auto-review approval is single-use. On the gateway, OpenClaw supplies the resolved executable path to the reviewer and pins execution to that same path. Commands that cannot be reduced to one enforceable execution plan—such as heredocs, shell expansions, or unsupported wrapper quoting—fall back to human approval even if the model would otherwise allow them.
Codex app-server command approvals that are not already decided by explicit runtime or native policy use the human approval route. OpenClaw does not run its configured exec reviewer for these requests because Codex does not expose an enforceable resolved executable that can bind the review decision to the command Codex runs.
Inline eval (strictInlineEval)
When tools.exec.strictInlineEval is true, inline interpreter-eval forms require reviewer or explicit approval: python -c, node -e, ruby -e, perl -e, php -r, lua -e, osascript -e, and similar forms across other supported interpreters and command carriers (awk, find -exec, make, sed, xargs, and more). In mode=auto, the normal exec approval path may let the native auto reviewer allow a clearly low-risk one-off command; direct node-host system.run calls still require an explicit approval because they cannot hand the command to a human approval route. If the reviewer asks, the request goes to a human. allow-always can still persist benign interpreter/script invocations, but inline-eval forms do not become durable allow rules.
PATH handling
host=gateway: merges your login-shellPATHinto the exec environment.env.PATHoverrides are rejected for host execution. The daemon itself still runs with a minimalPATH:- macOS:
/opt/homebrew/bin,/usr/local/bin,/usr/bin,/bin - Linux:
/usr/local/bin,/usr/bin,/bin - To prevent user shell configuration (like
~/.zshenvor/etc/zshenv) from overriding priority paths during startup,tools.exec.pathPrependentries are securely prepended to the finalPATHinside the shell command right before execution.
- macOS:
host=sandbox: runssh -lc(login shell) inside the container, so/etc/profilemay resetPATH. OpenClaw prependsenv.PATHafter profile sourcing via an internal env var (no shell interpolation);tools.exec.pathPrependapplies here too.host=node: only non-blocked env overrides you pass are sent to the node.env.PATHoverrides are rejected for host execution and ignored by node hosts. If you need additional PATH entries on a node, configure the node host service environment (systemd/launchd) or install tools in standard locations.
Per-agent node binding (use the keyed agent ID in config):
openclaw config get agents.entries
openclaw config set 'agents.entries.main.tools.exec.node' "node-id-or-name"
Control UI: the Devices page includes a small "Exec node binding" panel for the same settings.
Session overrides (/exec)
Use /exec to set per-session defaults for host, security, ask, and node. Send /exec with no arguments to show the current values.
Example:
/exec host=auto security=allowlist ask=on-miss node=mac-1
/exec is only honored for authorized senders through channel allowlists/pairing and access groups. Access-group enforcement is always on. It updates session state only and does not write config. Authorized external channel senders may set these session defaults. Internal gateway/webchat clients need operator.admin to persist them.
To hard-disable exec, deny it via tool policy (tools.deny: ["exec"] or per-agent). Host approvals still apply unless you explicitly set security=full and ask=off.
Exec approvals (companion app / node host)
Sandboxed agents can require per-request approval before exec runs on the gateway or node host. See Exec approvals for the policy, allowlist, and UI flow.
When a human approval is required, node-host and non-native gateway flows return immediately with status: "approval-pending" and an approval id. Native chat and Web UI gateway flows can instead wait inline and return the final command result after approval. An approval-pending result means the command has not started, so foreground fallback warnings appear only if the approved command actually runs inline. Approved asynchronous runs emit command progress and completion system events (Exec running / Exec finished); denied or timed-out approvals are terminal and do not wake the agent session with a denial system event.
On channels with native approval cards/buttons, the agent should rely on that native UI first and only include a manual /approve command when the tool result explicitly says chat approvals are unavailable or manual approval is the only path.
Allowlist + safe bins
Manual allowlist enforcement matches resolved binary path globs and bare command-name globs. Bare names match only commands invoked through PATH, so rg can match /opt/homebrew/bin/rg when the command is rg, but not ./rg or /tmp/rg.
When security=allowlist, shell commands are auto-allowed only if every pipeline segment is allowlisted or a safe bin. Chaining (;, &&, ||) and redirections are rejected in allowlist mode unless every top-level segment satisfies the allowlist (including safe bins). Redirections remain unsupported. Durable allow-always trust does not bypass that rule: a chained command still requires every top-level segment to match.
autoAllowSkills is a separate convenience path in exec approvals, not the same as manual path allowlist entries. For strict explicit trust, keep autoAllowSkills disabled.
Use the two controls for different jobs:
tools.exec.safeBins: small, stdin-only stream filters.tools.exec.safeBinTrustedDirs: explicit extra trusted directories for safe-bin executable paths.tools.exec.safeBinProfiles: explicit argv policy for custom safe bins.- allowlist: explicit trust for executable paths.
Do not treat safeBins as a generic allowlist, and do not add interpreter/runtime binaries (for example python3, node, ruby, bash). If you need those, use explicit allowlist entries and keep approval prompts enabled.
openclaw security audit warns when interpreter/runtime safeBins entries are missing explicit profiles, and openclaw doctor --fix can scaffold missing custom safeBinProfiles entries. openclaw security audit and openclaw doctor also warn when you explicitly add broad-behavior bins such as jq back into safeBins (jq can read environment data and load jq code from modules or startup files, so prefer explicit allowlist entries or approval-gated runs instead). jq is denied as a safe bin even when it is explicitly listed. If you explicitly allowlist interpreters, enable tools.exec.strictInlineEval so inline code-eval forms still require reviewer or explicit approval.
For full policy details and examples, see Exec approvals and Safe bins versus allowlist.
예시
Foreground:
{ "tool": "exec", "command": "ls -la" }
Background + poll:
{"tool":"exec","command":"npm run build","yieldMs":1000}
{"tool":"process","action":"poll","sessionId":"<id>"}
Polling is for on-demand status, not waiting loops. If automatic completion wake is enabled, the command can wake the session when it emits output or fails.
Send keys (tmux-style):
{"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 (send CR only):
{ "tool": "process", "action": "submit", "sessionId": "<id>" }
Paste (bracketed by default):
{ "tool": "process", "action": "paste", "sessionId": "<id>", "text": "line1\nline2\n" }
apply_patch
apply_patch is a subtool of exec for structured multi-file edits. It is enabled by default and available to any model provider; allowModels can restrict it. Use config only when you want to disable it or restrict it to specific models:
{
tools: {
exec: {
applyPatch: { workspaceOnly: true, allowModels: ["gpt-5.6-sol"] },
},
},
}
Notes:
- Tool policy still applies;
allow: ["write"]implicitly allowsapply_patch. deny: ["write"]does not denyapply_patch; denyapply_patchexplicitly or usedeny: ["group:fs"]when patch writes should also be blocked.- Config lives under
tools.exec.applyPatch. tools.exec.applyPatch.enableddefaults totrue; set it tofalseto disable the tool.tools.exec.applyPatch.workspaceOnlydefaults totrue(workspace-contained). Set it tofalseonly if you intentionally wantapply_patchto write/delete outside the workspace directory.tools.exec.applyPatch.allowModelsis an optional allowlist of model ids (raw, likegpt-5.4, or full, likeopenai/gpt-5.4). When set, only matching models get the tool; when unset, all models get it.
관련 문서
- Exec Approvals — approval gates for shell commands
- Sandboxing — running commands in sandboxed environments
- Background Process — long-running exec and process tool
- Security — tool policy and elevated access
검증 체크리스트
- 해당 tool이 활성 profile/policy에서 허용되는지 확인
- sandbox / elevated / host 실행 경로 정책을 이해했는지 확인
- 채널·에이전트 권한과 충돌하지 않는지 확인
- 공식 CLI/
--help와 문서 옵션이 버전과 맞는지 확인