Ir al contenido

Control de ejecución con exec.host: Seguridad y flexibilidad

Seguro que te ha pasado: quieres que tu agente ejecute un comando, pero te preocupa que termine rompiendo algo en tu sistema local o que no tenga los permisos necesarios dentro de un contenedor. Gestionar el lugar exacto donde corre el código y qué permisos tiene suele ser un proceso manual y propenso a errores.

Esta actualización del sistema de ejecución está diseñada para que decidas con precisión el entorno de cada tarea, manteniendo siempre la seguridad por defecto. Ya sea que necesites un entorno aislado o acceso directo al sistema, ahora tienes el control total.

  • Archivo de configuración de OpenClaw activo.
  • Un Node runner instalado (para ejecución en nodos remotos).
  • Acceso a ~/.openclaw/ para gestionar políticas locales.

Configura la ejecución en menos de 5 minutos siguiendo estos pasos. El sistema utiliza sandbox por defecto para que nada corra en tu máquina sin permiso explícito.

  1. Define el host global: En tu configuración, establece dónde quieres que se ejecuten los comandos normalmente.

    {
    "tools": {
    "exec": {
    "host": "sandbox",
    "security": "deny",
    "ask": "on-miss"
    }
    }
    }
  2. Usa el modo elevado: Si necesitas saltarte las restricciones temporalmente para un agente, usa el comando de barra: /elevated on Esto cambia el host a gateway y la security a full solo para la sesión actual.

  3. Configura un Node específico: Si quieres que un agente use un runner concreto, añade el nodeId: /exec host=node node=mi-laptop-personal

El sistema te permite elegir entre diferentes entornos de ejecución:

  • sandbox: Ejecución dentro de Docker (comportamiento estándar).
  • gateway: Ejecución directa en la máquina que aloja el Gateway.
  • node: Ejecución en un runner remoto a través de Bridge.

Para proteger estos entornos, aplicas uno de estos niveles de seguridad:

  • deny: Bloquea cualquier intento de ejecución.
  • allowlist: Solo permite comandos que coincidan con tus patrones definidos.
  • full: Permite todo (equivale al modo /elevated).

El parámetro ask determina cuándo el sistema debe pedirte permiso manual:

  • on-miss: Te pregunta solo si el comando no está en tu allowlist.
  • always: Te pide confirmación cada vez que se intenta ejecutar algo.
  • off: No pregunta nunca.

Toda la configuración de seguridad local se guarda en ~/.openclaw/exec-approvals.json. Este archivo es la fuente de verdad para el runner y tiene este formato:

{
"version": 1,
"defaults": {
"security": "deny",
"ask": "on-miss",
"askFallback": "deny"
},
"agents": {
"agent-id-1": {
"security": "allowlist",
"ask": "on-miss",
"allowlist": [
{
"pattern": "~/Projects/**/bin/rg",
"lastUsedAt": 0,
"lastUsedCommand": "rg -n TODO",
"lastResolvedPath": "/Users/user/Projects/.../bin/rg"
}
]
}
}
}
  • Ejecución denegada inesperadamente: Verifica que exec.security no esté en deny. Si usas allowlist, asegúrate de que el patrón en exec-approvals.json coincida exactamente con la ruta del binario.
  • La interfaz no muestra el prompt: Si la app de UI no está disponible, el sistema usa askFallback. Si este valor es deny, la petición fallará automáticamente.
  • Error de ambigüedad en Node: Si tienes varios nodos conectados y no has definido un nodeId o binding, el agente no sabrá a cuál dirigirse. Especifica el nodo en la configuración del agente.
  • Salida de comandos incompleta: El sistema limita el output combinado a 200k. Si tu comando genera más texto, verás un sufijo (truncated) y solo se conservarán los últimos 20k para los eventos.

Para resolver dudas específicas sobre tu configuración, consulta al AI Setup Assistant.

OpenClaw

OpenClaw Expert

Sigues atascado?

Si esta pagina no resolvio tu caso, pregunta a OpenClaw Expert para pasos concretos.