telegram just conversational, not trigging actions | Friends of the Crustacean 🦞🤝 | Page 1

zinc root Apr 14, 2026, 2:02 PM

#

En Telegram el bot contesta en modo conversacional pero no dispara herramientas/acciones, y en Slack hay problemas similares con interacciones o eventos que se encolan pero no “despiertan” la sesión para ejecutar.
Usando 4.12

noble prawnBOT Apr 14, 2026, 2:02 PM

#

elfin lanceBOT Apr 14, 2026, 2:02 PM

#

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

tight parrotBOT Apr 14, 2026, 2:05 PM

#

Voy a comprobar la referencia local y buscar si esto ya está documentado o corregido en versiones más nuevas.

#

Si por “4.12” te refieres a v2026.4.12, sí, esto huele bastante a regresión en esa versión.

Lo revisé en docs + repo, y justo después de v2026.4.12 entraron varios fixes muy relacionados con tu síntoma:

Slack: fix(slack): make inbound retries explicit
Telegram: varios fix(telegram): retry failed ... callbacks
sesiones/eventos: preserve shared session route on system events
cola/ruteo: replay queued session context

Eso encaja mucho con “se encola el evento/interacción pero no despierta la sesión”.

Lo que haría, en este orden:

Confirma versión exacta:

openclaw --version

#

Si realmente es v2026.4.12, actualiza primero:

openclaw update

Si necesitas probar los fixes post-4.12 ya mismo:

openclaw update --tag main

Luego corre:

openclaw status --all
openclaw channels status --probe
openclaw logs --follow

Reproduce:

#

una interacción en Slack
un callback/acción en Telegram

y pega el bloque de logs alrededor del evento.

Checks puntuales:

Slack HTTP mode: Events, Interactivity y slash commands deben apuntar al mismo /slack/events, con signingSecret válido.
Slack Socket Mode: verifica botToken, appToken y scope assistant:write.
Telegram: si esperas botones/callbacks, revisa channels.telegram.capabilities.inlineButtons.
Telegram/Slack actions: confirma que no estén desactivadas por config (channels.telegram.actions.*, channels.slack.actions.*).

Como el bot sí responde “conversacional”, yo no empezaría por pairing/modelos. El problema parece más abajo, en callbacks/system events/session wake.

Docs útiles:

#

Si quieres, pega aquí:

openclaw --version
openclaw channels status --probe
30-50 líneas de openclaw logs --follow al reproducirlo

y lo afinamos rápido.

zinc root Apr 14, 2026, 2:08 PM

#

Thanks. I’m seeing the same issue in both Telegram and Slack.

OpenClaw responds in chat, but often stays in a conversational mode instead of actually executing actions/tools. So it looks like it understood the request, but the action never really happens.

What I expected:
• the bot should execute actions from Telegram and Slack,
• cron jobs should run normally,
• and cron outputs should be delivered back to chat reliably.

What happens instead:
• the bot replies in natural language,
• but simple actions are often not executed,
• and cron behavior in chat is inconsistent.

Cron itself seems to be running: jobs are enabled, stored correctly, and most show Status: ok with Target: isolated. That makes me think the scheduler is probably not the main issue.

So my current suspicion is that this is related to channel handling, tool/action dispatch, approvals, or delivery in Telegram/Slack rather than cron execution itself.

tight parrotBOT Apr 14, 2026, 2:09 PM

#

Voy a mirar la parte de cron/delivery, porque “Target: isolated” sí cambia cómo vuelve el resultado al chat.

#

Sí, eso ya acota bastante.

Si pasa en Telegram + Slack + cron, yo dejaría de pensar en “bug del canal” y lo dividiría así:

el modelo no está haciendo tool/action calls, entonces responde en modo conversacional
sí hay ejecución, pero falla el wake/routing/delivery al volver al chat

Y en v2026.4.12 hay señales de ambos, pero sobre todo del segundo, porque justo después entraron fixes de:

system events / shared session route
queued session context replay
Slack inbound retries
varios retries de callbacks en Telegram

Además, para cron aislado hay un matiz importante: el runner es quien entrega el resultado final, no el agente. Si el run queda “ok” pero delivery falla, el scheduler no es el culpable. Eso está documentado aquí: https://docs.openclaw.ai/automation/cron-jobs y https://docs.openclaw.ai/automation/tasks

Qué mirar

Si en logs no aparece ningún tool/action attempt, el problema es más de modelo/tool-calling.

#

Esto pasa bastante con algunos modelos locales/OpenAI-compatible, que contestan bonito pero no llaman herramientas bien.
Si sí aparece ejecución pero no hay mensaje final, entonces es delivery/routing/wake.
- Ahí 4.12 me parece sospechoso.

