exec es una superficie de shell mutante: los comandos pueden crear, editar o eliminar archivos donde lo permita el host seleccionado o el sistema de archivos del sandbox. Deshabilitar herramientas de sistema de archivos de OpenClaw como write, edit o apply_patch no hace que exec sea de solo lectura.
Admite ejecución en primer plano y en segundo plano mediante process. Si process no está permitido, exec se ejecuta de forma síncrona e ignora yieldMs/background. Las sesiones en segundo plano tienen alcance por agente; process solo ve sesiones del mismo agente.
Parámetros
Comando de shell que se ejecutará.
Directorio de trabajo para el comando.
Anulaciones de entorno de clave/valor combinadas sobre el entorno heredado.
Enviar automáticamente el comando a segundo plano después de este retraso (ms).
Enviar el comando a segundo plano inmediatamente en lugar de esperar
yieldMs.Anula el tiempo de espera de exec configurado para esta llamada, en segundos. Se aplica a la ejecución en primer plano, en segundo plano,
yieldMs, Gateway, sandbox y Node system.run. timeout: 0 deshabilita el tiempo de espera del proceso exec para esa llamada.Ejecutar en una pseudoterminal cuando esté disponible. Úsalo para CLI solo TTY, agentes de programación e interfaces de terminal.
Dónde ejecutar.
auto se resuelve como sandbox cuando hay un runtime de sandbox activo y como gateway en caso contrario.Se ignora para llamadas normales a herramientas. La seguridad de
gateway/node se controla mediante tools.exec.security y el archivo de aprobaciones del host; el modo elevado solo puede forzar security=full cuando el operador concede explícitamente acceso elevado.El modo de solicitud base proviene de
tools.exec.ask y de las aprobaciones del host. Para llamadas de modelo originadas en canales, el ask por llamada se ignora cuando la solicitud efectiva del host es off; de lo contrario, solo puede endurecerse a un modo más estricto. Los llamadores internos/API de confianza que construyen herramientas exec con un valor ask explícito no cambian.Id/nombre de Node cuando
host=node.Solicita modo elevado: salir del sandbox hacia la ruta de host configurada.
security=full se fuerza solo cuando elevated se resuelve como full.hostsolo aceptaauto,sandbox,gatewayonode. No es un selector de nombre de host; los valores con aspecto de nombre de host se rechazan antes de ejecutar el comando.- Se permite
host=nodepor llamada desdeauto;host=gatewaypor llamada solo se permite cuando no hay un runtime de sandbox activo. - Sin configuración adicional,
host=autosigue “funcionando sin más”: sin sandbox se resuelve comogateway; con un sandbox activo permanece en el sandbox. elevatedsale del sandbox hacia la ruta de host configurada:gatewayde forma predeterminada, onodecuandotools.exec.host=node(o el valor predeterminado de la sesión eshost=node). Solo está disponible cuando el acceso elevado está habilitado para la sesión/proveedor actual.- Las aprobaciones de
gateway/nodese controlan mediante el archivo de aprobaciones del host. noderequiere un nodo emparejado (aplicación complementaria o host de nodo sin interfaz). Si hay varios nodos disponibles, defineexec.nodeotools.exec.nodepara seleccionar uno.exec host=nodees la única ruta de ejecución de shell para nodos; se eliminó el wrapper heredadonodes.run.- En hosts que no son Windows, exec usa
SHELLcuando está definido; siSHELLesfish, prefierebash(osh) desdePATHpara evitar bashismos incompatibles con fish, y luego vuelve aSHELLsi ninguno existe. - En hosts Windows, exec prefiere descubrir PowerShell 7 (
pwsh) (Program Files, ProgramW6432 y luego PATH), y después vuelve a Windows PowerShell 5.1. - En hosts Gateway que no son Windows, los comandos exec de bash y zsh usan una instantánea de inicio. OpenClaw captura alias/funciones que se pueden cargar con source y un pequeño conjunto de entorno seguro desde los archivos de inicio del shell en
$OPENCLAW_STATE_DIR/cache/shell-snapshots/, y luego carga esa instantánea con source antes de cada comando exec. Las variables que parecen secretas se excluyen; exec en sandbox y node no usa esta instantánea. DefineOPENCLAW_EXEC_SHELL_SNAPSHOT=0en el entorno del proceso Gateway para deshabilitar esta ruta de instantánea. - La ejecución en host (
gateway/node) rechazaenv.PATHy anulaciones de cargador (LD_*/DYLD_*) para impedir el secuestro de binarios o código inyectado. - OpenClaw establece
OPENCLAW_SHELL=execen el entorno del comando generado (incluida la ejecución en PTY y sandbox) para que las reglas de shell/perfil puedan detectar el contexto de herramienta exec. - Para ejecuciones originadas en canales, OpenClaw también expone una carga JSON estrecha de identidad de remitente/chat en
OPENCLAW_CHANNEL_CONTEXTcuando el canal proporcionó esos ids. execno puede ejecutar comandos de shellopenclaw channels loginni/approve:openclaw channels logines un flujo interactivo de autenticación de canal, y/approvedebe pasar por el manejador de comandos de aprobación, no por un shell. Ejecuta el inicio de sesión de canal en una terminal en el host Gateway, o usa una herramienta de agente de inicio de sesión específica del canal cuando exista (por ejemplo,whatsapp_login).- Importante: el sandboxing está desactivado de forma predeterminada. Si el sandboxing está desactivado, el
host=autoimplícito se resuelve comogateway. Elhost=sandboxexplícito aún falla de forma cerrada en lugar de ejecutarse silenciosamente en el host Gateway. Habilita el sandboxing o usahost=gatewaycon aprobaciones. - Las comprobaciones previas de scripts (para errores comunes de sintaxis de shell en Python/Node) solo inspeccionan archivos dentro del límite efectivo de
workdir. Si una ruta de script se resuelve fuera deworkdir, se omite la comprobación previa para ese archivo. La comprobación previa también se omite por completo cuandohost=gatewayy la política efectiva essecurity=fullconask=off. - Para trabajo de larga duración que comienza ahora, inícialo una vez y confía en la reactivación automática al completarse cuando esté habilitada y el comando emita salida o falle. Usa
processpara registros, estado, entrada o intervención; no emules la programación con bucles de suspensión, bucles de tiempo de espera ni sondeos repetidos. - Para trabajo que deba ocurrir más tarde o según una programación, usa cron en lugar de patrones de suspensión/retraso con
exec.
Configuración
| Clave | Predeterminado | Notas |
|---|---|---|
tools.exec.timeoutSec | 1800 | Tiempo de espera exec predeterminado por comando, en segundos. El timeout por llamada lo anula; timeout: 0 por llamada deshabilita el tiempo de espera del proceso exec. |
tools.exec.host | auto | Se resuelve como sandbox cuando hay un runtime de sandbox activo, y como gateway en caso contrario. |
tools.exec.security | deny para sandbox, full para gateway/node cuando no está definido | |
tools.exec.ask | off | |
tools.exec.mode | sin definir | Perilla de política normalizada. Consulta Modos a continuación. No puede combinarse con tools.exec.security/tools.exec.ask. |
tools.exec.node | sin definir | |
tools.exec.notifyOnExit | true | Cuando es true, las sesiones exec enviadas a segundo plano encolan un evento del sistema y solicitan un Heartbeat al salir. |
tools.exec.approvalRunningNoticeMs | 10000 | Emite un único aviso de “en ejecución” cuando un exec bloqueado por aprobación se ejecuta durante más tiempo que esto (0 lo deshabilita). |
tools.exec.strictInlineEval | false | Consulta Evaluación en línea. |
tools.exec.commandHighlighting | false | Cuando es true, las solicitudes de aprobación pueden resaltar fragmentos de comando derivados del analizador en el texto del comando. Defínelo globalmente o por agente; no cambia la política de aprobación. |
tools.exec.pathPrepend | sin definir | Lista de directorios que se anteponen a PATH para ejecuciones exec (solo gateway + sandbox). |
tools.exec.safeBins | sin definir | Binarios seguros solo de stdin que pueden ejecutarse sin entradas explícitas en la lista de permitidos. Consulta Binarios seguros. |
tools.exec.safeBinTrustedDirs | /bin, /usr/bin | Directorios explícitos adicionales de confianza para las comprobaciones de ruta de safeBins. Las entradas de PATH nunca son de confianza automáticamente. |
tools.exec.safeBinProfiles | sin definir | Política argv personalizada opcional por binario seguro (minPositional, maxPositional, allowedValueFlags, deniedFlags). |
security=full, ask=off): esto proviene de los valores predeterminados de política de host, no de host=auto. Si quieres comportamiento de aprobaciones/lista de permitidos, endurece tanto tools.exec.* como el archivo de aprobaciones del host; consulta Aprobaciones de exec. Para forzar el enrutamiento de gateway o node sin importar el estado del sandbox, define tools.exec.host o usa /exec host=....
Ejemplo:
Modos
tools.exec.mode es la perilla de política normalizada. Al definirla, deriva security/ask y no puede combinarse con tools.exec.security/tools.exec.ask.
| Modo | security | ask | Comportamiento |
|---|---|---|---|
deny | deny | off | Exec se deniega. |
allowlist | allowlist | off | Solo se ejecutan comandos incluidos en la lista de permitidos/safe-bin; no se pregunta nada más. |
ask | allowlist | on-miss | Las coincidencias de la lista de permitidos se ejecutan directamente; todo lo demás pregunta a un humano. |
auto | allowlist | on-miss | Las coincidencias de la lista de permitidos/safe-bin se ejecutan directamente; todo lo demás pasa por el revisor automático nativo de OpenClaw antes de preguntar a un humano. |
full | full | off | Sin puerta de aprobación. |
ask/ask=always sigue preguntando a un humano cada vez, independientemente del modo.
Eval en línea (strictInlineEval)
Cuando tools.exec.strictInlineEval es true, las formas de evaluación en línea de intérpretes requieren revisor o aprobación explícita: python -c, node -e, ruby -e, perl -e, php -r, lua -e, osascript -e y formas similares en otros intérpretes y transportadores de comandos admitidos (awk, find -exec, make, sed, xargs y más). En mode=auto, la ruta normal de aprobación de exec puede permitir que el revisor automático nativo autorice un comando puntual claramente de bajo riesgo; las llamadas directas system.run del host de nodo siguen requiriendo aprobación explícita porque no pueden entregar el comando a una ruta de aprobación humana. Si el revisor pregunta, la solicitud va a un humano. allow-always todavía puede persistir invocaciones benignas de intérpretes/scripts, pero las formas de eval en línea no se convierten en reglas de permiso duraderas.
Manejo de PATH
host=gateway: fusiona elPATHde tu shell de inicio de sesión en el entorno de exec. Las sobrescrituras deenv.PATHse rechazan para la ejecución en host. El daemon sigue ejecutándose con unPATHmínimo:- macOS:
/opt/homebrew/bin,/usr/local/bin,/usr/bin,/bin - Linux:
/usr/local/bin,/usr/bin,/bin - Para evitar que la configuración del shell del usuario (como
~/.zshenvo/etc/zshenv) sobrescriba rutas prioritarias durante el inicio, las entradas detools.exec.pathPrependse anteponen de forma segura alPATHfinal dentro del comando de shell justo antes de la ejecución.
- macOS:
host=sandbox: ejecutash -lc(shell de inicio de sesión) dentro del contenedor, por lo que/etc/profilepuede restablecerPATH. OpenClaw anteponeenv.PATHdespués de cargar el perfil mediante una variable de entorno interna (sin interpolación de shell);tools.exec.pathPrependtambién se aplica aquí.host=node: solo se envían al nodo las sobrescrituras de entorno no bloqueadas que pases. Las sobrescrituras deenv.PATHse rechazan para la ejecución en host y los hosts de nodo las ignoran. Si necesitas entradas de PATH adicionales en un nodo, configura el entorno del servicio del host de nodo (systemd/launchd) o instala herramientas en ubicaciones estándar.
Sobrescrituras de sesión (/exec)
Usa /exec para definir valores predeterminados por sesión para host, security, ask y node. Envía /exec sin argumentos para mostrar los valores actuales.
Ejemplo:
/exec solo se respeta para remitentes autorizados (listas de permitidos/emparejamiento de canales más commands.useAccessGroups). Actualiza solo el estado de la sesión y no escribe configuración. Los remitentes autorizados de canales externos pueden definir estos valores predeterminados de sesión. Los clientes internos de gateway/webchat necesitan operator.admin para persistirlos.
Para desactivar exec de forma estricta, deniégalo mediante la política de herramientas (tools.deny: ["exec"] o por agente). Las aprobaciones de host siguen aplicándose salvo que configures explícitamente security=full y ask=off.
Aprobaciones de exec (aplicación complementaria / host de nodo)
Los agentes en sandbox pueden requerir aprobación por solicitud antes de queexec se ejecute en el gateway o en el host de nodo. Consulta Aprobaciones de exec para ver la política, la lista de permitidos y el flujo de UI.
Cuando se requieren aprobaciones, la herramienta exec devuelve inmediatamente status: "approval-pending" y un id de aprobación. Una vez aprobado (o denegado / agotado el tiempo), el Gateway emite eventos de sistema de progreso y finalización del comando solo para ejecuciones aprobadas (Exec running / Exec finished). Las aprobaciones denegadas o vencidas son terminales y no despiertan la sesión del agente con un evento de sistema de denegación.
En canales con tarjetas/botones de aprobación nativos, el agente debe confiar primero en esa UI nativa e incluir un comando manual /approve solo cuando el resultado de la herramienta diga explícitamente que las aprobaciones por chat no están disponibles o que la aprobación manual es la única ruta.
Lista de permitidos + safe bins
La aplicación manual de la lista de permitidos compara globs de rutas binarias resueltas y globs de nombres de comando sin ruta. Los nombres sin ruta solo coinciden con comandos invocados mediante PATH, por lo querg puede coincidir con /opt/homebrew/bin/rg cuando el comando es rg, pero no con ./rg ni /tmp/rg.
Cuando security=allowlist, los comandos de shell se permiten automáticamente solo si cada segmento de la canalización está en la lista de permitidos o es un safe bin. El encadenamiento (;, &&, ||) y las redirecciones se rechazan en modo de lista de permitidos salvo que cada segmento de nivel superior satisfaga la lista de permitidos (incluidos los safe bins). Las redirecciones siguen sin estar admitidas. La confianza duradera de allow-always no omite esa regla: un comando encadenado sigue requiriendo que cada segmento de nivel superior coincida.
autoAllowSkills es una ruta de conveniencia separada en las aprobaciones de exec, no lo mismo que las entradas manuales de lista de permitidos de rutas. Para confianza explícita estricta, mantén autoAllowSkills desactivado.
Usa los dos controles para tareas distintas:
tools.exec.safeBins: filtros de flujo pequeños, solo stdin.tools.exec.safeBinTrustedDirs: directorios confiables adicionales explícitos para rutas de ejecutables safe-bin.tools.exec.safeBinProfiles: política argv explícita para safe bins personalizados.- lista de permitidos: confianza explícita para rutas de ejecutables.
safeBins como una lista de permitidos genérica, y no añadas binarios de intérpretes/runtimes (por ejemplo python3, node, ruby, bash). Si los necesitas, usa entradas explícitas de lista de permitidos y mantén activados los avisos de aprobación.
openclaw security audit advierte cuando a las entradas safeBins de intérpretes/runtimes les faltan perfiles explícitos, y openclaw doctor --fix puede generar un andamiaje para entradas safeBinProfiles personalizadas faltantes. openclaw security audit y openclaw doctor también advierten cuando añades explícitamente bins de comportamiento amplio como jq de vuelta a safeBins (jq admite programas y builtins amplios, así que prefiere entradas explícitas de lista de permitidos o ejecuciones con puerta de aprobación). Si incluyes intérpretes explícitamente en la lista de permitidos, activa tools.exec.strictInlineEval para que las formas de eval de código en línea sigan requiriendo revisor o aprobación explícita.
Para detalles completos de política y ejemplos, consulta Aprobaciones de exec y Safe bins frente a lista de permitidos.
Ejemplos
Primer plano:apply_patch
apply_patch es una subherramienta de exec para ediciones estructuradas de múltiples archivos. Está activada de forma predeterminada y disponible para cualquier proveedor de modelos; allowModels puede restringirla. Usa la configuración solo cuando quieras desactivarla o restringirla a modelos específicos:
- La política de herramientas sigue aplicándose;
allow: ["write"]permite implícitamenteapply_patch. deny: ["write"]no deniegaapply_patch; deniegaapply_patchexplícitamente o usadeny: ["group:fs"]cuando las escrituras de parches también deban bloquearse.- La configuración vive bajo
tools.exec.applyPatch. tools.exec.applyPatch.enabledtienetruecomo valor predeterminado; configúralo enfalsepara desactivar la herramienta.tools.exec.applyPatch.workspaceOnlytienetruecomo valor predeterminado (contenido en el espacio de trabajo). Configúralo enfalsesolo si quieres intencionalmente queapply_patchescriba/elimine fuera del directorio del espacio de trabajo.tools.exec.applyPatch.allowModelses una lista de permitidos opcional de ids de modelo (sin procesar, comogpt-5.4, o completos, comoopenai/gpt-5.4). Cuando se configura, solo los modelos coincidentes reciben la herramienta; cuando no se configura, todos los modelos la reciben.
Relacionado
- Aprobaciones de exec — puertas de aprobación para comandos de shell
- Sandboxing — ejecución de comandos en entornos en sandbox
- Proceso en segundo plano — exec de larga duración y herramienta de procesos
- Seguridad — política de herramientas y acceso elevado