#Sub agente se niega a instalar skills

1 messages · Page 1 of 1 (latest)

shell valveBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

limber treeBOT
#

Esto suena a dos cosas distintas que a veces se confunden:

  1. Sub-agents (subagentes) no son “otro agente completo”: por diseño corren con un system prompt “minimal” y NO reciben la sección de Skills en el prompt. O sea: aunque tengas skills instaladas, el subagente muchas veces “no sabe” que existen si no las invocas explícitamente. (Es comportamiento esperado.)

  2. En Discord (canales/hilos) es muy común que estés en sandbox si tienes agents.defaults.sandbox.mode: "non-main". Y ahí vienen dos problemas gordos:

    • Por defecto docker.network suele estar en "none" ⇒ sin salida a internet ⇒ cualquier skill que llame a una API (imágenes, etc.) falla.
    • Por defecto workspaceAccess: "none" ⇒ el sandbox tiene un workspace “interno” ⇒ si intentas “instalar skills” desde ahĂ­, no te quedan instaladas en tu workspace real (parece que “se niega” o que “no funciona”).
    • Docs: https://docs.openclaw.ai/gateway/sandboxing (mira “Workspace access” y “Default docker.network is none”)

Lo que necesito para ayudarte sin adivinar

Pega aquĂ­:

  1. El error exacto que ves cuando “se niega” (una línea ya ayuda mucho).
  2. Salida de:
# 
openclaw --version
openclaw sandbox explain --json
  1. Y si puedes, el trozo relevante de tu ~/.openclaw/openclaw.json con:
  • agents.defaults.sandbox
  • tools.allow / tools.deny
  • tools.subagents.tools (si lo tienes)
  • (si quieres que agentes hablen entre sĂ­) tools.agentToAgent

Mientras tanto: checklist rápido (las 3 causas más comunes)

  • ÂżEstás sandboxed en ese canal/hilo? Si sĂ­:
    • habilita red (agents.defaults.sandbox.docker.network, por ejemplo "bridge") si necesitas APIs
    • si quieres que “instalar skills” persista, pon agents.defaults.sandbox.workspaceAccess: "rw"
  • Tool policy para subagents: aunque el agente principal tenga herramientas, el subagente puede estar más restringido. Se controla con tools.subagents.tools.allow/deny.
  • InteracciĂłn entre agentes (agente↔agente): eso requiere habilitar explĂ­citamente:
    • tools.agentToAgent.enabled: true y tools.agentToAgent.allow: [...]
dusty vortex
#

openclaw --version
openclaw sandbox explain --json
2026.2.23
│
◇ Doctor warnings ───────────────────────────────────────────────────────────────────────╮
│ │
│ - Legacy state dir is a symlink (/home/pi/.clawdbot → /home/pi/stack/Clawdbot/state); │
│ skipping auto-migration. │
│ │
├─────────────────────────────────────────────────────────────────────────────────────────╯
{
"docsUrl": "https://docs.openclaw.ai/sandbox",
"agentId": "main",
"sessionKey": "agent:main:main",
"mainSessionKey": "agent:main:main",
"sandbox": {
"mode": "off",
"scope": "agent",
"perSession": false,
"workspaceAccess": "none",
"workspaceRoot": "/home/pi/.clawdbot/sandboxes",
"sessionIsSandboxed": false,
"tools": {
"allow": [
"exec",
"process",
"read",
"write",
"edit",
"apply_patch",
"image",
"sessions_list",
"sessions_history",
"sessions_send",
"sessions_spawn",
"subagents",
"session_status"

#

],
"deny": [
"browser",
"canvas",
"nodes",
"cron",
"gateway",
"telegram",
"whatsapp",
"discord",
"irc",
"googlechat",
"slack",
"signal",
"imessage"
],
"sources": {
"allow": {
"source": "default",
"key": "tools.sandbox.tools.allow"
},
"deny": {
"source": "default",
"key": "tools.sandbox.tools.deny"
}
}
}
},
"elevated": {
"enabled": true,
"channel": "webchat",
"allowedByConfig": false,
"alwaysAllowedByConfig": false,
"allowFrom": {
"global": []
},
"failures": [
{
"gate": "allowFrom",
"key": "tools.elevated.allowFrom.webchat"
}
]
},
"fixIt": [
"tools.sandbox.tools.allow",
"tools.sandbox.tools.deny",
"agents.list[].tools.sandbox.tools.allow",
"agents.list[].tools.sandbox.tools.deny",
"tools.elevated.enabled",
"tools.elevated.allowFrom.webchat"
]
}