Recomendación práctica

Si confirmas que es v2026.4.12, yo probaría primero:

openclaw update

Si quieres validar los fixes post-4.12 sin esperar:

openclaw update --tag main

Dos detalles extra

#

En Slack, si usas HTTP mode, revisa que Events + Interactivity + Slash Commands apunten al mismo /slack/events.
En cron isolated, no esperes que el agente “se auto-entregue” con message; el runner es quien debe anunciar el resumen final.

Si quieres, pega:

openclaw models status
un tasks show <runId>
y 30-50 líneas de log reproduciendo una acción simple

y te digo cuál de las dos ramas es la tuya.

zinc root Apr 14, 2026, 2:12 PM

#

✗ Updating via package manager (81.35s)
npm error code ENOENT
npm error syscall spawn sh
npm error path /opt/homebrew/lib/node_modules/openclaw/node_modules/@whiskeysockets/baileys
npm error errno -2
npm error enoent spawn sh ENOENT
npm error enoent This is related to npm not being able to find a file.
npm error enoent
npm error A complete log of this run can be found in: /Users/xx/.npm/_logs/2026-04-14T14_10_49_826Z-debug-0.log

Update Result: ERROR
Root: /opt/homebrew/lib/node_modules/openclaw
Reason: global update
Before: 2026.4.12

Total time: 82.15s

tight parrotBOT Apr 14, 2026, 2:14 PM

#

Eso ya es otra pista buena: el update ni siquiera llegó a aplicar. Voy a comprobar si ese spawn sh ENOENT ya está documentado o si conviene saltarse el updater.

#

Perfecto, eso ya separa dos cosas.

Ese error de update es del install global por npm/Homebrew, no del runtime de Telegram/Slack en sí:

npm error enoent spawn sh ENOENT
root: /opt/homebrew/lib/node_modules/openclaw

O sea, ahora mismo sigues en 2026.4.12, así que todavía no probaste los fixes post-4.12.

Mi recomendación

Yo no pelearía más con ese global install. Haría bypass y me pasaría a git/dev, que además es justo lo que te conviene para este bug.

Opción más directa

curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash -s -- --install-method git
openclaw update --channel dev

#

openclaw doctor
openclaw gateway restart
openclaw --version

Docs:

Por qué esta ruta

Porque tu problema tiene pinta de:

fixes ya aterrizados después de v2026.4.12
y además tu updater global está roto, así que openclaw update por npm no es una vía fiable ahora mismo

Si quieres revisar el fallo del updater

#

Ese spawn sh ENOENT suele apuntar a shell/PATH roto en npm. Chequeos rápidos:

which sh
echo $PATH
npm config get script-shell
npm prefix -g

Pero honestamente, para desbloquearte, yo haría primero el cambio a git/dev.

Si luego de eso sigue igual, el siguiente paquete de datos útil sería:

openclaw --version
openclaw models status

#

openclaw channels status --probe
openclaw logs --follow

y una reproducción mínima de:

una acción simple en Telegram
una interacción simple en Slack
un cron runs --id <jobId> --limit 20

Si quieres, pega el openclaw --version después del cambio y seguimos desde ahí.

zinc root Apr 14, 2026, 2:28 PM

#

sigue Igual

🦞 OpenClaw 2026.4.14 (a88c6f0)
Runs on a Raspberry Pi. Dreams of a rack in Iceland.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.3-codex
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : OpenRouter -> openrouter/auto
Configured models (1): openrouter/auto

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)

openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...27c07619 | env=sk-or-v1...8a84c0af | source=env: OPENROUTER_API_KEY
perplexity effective=env:sk-or-v1...8a84c0af | env=sk-or-v1...8a84c0af | source=env: OPENROUTER_API_KEY

OAuth/token status

openai-codex usage: 5h 75% left ⏱57m · Week 34% left ⏱3d 6h
- openai-codex:default ok expires in 4d

tight parrotBOT Apr 14, 2026, 2:30 PM

#

Gracias, esto ya aclara bastante.

Como en 2026.4.14 sigue igual, yo ya dejaría de culpar a la versión 4.12.
Si falla en Telegram + Slack + cron isolated, casi seguro el problema está en la ruta compartida del agente:

o no está emitiendo tool calls
o las emite pero están bloqueadas por config
y recién al final eso se ve como “no hace nada” en cada canal

O sea, ahora me suena menos a canal y más a modelo/tools/config.

Siguiente corte, muy simple

Mira el estado de canales:

openclaw channels status --probe

#

Mira si las acciones están habilitadas:

openclaw config get tools.allow
openclaw config get channels.telegram.actions
openclaw config get channels.slack.actions

Abre logs y reproduce una acción mínima:

openclaw logs --follow

Luego pídele algo muy tonto, por ejemplo:

en Telegram: “reacciona con 👍 a este mensaje”
en Slack: “pon una reacción 👍”

Lo importante en logs

#

Si no aparece ningún intento de tool/action, el problema es modelo/tool-calling
Si aparece el intento pero falla/salta/queda queued, entonces sí es dispatch/delivery/wake

Otra sospecha importante

Para depurar esto, no uses auto-routing tipo openrouter/auto si alguna sesión lo está tocando. Mete un modelo explícito y estable mientras pruebas, porque el auto-router hace muy difícil saber si el fallo es del canal o del modelo.

Para cron

Como tus jobs están en Target: isolated, revisa el delivery real del run:

openclaw cron runs --id <jobId> --limit 10
openclaw tasks show <runId>

Ahí quiero ver especialmente:

deliveryStatus
delivered

#

deliveryError

Si pegas ahora estas 4 cosas:

openclaw channels status --probe
openclaw config get tools.allow
openclaw config get channels.telegram.actions
20-40 líneas de openclaw logs --follow al pedir una reacción 👍

te digo ya si esto va por modelo, tools bloqueadas, o delivery/wake.

zinc root Apr 14, 2026, 2:31 PM

#

🦞 OpenClaw 2026.4.14 (a88c6f0)
Less clicking, more shipping, fewer "where did that file go" moments.

Config path not found: tools.allow

🦞 OpenClaw 2026.4.14 (a88c6f0)
Your personal assistant, minus the passive-aggressive calendar reminders.

Config path not found: channels.telegram.actions

🦞 OpenClaw 2026.4.14 (a88c6f0)
The only crab in your contacts you actually want to hear from. 🦞

Config path not found: channels.slack.actions

tight parrotBOT Apr 14, 2026, 2:32 PM

#

Eso en realidad sí ayuda.

Config path not found aquí significa:

no tienes un tools.allow custom
no tienes channels.telegram.actions custom
no tienes channels.slack.actions custom

O sea, no parece que estés bloqueando tools/actions por config.
Con eso, mi sospecha sube bastante a:

el modelo no está llamando herramientas, o
sí las llama, pero el runtime las está perdiendo en logs/dispatch

Siguiente paso, ya sin dar más vueltas

Necesito solo estas 2 cosas:

#

openclaw channels status --probe

y luego:

openclaw logs --follow

Con los logs abiertos, prueba una acción mínima, por ejemplo:

Telegram: reacciona con 👍 a este mensaje
Slack: pon una reacción 👍

Qué quiero ver en esos logs

si aparece un tool/action attempt

#

si aparece algo como queued / wake / delivery / interaction
o si directamente nunca hubo tool call y solo sale texto normal

Interpretación rápida

No hay tool call en logs → problema de modelo/tool-calling
Sí hay tool call pero falla después → problema de dispatch/delivery/wake

Y una nota importante: como ya descartamos config básica y te pasa en Telegram + Slack + cron, esto ya no huele a Telegram ni a Slack. Huele a ruta común del agente.

Si pegas:

openclaw channels status --probe
20-40 líneas de openclaw logs --follow durante una prueba de 👍

te digo cuál de las dos es casi seguro.

zinc root Apr 14, 2026, 2:35 PM

#

Gateway reachable.

Discord default: enabled, not configured, stopped, disconnected, error:not configured
Slack default: enabled, configured, running, connected, bot:config, app:config, works
Telegram default: enabled, configured, running, in:6m ago, mode:polling, bot:@xx_bot, token:config, works

cuando puse la acción mínima en telegram:
14:34:37+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 64ms conn=a0935a30…5ae3 id=83193988…6D9C
14:35:08+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 69ms conn=24ad9e4f…296f id=83eb9249…edce
14:35:08+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 115ms conn=4a13e67d…3035 id=98b45606…985c

tight parrotBOT Apr 14, 2026, 2:37 PM

#

Bien, eso ya descarta bastante.

Lo que ya sabemos

Slack y Telegram están sanos a nivel de transporte: ambos salen works
no parece bloqueo por config: esos paths no existen porque no están overrideados
los logs que pegaste no son del evento de Telegram, son del Control UI / WS:
- sessions.list
- logs.tail
- node.list

O sea, eso todavía no muestra ni inbound de Telegram ni tool call ni fallo de dispatch.

Mi lectura ahora

Esto ya apunta mucho más a:

el agente/modelo no está entrando en tool-calling, o
sí entra, pero necesitamos ver el log real del run

#

Haz esta prueba, pero filtrando mejor

openclaw logs --follow | grep -Ei 'telegram|slack|tool|queue|cron|agent|assistant|warn|error'