limber treeBOT
#

BuenĂ­simo, esto ya da pistas claras.

1) Ojo: tu openclaw --version NO es 2026.3.11

En lo que pegaste sale 2026.2.23. Eso significa que o no estás en la máquina/entorno que crees, o tienes dos instalaciones y el Gateway está corriendo con otra.

Para confirmar qué versión está ejecutando el servicio del Gateway, pega también:

openclaw gateway status

(En muchos “misterios raros”, el problema es simplemente CLI actualizado pero servicio viejo o viceversa.)

2) Tu sesión que inspeccionaste no está sandboxed

En el JSON:

#
  • "sandbox.mode": "off"
  • "sessionIsSandboxed": false
  • "sessionKey": "agent:main:main"

Así que no es el caso típico de “en Discord va en sandbox y no tiene red / no persiste skills” (al menos no en esa sesión).

PERO: lo que has inspeccionado es la sesiĂłn main (agent:main:main). El fallo te pasa en Discord en un hilo/canal, que suele tener otro sessionKey.

Si puedes, vuelve a correr sandbox explain pero apuntando a la sesión de Discord (si no sabes el sessionKey, no pasa nada: con el error exacto también llegamos).

3) Para “subagentes se niegan a instalar skills / generar imágenes”: necesito el error exacto

Porque “se niegan” puede ser 3 cosas distintas:

  • Tool policy: el subagente no tiene permitido exec / image / web_fetch, etc. (esto se controla con tools.subagents.tools.allow/deny).
  • Modelo del subagente: si tienes agents.defaults.subagents.model apuntando a un provider sin credenciales o sin soporte de imagen, el image tool falla aunque el agente principal funcione.
#
  • Prompt minimal (comportamiento esperado): los subagentes no reciben la secciĂłn “Skills” en el prompt, entonces no “saben” cĂłmo usar/instalar skills salvo que se lo indiques muy explĂ­cito.

Pégame una de estas dos cosas y lo cerramos rápido:

A) el mensaje de error del chat (tal cual), o
B) logs del subagente:

  • En Discord: /subagents list y luego /subagents log <id> tools (si tienes el id)

4) “Quiero que los agentes interactúen entre ellos”

Eso es configuraciĂłn explĂ­cita:

  • tools.agentToAgent.enabled: true
  • tools.agentToAgent.allow: ["main", "otroAgentId", ...]
#

Ese trozo que pegaste es clave, gracias.

Lo más importante: un sub-agent “normal” corre con prompt minimal

Y ese modo omite justamente las secciones que necesitas para tu caso:

  • Skills (no ve la lista de skills ni las instrucciones de “cĂłmo cargar SKILL.md”)
  • Messaging / adjuntos (no ve la regla de “para enviar un archivo hay que poner una lĂ­nea MEDIA:<path>”)

Esto está documentado aquí: https://docs.openclaw.ai/concepts/system-prompt

Por eso se siente como que “se niega” o “no puede”, pero muchas veces es simplemente que no tiene el contexto/instrucciones para:

  • instalar/usar skills por sĂ­ mismo
  • enviar la imagen aunque la haya generado

Además en el FAQ hay un apartado literal de “generó imagen pero no se envió” (y explica lo de MEDIA:):
https://docs.openclaw.ai/help/faq#my-skill-generated-an-imagepdf-but-nothing-was-sent