Luego manda en Telegram algo tipo:

reacciona con 👍 a este mensaje
o mejor aún, algo con herramienta no de canal:
- lee ~/.openclaw/openclaw.json y dime si existe

Qué necesito ver

Quiero las líneas donde salga algo como:

inbound Telegram/Slack
start de run/agent
tool call / tool result
queue / wake / delivery
warn / error

#

Importante

Ahora mismo no parece un problema del canal.
Si Telegram y Slack dicen works y cron isolated también se comporta raro, el sospechoso principal pasa a ser la ruta común del agente, especialmente modelo/tool-calling.

Y para depurar eso, evita cualquier cosa tipo openrouter/auto mientras pruebas. Para debugging, mejor usar un modelo explícito, no auto-router, porque si no nunca sabes si el fallo es del modelo que tocó en ese turno.

Si me pegas el log filtrado de una sola prueba, ya te puedo decir con bastante precisión si esto es:

no tool call
tool call fallido
o delivery/wake roto

zinc root Apr 14, 2026, 2:38 PM

#

14:37:56+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 235ms conn=6498d4c6…a06f id=e984c58c…f1f4

tight parrotBOT Apr 14, 2026, 2:39 PM

#

Ese log sigue siendo solo la suscripción al stream de logs, no el evento real:

⇄ res ✓ logs.tail

A esta altura, con:

Slack/Telegram = works
sin bloqueos obvios por config
y cero logs del mensaje real

mi sospecha principal cambia a esta:

Estás mirando el log/gateway equivocado, o tienes más de un gateway corriendo

Eso encaja mucho con:

channels status --probe pega a un gateway “sano”
pero el mensaje real entra por otro proceso / otro state dir / otro servicio viejo

#

Haz estas 3 cosas

openclaw gateway status
openclaw gateway status --deep
tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Luego manda en Telegram:
reacciona con 👍 a este mensaje

Qué espero

En el tail -f quiero ver algo de:

telegram inbound/update
run start
tool call
error/warn/queue/delivery

#

Si NO sale nada del mensaje en ese log

Entonces casi seguro tienes:

otro gateway-like service corriendo
o mismatch entre config/state dir y el servicio activo

Y gateway status --deep justo sirve para pescar eso.

Si SÍ sale el mensaje pero no hay tool call

Entonces volvemos a la otra rama:

modelo/tool-calling

Pero ahora mismo, sinceramente, lo de múltiples gateways / servicio stale ya me preocupa más que Telegram o Slack.

Docs:

#

Si pegas la salida de openclaw gateway status --deep, ahí ya deberíamos ver si ese es el lío.

zinc root Apr 14, 2026, 2:45 PM

#

Last login: Tue Apr 14 11:25:30 on ttys000
You have new mail.
xx@MacBookPro ~ % openclaw gateway status

🦞 OpenClaw 2026.4.14 (a88c6f0)
Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-14.log
Command: /opt/homebrew/opt/node/bin/node /Users/xx
/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 42510, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
xx@MacBookPro ~ %

arielestebanbardach@MacBookPro ~ % openclaw gateway status --deep

🦞 OpenClaw 2026.4.14 (a88c6f0)
The only open-source project where the mascot could eat the competition.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-14.log
Command: /opt/homebrew/opt/node/bin/node /Users/xx
/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 42510, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
xx@MacBookPro ~ %

#

ast login: Tue Apr 14 11:41:33 on ttys000
You have new mail.
xx@MacBookPro ~ % tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
{"0":"{"subsystem":"plugins"}","1":"[plugins] openclaw-google-workspace: loaded without install/load-path provenance; treat as untracked local code and pin trust via plugins.allow or install records (/Users/xx/.openclaw/extensions/openclaw-google-workspace/src/index.ts)","_meta":{"runtime":"node","runtimeVersion":"25.6.1","hostname":"unknown","name":"{"subsystem":"plugins"}","parentNames":["openclaw"],"date":"2026-04-14T14:33:27.092Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///Users/xx/openclaw/dist/subsystem-BHv2zSx6.js:330:14","fileName":"subsystem-BHv2zSx6.js","fileNameWithLine":"subsystem-BHv2zSx6.js:330","fileColumn":"14","fileLine":"330","filePath":"openclaw/dist/subsystem-BHv2zSx6.js","filePathWithLine":"openclaw/dist/subsystem-BHv2zSx6.js:330","method":"logToFile"}},"time":"2026-04-14T11:33:27.092-03:00"}
{"0":"u001b[38;2;47;191;113mGateway reachable.u001b[39mn- Discord default: enabled, not configured, stopped, disconnected, error:not configuredn- Slack default: enabled, configured, running, connected, bot:config, app:config, worksn- Telegram default: enabled, configured, running, in:6m ago, mode:polling, bot:@Juanca38_bot, token:config, worksnnTip: u001b]8;;https://docs.openclaw.ai/cli#statusu0007status --deepu001b]8;;u0007 adds gateway health probes to status output (requires a reachable gateway).","_meta":{"runtime":"node","runtimeVersion":"25.6.1","hostname":"unknown","name":"openclaw","date":"2026-04-14T14:33:28.895Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///Users/xx/openclaw/dist/subsystem-BHv2zSx6.js:159:46","fileName":"subsystem-BHv2zSx6.js","fileNameWithLine":"subsystem-BHv2zSx6.js:159","fileColumn":"46","fileLine":"159","filePath":"openclaw/dist/subsystem-BHv2zSx6.js","filePathWithLine":"openclaw/dist/subsystem-BHv2zSx6.js:159","method":"console.log"}},...

tight parrotBOT Apr 14, 2026, 2:50 PM

#

Sí, ahí seguimos viendo ruido de arranque/status, no la prueba real. Para no hacerte dar más vueltas, mejor hagamos un corte limpio:

Bypass total de Telegram/Slack

Prueba el runtime del agente desde CLI, sin canales.

Con el path que ya sabemos que existe:

openclaw agent --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line." --json

Docs: https://docs.openclaw.ai/tools/agent-send

Qué nos dice ese resultado

Si usa la tool y te devuelve la primera línea real del archivo
→ el problema no es tool-calling general, entonces volvemos a delivery/wake/channel
Si responde en lenguaje natural y no usa la tool

#

→ el problema es modelo / tool-calling / runtime compartido

Eso nos saca del bucle de “¿es Telegram? ¿es Slack? ¿es cron?” en un solo paso.

Si puedes, pega el JSON completo de ese comando. Ahí ya deberíamos tener el diagnóstico de verdad.

zinc root Apr 14, 2026, 2:52 PM

#

xx@MacBookPro ~ % openclaw agent --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line." --json
11:51:04 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-google-workspace (/Users/xx/.openclaw/extensions/openclaw-google-workspace/src/index.ts). Set plugins.allow to explicit trusted ids.
11:51:08 [plugins] openclaw-google-workspace: loaded without install/load-path provenance; treat as untracked local code and pin trust via plugins.allow or install records (/Users/xx/.openclaw/extensions/openclaw-google-workspace/src/index.ts)
Gateway agent failed; falling back to embedded: Error: Pass --to <E.164>, --session-id, or --agent to choose a session
Error: Pass --to <E.164>, --session-id, or --agent to choose a session
xx@MacBookPro ~ %

tight parrotBOT Apr 14, 2026, 2:53 PM

#

Sí, ahí el comando no llegó a ejecutar nada, porque le faltó el destino de sesión.

Mi error, usa este:

openclaw agent --agent main --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line." --json

Eso ya fuerza la sesión main y debería correr de verdad.

Notas rápidas:

el warning de openclaw-google-workspace ahora mismo es ruido, no el fallo principal
el error real es este: Pass --to <E.164>, --session-id, or --agent

Si quieres aislarlo todavía más del gateway, también puedes probar:

#

openclaw agent --agent main --local --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line." --json

Cómo leer el resultado

si usa read y devuelve la línea → tools funcionan, volvemos a channel/delivery
si vuelve a contestar natural sin tool → problema claro de tool-calling/runtime

Pégame el JSON de --agent main y ya cerramos el diagnóstico.

zinc root Apr 14, 2026, 2:54 PM

#

no hizo nada en telegram

tight parrotBOT Apr 14, 2026, 2:54 PM

#

Sí, eso es esperado, ese comando no tenía que hacer nada en Telegram 😅

Era una prueba de CLI local, para ver si el agente usa tools fuera del canal.
Sin --deliver, la salida va al terminal, no a Telegram.

Lo que necesito es lo que imprimió en la terminal con:

openclaw agent --agent main --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line." --json

Si prefieres algo más simple, sin JSON:

openclaw agent --agent main --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line."

#

Interpretación

si responde en terminal con la primera línea real del archivo → tools sí funcionan
si responde en modo conversacional o no usa la tool → problema de tool-calling/runtime

Así que ahora mismo no necesito Telegram, necesito la salida del terminal. Pégamela y seguimos.

zinc root Apr 14, 2026, 2:56 PM

#