#

Qué hacer (recomendación práctica)

A) Instalar skills: hazlo fuera del subagent

Instala con ClawHub en el host (o ponlas en ~/.openclaw/skills) y luego abre una sesiĂłn nueva para que OpenClaw recalcule skills elegibles.
Docs: https://docs.openclaw.ai/tools/skills y https://docs.openclaw.ai/tools/clawhub

B) Generar y enviar imágenes: que el main agent haga el envío

PatrĂłn que funciona bien:

  1. Sub-agent: genera la imagen y devuelve la ruta del archivo o una URL
  2. Main: envĂ­a el archivo al chat usando MEDIA:<ruta>

En subagents, si no les dices explĂ­citamente lo de MEDIA:, normalmente nunca lo van a hacer (porque no ven esa regla en su prompt minimal).

#

Sobre tu JSON: tools.sandbox.tools.deny incluye discord, etc.

Eso significa: si algún día tu sesión estuviera sandboxed, por defecto el sandbox bloquea herramientas de canal (discord, telegram, …). Eso puede romper envíos/adjuntos y también hace que “parezca” que no manda la imagen.

Pero para saber si eso te está pegando en Discord necesito 1 dato:

¿Cuál es el error exacto cuando falla?

Pega el mensaje de error del chat, o bien:

  • /subagents list
  • /subagents log <id> tools

Y otro detalle: tu openclaw --version saliĂł 2026.2.23, no 2026.3.11

Aquí hay casi seguro mismatch entre lo que crees que corre y lo que corre de verdad. Pega también:

# 
openclaw gateway status

Con eso te digo si el problema es (1) prompt minimal esperado, (2) bloqueo por tool policy (sandbox/subagents), o (3) mismatch de versiĂłn/servicio.

dusty vortex
#

openclaw gateway status

🦞 OpenClaw 2026.2.23 (b817600) — Works on Android. Crazy concept, we know.

│
◇ Doctor warnings ───────────────────────────────────────────────────────────────────────╮
│ │
│ - Legacy state dir is a symlink (/home/pi/.clawdbot → /home/pi/stack/Clawdbot/state); │
│ skipping auto-migration. │
│ │
├─────────────────────────────────────────────────────────────────────────────────────────╯
│
â—‡
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-03-12.log

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.clawdbot/moltbot.json
Config (service): ~/.clawdbot/moltbot.json

Gateway: bind=lan (0.0.0.0), port=18789 (env/config)
Probe target: ws://192.168.31.135:18789
Dashboard: http://192.168.31.135:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 192.168.31.135.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
RPC probe: failed
RPC target: ws://192.168.31.135:18789
SECURITY ERROR: Gateway URL "ws://192.168.31.135:18789" uses plaintext ws:// to a non-

#

loopback address.
Both credentials and chat data would be exposed to network interception.
Source: cli --url
Config: /home/pi/.clawdbot/moltbot.json
Fix: Use wss:// for remote gateway URLs.
Safe remote access defaults:

  • keep gateway.bind=loopback and use an SSH tunnel (ssh -N -L 18789:127.0.0.1:18789 user@gateway-host)
  • or use Tailscale Serve/Funnel for HTTPS remote access
    Doctor: openclaw doctor --fix
    Docs: https://docs.openclaw.ai/gateway/remote

Port 18789 is already in use.

limber treeBOT
#

Perfecto — este gateway status explica por qué te está fallando el “RPC probe” y por qué ahora mismo es difícil diagnosticar lo de subagents desde tu CLI.

1) Estás en OpenClaw 2026.2.23, no 2026.3.11

El propio status lo dice arriba:

🦞 OpenClaw 2026.2.23 (b817600)

AsĂ­ que hay mismatch con lo que creĂ­as. Si realmente quieres 2026.3.11, primero hay que actualizar esa instalaciĂłn (y luego reiniciar el gateway).