{
"runId": "88340a58-cc19-488e-8e4e-581e64d2f184",
"status": "ok",
"summary": "completed",
"result": {
"payloads": [
{
"text": "{"subsystem":"telegram/network"}",
"mediaUrl": null
}
],
"meta": {
"durationMs": 29196,
"agentMeta": {
"sessionId": "29a2d862-657e-465c-820b-f3861209be3e",
"provider": "openai-codex",
"model": "gpt-5.3-codex",
"usage": {
"input": 101386,
"output": 132,
"cacheRead": 100736,
"total": 101291
},
"lastCallUsage": {
"input": 496,
"output": 59,
"cacheRead": 100736,
"cacheWrite": 0,
"total": 101291
},
"promptTokens": 101232
},
"aborted": false,
"systemPromptReport": {
"source": "run",
"generatedAt": 1776178497586,
"sessionId": "29a2d862-657e-465c-820b-f3861209be3e",
"sessionKey": "agent:main:main",
"provider": "openai-codex",
"model": "gpt-5.3-codex",
"workspaceDir": "/Users/xx/.openclaw/workspace",
"bootstrapMaxChars": 20000,
"bootstrapTotalMaxChars": 150000,
"bootstrapTruncation": {
"warningMode": "once",
"warningShown": false,
"truncatedFiles": 0,
"nearLimitFiles": 0,
"totalNearLimit": false
},
"sandbox": {
"mode": "off",
"sandboxed": false
},
"systemPrompt": {
"chars": 51495,
"projectContextChars": 25551,
"nonProjectContextChars": 25944
},
"injectedWorkspaceFiles": [
{
"name": "AGENTS.md",
"path": "/Users/xx/.openclaw/workspace/AGENTS.md",
"missing": false,
"rawChars": 7804,
"injectedChars": 7804,
"truncated": false
},

tight parrotBOT Apr 14, 2026, 2:57 PM

#

Perfecto, esto ya sirve muchísimo.

Ese resultado confirma dos cosas:

sí hubo tool call
el modelo/runtime general funciona

Porque te devolvió la primera línea real del archivo:

{"subsystem":"telegram/network"}

Así que ya podemos descartar bastante fuerte:

problema general de modelo
problema general de tool-calling
problema general del agente

#

Lo que queda

El fallo está mucho más abajo, en una de estas dos capas:

tools ligadas al canal (message, react, callbacks, interacciones)
wake/delivery/session routing para Telegram/Slack

O sea, ya no es “el bot no sabe usar tools”, sino “las tools del canal / el wake del canal no terminan de ejecutarse bien”.

Siguiente prueba útil

Haz una prueba sin modelo, directo contra el canal.

Telegram

openclaw message send --channel telegram --target <chat-id-o-@user> --message "ping from CLI"

Slack

#

openclaw message send --channel slack --target channel:<id> --message "ping from CLI"

Cómo leer eso

Si esto funciona, entonces el transporte outbound está bien, y el bug queda casi seguro en:
- agent → channel action dispatch
- o interaction/session wake
Si esto falla, entonces sí estamos en un problema más básico de acción/delivery del canal

Mi lectura ahora

Con la evidencia que ya juntaste, esto ya huele a bug real, no a mala configuración.

Yo haría dos cosas en paralelo:

prueba el openclaw message send directo
abre issue en GitHub con este paquete de evidencia:

#

2026.4.14
- channels status --probe = Slack/Telegram works
- openclaw agent --agent main ... sí usa read
- en chat responde conversacionalmente pero no ejecuta acciones / no despierta sesión

Issue: https://github.com/openclaw/openclaw/issues

Si quieres, te ayudo a redactar el issue en 5 líneas con todo lo que ya probaste.

zinc root Apr 14, 2026, 4:03 PM

#

me respondió en Telegram: ping from CLI

tight parrotBOT Apr 14, 2026, 4:04 PM

#

Perfecto. Con eso ya quedó muy bien aislado.

Lo que ya probaste

Telegram/Slack transport: works
tool-calling general: funciona (read sí se ejecuta)
outbound directo al canal: funciona (ping from CLI llegó a Telegram)

Conclusión

Entonces el bug no está en:

auth del canal
conexión del canal
modelo en general
tools en general
envío directo al canal

El fallo queda casi seguro en la capa de:

#

agent → channel action dispatch
o interaction / queued event → session wake
especialmente para acciones disparadas desde chat y para Slack interactions

Eso encaja exactamente con tu síntoma original.

Mi recomendación

Yo ya lo trataría como bug de OpenClaw y abriría issue con esta evidencia:

Título sugerido

Telegram/Slack chat-triggered actions stay conversational instead of executing tools; direct CLI tool calls and direct channel sends work

Resumen sugerido

Version: 2026.4.14 (a88c6f0)
openclaw channels status --probe: Telegram and Slack both works
openclaw agent --agent main ... successfully uses read tool
openclaw message send --channel telegram ... successfully delivers to Telegram

#

But when asking from Telegram/Slack chat, the bot often replies conversationally instead of executing actions/tools
Slack interactions / queued events also appear not to wake the session reliably
Isolated cron runs show ok, but chat-facing delivery/action behavior is inconsistent

Issue: https://github.com/openclaw/openclaw/issues

Workaround while tanto

para envíos críticos, usa openclaw message send directo
para cron, apóyate en delivery/announce explícito y no en que el agente “se auto-envíe” cosas al chat

Si quieres, te dejo el issue ya redactado en formato markdown para copiar/pegar.

zinc root Apr 14, 2026, 4:05 PM

#

dale

tight parrotBOT Apr 14, 2026, 4:06 PM

#

Pega esto en GitHub:

## Summary

On `OpenClaw 2026.4.14 (a88c6f0)`, Telegram and Slack respond conversationally, but chat-triggered actions/tools often do not execute.

This does **not** look like a basic channel transport or auth problem.

## What I expected

- Telegram and Slack chat requests should execute tools/actions normally
- Slack interactions / queued events should wake the session and run
- Isolated cron runs should deliver chat-facing results reliably

## What happens instead

#


- The bot replies in natural language
- But actions/tools from chat often do not happen
- Slack interactions / queued events appear not to wake the session reliably
- Cron runs can show `ok`, but chat-facing action/delivery behavior is inconsistent

## Version / environment

- OpenClaw: `2026.4.14 (a88c6f0)`
- macOS
- LaunchAgent service
- Gateway status: `running`, `RPC probe: ok`
- Config (cli) and Config (service) both point to `~/.openclaw/openclaw.json`

## Evidence collected

#


### Channels look healthy

`openclaw channels status --probe` shows:

- Slack: `enabled, configured, running, connected, works`
- Telegram: `enabled, configured, running, mode: polling, works`

### General tool-calling works

This CLI test successfully used the `read` tool:

```bash
openclaw agent --agent main --message "Use the read tool on /tmp/openclaw/openclaw-2026-04-14.log and return only the first line." --json

#


Result included:

```json
{"subsystem":"telegram/network"}

So general agent tool-calling is working.

Direct outbound channel send also works

This direct Telegram send worked:

openclaw message send --channel telegram --target <target> --message "ping from CLI"

#


Telegram received:

```text
ping from CLI

So direct outbound Telegram delivery is working too.

Current conclusion

This seems narrowed down to a bug in one of these layers:

agent -> channel action dispatch
interaction / queued-event -> session wake

#

- channel-bound tool execution path from chat context

It does **not** seem to be:
- broken auth
- broken transport
- broken direct outbound send
- broken general tool-calling

## Repro shape

1. Send a tool/action request from Telegram or Slack chat
2. Bot answers conversationally
3. Expected action/tool does not happen
4. Similar symptoms appear with Slack interactions and queued events that should wake the session

#

## Extra notes

- `openclaw gateway status --deep` did not show an obvious multi-gateway mismatch
- CLI/session tests suggest the problem is specific to chat-originated channel action execution, not the agent runtime in general

Si quieres, también te lo convierto a una versión más corta tipo “maintainer-friendly”.

zinc root Apr 15, 2026, 3:19 PM

#

openclaw not executing tool-calling from chat

tight parrotBOT Apr 15, 2026, 3:20 PM

#

Sí, pero yo lo haría un poco más específico.

Recomendado:
Chat-triggered tool calls stay conversational instead of executing (Telegram/Slack), while CLI tool calls and direct channel sends work

Más corto:
OpenClaw does not execute tool calls from chat in Telegram/Slack

Si quieres algo más técnico:
Telegram/Slack chat-originated tool calls do not execute, but CLI tool calls and direct channel sends work

Yo usaría el primero.

zinc root Apr 15, 2026, 3:20 PM

#

ok, no tenemos sugerencia tuya para arreglar esto?

tight parrotBOT Apr 15, 2026, 3:21 PM

#

Sí, pero te diría la verdad: arreglo confiable por config no tengo.
Con lo que aislamos, esto parece más bug que mala config.

Lo que sí haría como workaround:

Para cron, usa siempre delivery explícito del runner (--announce / delivery.mode: "announce").
- No confíes en que el agente dentro del cron “se mande” cosas al chat con tools.
Para envíos importantes, usa directo:
```
openclaw message send ...
```
Ya comprobaste que eso sí funciona.
Para tareas agentic fuera del chat, usa:

#

   openclaw agent --agent main ...

y si necesitas entrega:

openclaw agent --agent main --deliver ...

Prueba un chat/thread nuevo en Telegram y en Slack.
- Si en una sesión nueva sí funciona, entonces probablemente hay estado de sesión viejo/podrido en la conversación actual.
Evita auto-routing mientras pruebas.
- Usa un modelo explícito en esas sesiones, no auto-router, para no mezclar dos problemas.

Mi recomendación práctica

Si yo estuviera bloqueado hoy, haría esto:

#

chat normal para conversación
message send para envíos críticos
cron con announce para delivery
agent --agent main para automatizaciones que necesiten tools de verdad

O sea, separar:

conversación por chat
acciones/delivery por CLI/runner

No es bonito, pero te saca del paso hasta que lo corrijan.

Si quieres, te doy los comandos exactos para:

workaround de cron
workaround de Telegram
workaround de Slack
y te los dejo listos para copiar/pegar.

zinc root Apr 15, 2026, 3:22 PM

#

dale

tight parrotBOT Apr 15, 2026, 3:23 PM

#

Va. Te dejo los workarounds más útiles, listos para copiar.

1) Telegram, envío directo confiable

openclaw message send --channel telegram --target <chat-id-o-@user> --message "ping from CLI"

Si es un topic de Telegram:

openclaw message send --channel telegram --target "<chatId>:topic:<threadId>" --message "ping from CLI"

2) Slack, envío directo confiable

#

openclaw message send --channel slack --target "channel:<channel-id>" --message "ping from CLI"

Para DM:

openclaw message send --channel slack --target "user:<user-id>" --message "ping from CLI"

3) Correr el agente fuera del chat y entregar el resultado

A Telegram

openclaw agent --agent main \
  --message "Haz la tarea y devuelve solo el resultado final." \

#

  --deliver --reply-channel telegram --reply-to "<chat-id>"

A Slack

openclaw agent --agent main \
  --message "Haz la tarea y devuelve solo el resultado final." \
  --deliver --reply-channel slack --reply-to "#canal"

Esto te deja usar tools del agente, pero evitando el trigger roto desde chat.

Docs: https://docs.openclaw.ai/tools/agent-send

#

4) Cron robusto, dejando el delivery al runner

Telegram

openclaw cron add \
  --name "Telegram report" \
  --cron "0 9 * * *" \
  --session isolated \
  --message "Genera el reporte y devuelve solo el texto final." \
  --announce \
  --channel telegram \
  --to "<chat-id>"

Slack

openclaw cron add \

#

  --name "Slack report" \
  --cron "0 9 * * *" \
  --session isolated \
  --message "Genera el reporte y devuelve solo el texto final." \
  --announce \
  --channel slack \
  --to "channel:C1234567890"

Importante:

en cron no le pidas al agente “envíalo por Telegram/Slack”
pídele solo que genere el resultado
el --announce hace el delivery

Docs: https://docs.openclaw.ai/automation/cron-jobs

#

5) Workaround práctico que yo usaría

chat solo para conversar
message send para envíos urgentes
agent --deliver para tareas con tools
cron + --announce para automatizaciones

6) Dos pruebas rápidas extra

abre un chat/thread nuevo en Telegram o Slack y prueba ahí
evita auto-router mientras depuras, usa un modelo explícito en esas sesiones

Si quieres, te ayudo a convertir tu caso real a comandos concretos, por ejemplo:

“enviar resumen diario a Telegram”
“mandar reporte a Slack”

#telegram just conversational, not trigging actions

Lo más útil ahora

Qué mirar

Recomendación práctica

Dos detalles extra

Mi recomendación

Opción más directa

Por qué esta ruta

Si quieres revisar el fallo del updater

Siguiente corte, muy simple

Lo importante en logs

Otra sospecha importante

Para cron

Siguiente paso, ya sin dar más vueltas

Qué quiero ver en esos logs

Interpretación rápida

Lo que ya sabemos

Mi lectura ahora

Haz esta prueba, pero filtrando mejor

Qué necesito ver

Importante

Estás mirando el log/gateway equivocado, o tienes más de un gateway corriendo

Haz estas 3 cosas

Qué espero

Si NO sale nada del mensaje en ese log

Si SÍ sale el mensaje pero no hay tool call

Bypass total de Telegram/Slack

Qué nos dice ese resultado

Cómo leer el resultado

Interpretación

Lo que queda

Siguiente prueba útil

Telegram

Slack

Cómo leer eso

Mi lectura ahora

Lo que ya probaste

Conclusión

Mi recomendación

Título sugerido

Resumen sugerido

Workaround while tanto

Direct outbound channel send also works

Current conclusion

Mi recomendación práctica

1) Telegram, envío directo confiable

2) Slack, envío directo confiable

3) Correr el agente fuera del chat y entregar el resultado

A Telegram

A Slack

4) Cron robusto, dejando el delivery al runner

Telegram

Slack

5) Workaround práctico que yo usaría

6) Dos pruebas rápidas extra