2) Tu Gateway (según systemd) está parado + el probe falla por un bloqueo de seguridad

En el status:

  • Service: systemd (disabled)
  • Runtime: stopped …
  • RPC probe: failed
#
  • y lo más importante:
    SECURITY ERROR: ... ws://192.168... uses plaintext ws:// to a non-loopback address

Esto último es intencional: en 2026.2.23+ el CLI bloquea conectar por ws:// a una IP LAN (aunque sea privada), porque sería tráfico en claro.

CĂłmo arreglarlo (recomendado):

  • Si quieres acceso remoto/LAN: usa Tailscale Serve/Funnel o HTTPS/WSS (ver doc)
    https://docs.openclaw.ai/gateway/remote
  • Alternativa “clásica” segura: deja gateway.bind=loopback y usa un SSH tunnel (la doc lo pone tal cual).
  • Hay un “break-glass” OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1, pero de verdad: Ăşsalo sĂłlo para pruebas en red privada y sabiendo lo que implica (sale tambiĂ©n en el error).

Hasta que el CLI pueda hacer el probe, vas a ver “RPC probe failed” aunque el gateway estuviera escuchando, porque el CLI se niega a hablar por ws:// a esa IP.

3) ¿Esto afecta a tu problema de “subagents no instalan skills / no envían imágenes”?

SĂ­, por dos motivos:

#
  1. Si el gateway no está corriendo (o no estás mirando el gateway correcto), cualquier cosa de subagents/skills va a ser inconsistente.
  2. Aunque el gateway corra, los subagents usan prompt minimal y omiten Skills + Messaging, asĂ­ que es normal que:

Siguiente paso (para destrabar de verdad)

Dime cuál de estos escenarios es el tuyo:

A) “El gateway debería correr en esta Raspberry Pi 24/7”
→ entonces primero hay que instalar/rehacer el servicio y arrancarlo (tu status ya sugiere openclaw doctor --repair y la FAQ recomienda openclaw gateway install --force). Después miramos subagents.

B) “El gateway corre en otra máquina / en Docker / etc.”
→ entonces este gateway status no es del gateway que realmente está atendiendo Discord, y necesitamos el status en el host correcto.

#

Y para ir directo al síntoma original: pega un ejemplo real del error del subagent (texto o /subagents log <id> tools). Con eso te digo si es (i) prompt minimal esperado, (ii) tool policy, o (iii) falta de credenciales/modelo para imágenes.

#

Vale, ahora está clarísimo qué está pasando:

1) El “SECURITY ERROR … ws://192.168…” te sale porque estás usando --url a una IP LAN

En el error pone:

  • Source: cli --url
  • y bloquea ws:// a cualquier direcciĂłn no-loopback por seguridad.

Eso significa:

  • Si estás en la misma Raspberry Pi: usa loopback, por ejemplo:

    openclaw gateway status --url ws://127.0.0.1:18789

    (o simplemente no uses --url si no estás en remote mode)

  • Si estás desde otra máquina y quieres administrar el gateway remoto: no se puede con ws://192.168... en claro. Las opciones seguras que te da el propio error son las buenas:

#

Hay un “break-glass” OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1, pero úsalo sólo si entiendes el riesgo (LAN “de confianza” y para debug).

2) “Port 18789 is already in use” + systemd dice “stopped” = hay algo escuchando fuera de systemd

Esto suele pasar cuando el gateway está corriendo:

  • en foreground (openclaw gateway en una terminal),
  • o en Docker,
  • o como otro service/profile.

Como no tienes lsof, usa ss (normalmente viene instalado) para ver qué proceso está ocupando el puerto:

# 
ss -ltnp | grep 18789
# si no sale el proceso por permisos:
sudo ss -ltnp | grep 18789

Con eso sabremos si lo que está escuchando es OpenClaw o “algo raro”.

3) Volviendo a tu tema original (sub-agents + skills + imágenes)

Aunque arreglemos lo del gateway/puerto, hay una parte que es por diseño: