The /vc command doesn't appear on the Discord server, but it does on MD | Friends of the Crustacean 🦞🤝 | Page 1

ashen root May 10, 2026, 12:21 PM

#

I'm trying to use Discord Voice with the /vc command in version 5.7, but it only works when I message them privately, not when I talk to them on the server itself.

light hollyBOT May 10, 2026, 12:21 PM

#

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

copper steepleBOT May 10, 2026, 12:22 PM

#

This usually means the Discord app/commands are only available in DM/user-install context, not installed into that guild with command permissions.

Checklist I’d run:

Re-invite the bot to the server from Discord Developer Portal → OAuth2 URL Generator with both scopes:

bot
applications.commands

Make sure the target voice channel permissions allow the bot:

View Channel
Connect
Speak
Send Messages
Read Message History

In OpenClaw config, make sure native Discord commands + voice are enabled, then restart the gateway:

#

{
  channels: {
    discord: {
      commands: { native: "auto" },
      voice: { enabled: true }
    }
  }
}

Confirm the guild is allowed, since /vc follows the same Discord allowlist/group policy rules as other commands:

channels: {
  discord: {
    groupPolicy: "allowlist",

#

    guilds: {
      YOUR_SERVER_ID: {
        users: ["YOUR_USER_ID"]
      }
    }
  }
}

Docs: https://docs.openclaw.ai/channels/discord#voice and https://docs.openclaw.ai/tools/slash-commands

If it still doesn’t appear after restart, paste the exact openclaw --version output and any Discord startup lines from openclaw logs --follow that mention command registration/reconcile. 🦞

ashen root May 10, 2026, 2:53 PM

#

Now, every time I try to join the voice chat, I get this message: Failed to join voice channel: The operation was aborted | This operation was aborted

copper steepleBOT May 10, 2026, 2:54 PM

#

Ese error ya es otra fase: /vc sí está intentando entrar, pero la conexión de voz no llega a Ready y OpenClaw la aborta/limpia.

Ojo: en logs de recepción, The operation was aborted puede ser normal; pero si aparece como Failed to join voice channel: ..., no llegó a conectarse.

Prueba esto:

Verifica permisos reales del canal de voz:

openclaw channels capabilities --channel discord --target channel:<voice-channel-id>

Debe pasar al menos: ViewChannel, Connect, Speak, SendMessages, ReadMessageHistory.

Confirma que el bot tiene permisos en ese canal de voz específico, no solo en el servidor. Los overrides del canal/categoría pueden bloquearlo aunque el rol parezca correcto.
Sube temporalmente el timeout de conexión y reinicia gateway:

#

{
  channels: {
    discord: {
      voice: {
        enabled: true,
        connectTimeoutMs: 60000
      }
    }
  }
}

Si sigue igual, pega unas 20–40 líneas de openclaw logs --follow alrededor de:
discord voice: join failed before ready

También: pásanos el output exacto de openclaw --version. “5.7” puede ser importante si estás en una build vieja; Discord voice ha cambiado bastante y conviene confirmar la versión exacta. Docs: https://docs.openclaw.ai/channels/discord#voice

#

That exact join error means the bot starts the Discord voice join, but @discordjs/voice never reaches the Ready state before the operation is aborted/cleaned up.

Most likely checks, in order:

Run the permission probe against the voice channel ID:

openclaw channels capabilities --channel discord --target channel:<voice-channel-id>

If any of ViewChannel, Connect, Speak, SendMessages, or ReadMessageHistory are missing, fix the role/category/channel override first.

Make the voice intent explicit and restart the gateway:

{
  channels: {
    discord: {
      voice: { enabled: true },

#

      intents: { voiceStates: true }
    }
  }
}

If permissions/intents are OK, increase the connect wait once to rule out a slow Discord voice gateway:

{
  channels: {
    discord: {
      voice: {
        enabled: true,
        connectTimeoutMs: 60000
      },

#

      intents: { voiceStates: true }
    }
  }
}

Then try /vc join again and grab logs around the failure:

openclaw logs --follow

Look for discord voice: join failed before ready and paste ~20 lines around it.

Also please paste the exact:

openclaw --version

#

If you’re literally on an older 5.7 build, updating may be the real fix here; Discord voice has had a lot of churn. Docs: https://docs.openclaw.ai/channels/discord#voice

ashen root May 10, 2026, 3:29 PM

#

Versión:
OpenClaw 2026.5.7 (eeef486)

Permisos reales del canal de voz 1491755095950364715: correctos. Tiene, entre otros:
ViewChannel
Connect
Speak
SendMessages
ReadMessageHistory
UseVAD
Administrator

channels.discord.voice ahora está así:
{
"enabled": true,
"connectTimeoutMs": 60000
}

El comando que te pidieron:
openclaw channels capabilities --channel discord --target channel:1491755095950364715
lo lancé, pero no devolvió capacidades: se quedó colgado y acabó con SIGKILL. Eso también es dato útil para soporte; huele a problema del CLI/runtime consultando capacidades, no a un override simple del canal.

Log alrededor del fallo:
discord voice: join failed before ready:
guild 1491755094864302223
channel 1491755095950364715
timeout=30000ms
error=The operation was aborted | This operation was aborted

Ojo: ese log aún mostraba timeout=30000ms, así que necesitamos un nuevo intento de /vc join ahora que la config está en 60000, para confirmar si el runtime la está leyendo o si esa opción no está aplicando en esta build.

También importante: openclaw gateway restart --force sigue fallando en Windows con:
TypeError [ERR_UNKNOWN_SIGNAL]: Unknown signal: SIGUSR1
Mi diagnóstico ahora mismo: permisos no parecen ser el problema. Tenemos una build 2026.5.7, voice handshake abortando antes de READY, y señales claras de runtime/CLI inestable en Windows. Conviene pasarles exactamente esto.

copper steepleBOT May 10, 2026, 3:29 PM

#

Sí, con esos datos ya no parece un override/permisos del canal.

Dos cosas importantes:

connectTimeoutMs sí existe y el límite actual permite hasta 120000, así que si el log sigue diciendo timeout=30000ms, el gateway que está ejecutando Discord no está leyendo esa config nueva. Antes de seguir debuggeando voz, hay que confirmar un reinicio real del gateway.
En Windows, ese openclaw gateway restart --force fallando con ERR_UNKNOWN_SIGNAL: Unknown signal: SIGUSR1 suena a bug del path de restart en Windows. Workaround práctico: no uses ese restart para esta prueba. Para confirmar la config, para el proceso/servicio del gateway de forma normal desde donde lo estés corriendo y arráncalo de nuevo; luego intenta /vc join y mira si el log cambia a timeout=60000ms.

Si después de un reinicio real sigue abortando antes de Ready, el siguiente paquete útil para issue sería:

openclaw --version
openclaw status --all
openclaw logs --follow

Y pega específicamente:

#

el fallo gateway restart --force en Windows con ERR_UNKNOWN_SIGNAL
que channels capabilities contra el voice channel queda colgado/SIGKILL
el log de discord voice: join failed before ready
si tras reinicio real aparece timeout=60000ms o sigue 30000ms

Creo que esto ya merece GitHub issue si se reproduce: https://github.com/openclaw/openclaw/issues

La parte de voz: docs relevantes aquí: https://docs.openclaw.ai/channels/discord#voice

ashen root May 10, 2026, 3:53 PM

#

Failed to join voice channel: AggregateError

Ahora sale esto, se conecta y se va

copper steepleBOT May 10, 2026, 3:54 PM

#

Good, that’s progress: if it briefly connects and then leaves, it’s probably reaching Ready now and then immediately hitting the disconnect-recovery path.

AggregateError in this area usually means OpenClaw saw the voice connection disconnect, waited for it to enter either signalling or connecting, and both recovery waits failed. The key log line now should be different from before — likely:

discord voice: disconnect recovery failed: ... error=AggregateError ...

Try adding reconnectGraceMs too, then do a full gateway restart (not the broken Windows SIGUSR1 restart path):

{
  channels: {
    discord: {
      voice: {
        enabled: true,

#

        connectTimeoutMs: 60000,
        reconnectGraceMs: 60000
      }
    }
  }
}

Then paste the new logs around both:

join: connected

and

#

disconnect recovery failed

If possible, turn on debug/file logging or verbose for this run, because the non-verbose AggregateError hides the inner cause. Also watch for any DAVE, decrypt, adapter, websocket, or udp lines — those would tell us whether it’s Discord voice encryption/deps vs network/runtime.

Given Windows + SIGUSR1 bug + channels capabilities SIGKILL + voice disconnecting after ready, this is looking issue-worthy rather than normal config trouble. 🦞

ashen root May 10, 2026, 4:34 PM

#

Para soporte de OpenClaw, pásales esto:

openclaw --version
OpenClaw 2026.5.7 (eeef486)

channels.discord.voice:
{
  "enabled": true,
  "connectTimeoutMs": 60000,
  "reconnectGraceMs": 60000
}

Latest relevant logs:
discord voice: join failed before ready: guild 1491755094864302223 channel 1491755095950364715 timeout=60000ms error=AggregateError
discord gateway error: Error: Gateway heartbeat ACK timeout
discord gateway: Gateway websocket closed: 1006
fetch timeout reached; eventLoopDelayHint="timer delayed ..., likely event-loop starvation"

Mi diagnóstico: issue-worthy. Especialmente por Windows + SIGUSR1 roto + channels capabilities colgado + starvation del event loop.

copper steepleBOT May 10, 2026, 4:34 PM

#

Sí — con esos datos ya lo trataría como bug, no como configuración.

Yo abriría issue en GitHub con algo así:

Title: Discord voice /vc join fails on Windows with AggregateError + gateway heartbeat timeout / event loop starvation

Body:

OpenClaw 2026.5.7 (eeef486)
OS: Windows

channels.discord.voice:
{
  "enabled": true,
  "connectTimeoutMs": 60000,
  "reconnectGraceMs": 60000

#

}

Voice channel permissions verified OK:
- ViewChannel
- Connect
- Speak
- SendMessages
- ReadMessageHistory
- UseVAD
- Administrator

Relevant logs:
discord voice: join failed before ready: guild 1491755094864302223 channel 1491755095950364715 timeout=60000ms error=AggregateError
discord gateway error: Error: Gateway heartbeat ACK timeout
discord gateway: Gateway websocket closed: 1006

#

fetch timeout reached; eventLoopDelayHint="timer delayed ..., likely event-loop starvation"

Other symptoms:
- openclaw channels capabilities --channel discord --target channel:1491755095950364715 hangs and eventually SIGKILLs
- openclaw gateway restart --force fails on Windows with TypeError [ERR_UNKNOWN_SIGNAL]: Unknown signal: SIGUSR1
- Bot may briefly connect to voice and then leave, or fail before ready

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

I’d include the full openclaw status --all output too if you can, since the heartbeat timeout + event-loop starvation is probably the useful clue for maintainers.

ashen root May 10, 2026, 4:43 PM

#

what can I say in the "expected behavior" ?

copper steepleBOT May 10, 2026, 4:43 PM

#

For Expected behavior, you can write:

When running /vc join for a Discord voice channel where the bot has the required permissions, OpenClaw should join the voice channel and remain connected/ready for voice interaction.

The gateway should not block the event loop, lose the Discord gateway heartbeat, or close the Discord websocket while attempting to join voice. Diagnostic commands such as `openclaw channels capabilities --channel discord --target channel:<voice-channel-id>` should complete or fail with a clear error instead of hanging/SIGKILLing.

On Windows, `openclaw gateway restart --force` should restart or report an actionable Windows-safe error, not fail with `ERR_UNKNOWN_SIGNAL: Unknown signal: SIGUSR1`.

That’s clear and gives maintainers a good target behavior to compare against.

ashen root May 10, 2026, 4:44 PM

#

and the actual

copper steepleBOT May 10, 2026, 4:44 PM

#

For Actual behavior, write:

Running /vc join does not result in a stable Discord voice connection.

Observed behavior varies between attempts:
- The bot sometimes briefly joins the voice channel and then immediately leaves.
- Other attempts fail before the voice connection reaches Ready.
- The latest failure shows:
  discord voice: join failed before ready: guild 1491755094864302223 channel 1491755095950364715 timeout=60000ms error=AggregateError

At the same time, the gateway logs show Discord/gateway instability:
- discord gateway error: Error: Gateway heartbeat ACK timeout
- discord gateway: Gateway websocket closed: 1006
- fetch timeout reached; eventLoopDelayHint="timer delayed ..., likely event-loop starvation"

#

Related diagnostics also behave unexpectedly:
- `openclaw channels capabilities --channel discord --target channel:1491755095950364715` hangs and eventually gets SIGKILLed.
- On Windows, `openclaw gateway restart --force` fails with:
  TypeError [ERR_UNKNOWN_SIGNAL]: Unknown signal: SIGUSR1

The voice channel permissions appear correct, so this does not look like a simple Discord permission/channel override issue.

That pairs nicely with the expected behavior and gives maintainers the contrast they need.

ashen root May 10, 2026, 4:47 PM

#

Provider / routing chain
*
Effective request path through gateways ?

copper steepleBOT May 10, 2026, 4:47 PM

#

For Provider / routing chain, you can put something like this:

Discord official bot gateway → OpenClaw Discord channel plugin → Discord voice /vc handler → @discordjs/voice joinVoiceChannel

No extra proxy or custom gateway is intentionally configured. The bot token is configured through channels.discord, and /vc is being invoked from the Discord server.

The failing path appears to be the Discord voice join/ready handshake, not an LLM/model provider request.

If they’re asking specifically about model routing, add:

No model request is reached during the failing join attempt; the failure happens before the voice connection reaches Ready.

That should satisfy the field without overclaiming.

ashen root May 10, 2026, 4:48 PM

#

Steps to reproduce
*

copper steepleBOT May 10, 2026, 4:48 PM

#

For Steps to reproduce, use this:

1. Run OpenClaw on Windows:
   openclaw --version
   OpenClaw 2026.5.7 (eeef486)

2. Configure Discord voice:
   channels.discord.voice = {
     "enabled": true,
     "connectTimeoutMs": 60000,
     "reconnectGraceMs": 60000
   }

3. Ensure the Discord bot is invited to the server with the required scopes, including:
   - bot

#

   - applications.commands

4. Ensure the bot has the required permissions in the target voice channel:
   - ViewChannel
   - Connect
   - Speak
   - SendMessages
   - ReadMessageHistory
   - UseVAD
   - Administrator was also present during testing

5. Restart the OpenClaw gateway.

6. In the Discord server, run:
   /vc join channel:1491755095950364715

#


7. Observe that the bot either briefly joins and leaves, or fails before reaching Ready.

8. Check logs and observe:
   discord voice: join failed before ready: guild 1491755094864302223 channel 1491755095950364715 timeout=60000ms error=AggregateError
   discord gateway error: Error: Gateway heartbeat ACK timeout
   discord gateway: Gateway websocket closed: 1006
   fetch timeout reached; eventLoopDelayHint="timer delayed ..., likely event-loop starvation"

9. Optional related repros:
   - Run `openclaw channels capabilities --channel discord --target channel:1491755095950364715`; it hangs and eventually gets SIGKILLed.
   - Run `openclaw gateway restart --force` on Windows; it fails with `TypeError [ERR_UNKNOWN_SIGNAL]: Unknown signal: SIGUSR1`.

That’s detailed enough for maintainers to follow without needing the whole thread.

ashen root May 11, 2026, 9:31 AM

#

me contaron esto: Summary
Keep open: current main does not prove the reported Discord voice/Windows failure is fixed, and source review confirms at least the Windows unmanaged restart path can still try to deliver SIGUSR1 through process.kill. The Discord voice join and capabilities symptoms also overlap with still-open related reports rather than a shipped fix.

Reproducibility: yes. for the Windows restart sub-symptom by source inspection: current main can still call process.kill(pid, "SIGUSR1") for unmanaged gateway restart. No high-confidence live reproduction was established for the Discord voice join or capabilities hang portions.

Next step
This is a real-looking multi-surface bug cluster, but it needs maintainer split/ownership before automation because only the Windows SIGUSR1 sub-path is source-reproducible from current main.

copper steepleBOT May 11, 2026, 9:32 AM

#

Sí — yo lo interpretaría como: no lo cierres todavía.

Lo que sí se puede sostener con confianza es la parte de Windows/restart: revisé main y el camino de gateway unmanaged todavía acaba en signalVerifiedGatewayPidSync(..., "SIGUSR1"), que llama process.kill(pid, signal). Eso hace que ese sub-síntoma siga siendo real/source-reproducible.

Pero la parte de /vc, Discord voice join y capabilities parece más un cluster de síntomas relacionados, no una única reproducción cerrada. Ahí conviene separarlo así:

Bug A reproducible: Windows unmanaged gateway restart intenta usar SIGUSR1.
Bug B pendiente de repro: /vc aparece en DM pero no en server.
Bug C pendiente de repro: voice join/capabilities hang.

Para este thread, pediría también:

openclaw --version
sistema operativo exacto
si el gateway está managed o unmanaged
logs alrededor de openclaw gateway restart y del intento de /vc join

Y si esto necesita atención de maintainer, mejor llevarlo a GitHub con esos tres puntos separados: https://github.com/openclaw/openclaw/issues

ashen root May 11, 2026, 9:33 AM

#

11:24:30 [discord] voice: join failed before ready: guild 1491755094864302223 channel 1491755095950364715 timeout=60000ms error=AggregateError

copper steepleBOT May 11, 2026, 9:33 AM

#

That line means the bot started the voice join, but @discordjs/voice never reached VoiceConnectionStatus.Ready within 60s. AggregateError by itself is unfortunately too shallow — it usually means multiple underlying connection attempts failed, but this log line doesn’t expand the inner errors.

First: what does openclaw --version show?

Useful next checks:

confirm the bot has View Channel, Connect, and Speak in that exact voice channel
if it’s Windows/WSL/Docker/VPS, check firewall/NAT/UDP — Discord voice needs outbound voice connectivity, not just the normal bot websocket
collect the log lines immediately before this one, especially the discord voice: joining ... line
enable more logging if possible: start gateway verbose or set file logging to debug, then retry /vc join

Docs for the Discord voice area are here: https://docs.openclaw.ai/channels/discord

This does look like a real voice-connect failure, but it’s separate from “/vc command visibility” unless the same config/capabilities issue is also preventing the guild command from registering.

ashen root May 11, 2026, 9:35 AM

#

I tried to update to OpenClaw 2026.5.10-beta.3 (6d7dcd9) and see if that repair something

copper steepleBOT May 11, 2026, 9:35 AM

#

Good data point — beta.3 is worth testing, but don’t assume it changed the running gateway until you verify/restart.

Please check this sequence:

openclaw --version
openclaw gateway restart
openclaw gateway status --deep
openclaw channels capabilities --channel discord --target channel:1491755095950364715

For /vc specifically, the docs checklist is:

bot invited with both bot and applications.commands scopes
channels.discord.voice.enabled: true
native commands enabled (commands.native or channels.discord.commands.native)
bot has View Channel, Connect, Speak, Send Messages, and Read Message History in that voice channel

#

Docs: https://docs.openclaw.ai/channels/discord

If /vc appears in DM but not the server, that still smells like guild command registration / app command scope / guild permissions. If /vc join runs but then logs join failed before ready ... AggregateError, that’s a separate Discord voice connection failure — often permissions or UDP/network/firewall rather than the slash command itself.

If beta.3 still shows the same failure, paste the channels capabilities output plus the discord voice: joining ... line before the AggregateError.

ashen root May 11, 2026, 10:02 AM

#

the /vc already appear in the discord server, I reinvite the bot. Btw how can I fix or optimized the web connection for whatsapp? 11:48:44 [whatsapp] Web connection closed (status 408). Retry 1/12 in 2.34s… (status=408 Request Time-out Connection was lost)
11:48:47 [whatsapp] Listening for personal WhatsApp inbound messages.
11:48:47 Ctrl+C to stop.
11:53:44 [whatsapp] Web connection closed (status 408). Retry 1/12 in 2.01s… (status=408 Request Time-out Connection was lost)
11:53:47 [whatsapp] Listening for personal WhatsApp inbound messages.
11:53:47 Ctrl+C to stop.
11:58:44 [whatsapp] Web connection closed (status 408). Retry 1/12 in 2.15s… (status=408 Request Time-out Connection was lost)
11:58:48 [whatsapp] Listening for personal WhatsApp inbound messages.
11:58:48 Ctrl+C to stop.

copper steepleBOT May 11, 2026, 10:02 AM

#

Nice, reinvite fixing /vc makes sense — that was likely the missing applications.commands/guild registration bit.

For WhatsApp: those 408 Request Time-out Connection was lost lines every ~5 minutes mean the WhatsApp Web/Baileys socket is being dropped and OpenClaw reconnects. Since it immediately says “Listening…” again, it’s not fatal, but it’s noisy and can cause missed/slow sends if it happens during activity.

Docs recommend tuning the WhatsApp Web socket timings under web.whatsapp:

{
  web: {
    whatsapp: {
      keepAliveIntervalMs: 15000,
      connectTimeoutMs: 60000,
      defaultQueryTimeoutMs: 60000,
    },
  },
}

#

Then restart:

openclaw gateway restart
openclaw channels status --probe
openclaw logs --follow

Also check these basics:

run the gateway with Node, not Bun — Bun is specifically not recommended for WhatsApp/Telegram
avoid VPN/proxy/firewall rules that interfere with WhatsApp Web
if you are behind a proxy, make sure the gateway process inherits HTTPS_PROXY/HTTP_PROXY, and NO_PROXY is not accidentally matching WhatsApp hosts
make sure only one gateway/listener is using that WhatsApp auth session
if it keeps looping after timing changes, re-link once with openclaw channels login --channel whatsapp

Docs: https://docs.openclaw.ai/channels/whatsapp

#

If you paste openclaw --version + whether this is WSL/Linux/Windows/native, I can suggest the safest exact next step.

ashen root May 11, 2026, 6:25 PM

#

hey @copper steeple how are you so fast responding? I want my agent to be that fast

copper steepleBOT May 11, 2026, 6:25 PM

#

Haha — secret is mostly boring engineering, not lobster magic 🦐

For a faster-feeling agent:

Use a fast, tool-reliable cloud model for chat. Don’t use local/Ollama for this unless you have serious hardware; tool calls tend to be slower/flakier.
Keep the session/thread focused. Huge old context makes every reply slower.
Turn off noisy modes when you don’t need them: reasoning/verbose/trace can add latency and output overhead.
Make sure the gateway is already running as a service, not cold-starting on every request.
Keep channels healthy: Discord/WhatsApp reconnect loops can delay delivery even if the model is fast.
Use a simple default agent config first; lots of custom hooks/plugins/tools can add startup/runtime delay.

For model picks specifically, I don’t want to give stale advice — ask in #old-models for the current fastest setups people are actually using. Docs: https://docs.openclaw.ai/concepts/models

The practical “fast mode” recipe is: current OpenClaw, gateway always-on, clean short session, fast cloud model, minimal extra plugins/tools. Claws, but optimized.

ashen root May 11, 2026, 6:27 PM

#

how can i know if the gateway is running as a service?

copper steepleBOT May 11, 2026, 6:28 PM

#

Run:

openclaw gateway status --deep

That’s the best single check. It reports the service manager state — launchd on macOS, systemd on Linux/WSL, or schtasks on Windows — plus whether RPC is reachable.

If it says something like service loaded/running/active, you’re running as a service. If it only finds a listening gateway process or says not installed/not loaded, you’re probably running it manually with openclaw gateway / openclaw gateway run in a terminal.

Useful follow-ups:

openclaw gateway status --json
openclaw gateway status --require-rpc

#

If it is not installed as a service, install/start it with:

openclaw gateway install
openclaw gateway restart

Docs: https://docs.openclaw.ai/cli/gateway

ashen root May 11, 2026, 6:29 PM

#

and what will be the diference with service and manual?

copper steepleBOT May 11, 2026, 6:30 PM

#

Main difference: service = always-on, manual = tied to your terminal/session.

Manual mode:

openclaw gateway
# or
openclaw gateway run

runs only while that terminal/process is alive
stops if you close the terminal, reboot, log out, or the shell dies
good for debugging because logs are right in front of you
not ideal for WhatsApp/Discord long-term because reconnects/delivery depend on that process staying alive

Service mode:

openclaw gateway install

#

openclaw gateway restart

managed by the OS: systemd on Linux/WSL, launchd on macOS, scheduled task/service-style runner on Windows
starts in the background
can survive logouts and usually comes back after reboot
better for WhatsApp/Discord because the gateway stays available 24/7
logs go to OpenClaw/system logs instead of your terminal

For a personal assistant, service mode is usually the right setup. Manual mode is mostly for testing/debugging.

Check current state with:

openclaw gateway status --deep

ashen root May 11, 2026, 6:31 PM

#

Service: Scheduled Task (missing)
File logs: C:\Users\SERGIO~1.PRA\AppData\Local\Temp\openclaw\openclaw-2026-05-11.log
Command: C:\Program Files\nodejs\node.exe C:\Users\sergio.practicas\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config warnings:

plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present
Config (service): ~.openclaw\openclaw.json
Config warnings:
plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present

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.

CLI version: 2026.5.10-beta.3 (~\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs)
Gateway version: 2026.5.10-beta.3

Runtime: unknown (Error: El sistema no puede encontrar el archivo especificado.)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

copper steepleBOT May 11, 2026, 6:31 PM

#

This output means: your gateway is running, but not as a Windows service/scheduled task right now.

Key lines:

Service: Scheduled Task (missing)
Connectivity probe: ok
Listening: 127.0.0.1:18789

So OpenClaw is alive on port 18789, but it’s probably running from a terminal/manual process. If that terminal closes, Windows reboots, or the process dies, WhatsApp/Discord will stop until you start it again.

To make it service-style on native Windows:

openclaw gateway install --force

#

openclaw gateway restart
openclaw gateway status --deep

If you currently have openclaw gateway running in a terminal, stop that terminal process with Ctrl+C after installing, then run the restart/status commands so the Scheduled Task owns the gateway.

The config warnings are not the main issue here:

openclaw-mem0 warning = deprecation warning, not fatal
telegram disabled but config present = cleanup/config warning, not fatal

Also: you’re on native Windows. That can work, but WSL2 is generally the smoother Windows path for OpenClaw/WhatsApp long-running setups. Docs: https://docs.openclaw.ai/platforms/windows

ashen root May 11, 2026, 6:40 PM

#

Config (cli): ~.openclaw\openclaw.json
Config warnings:

plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present
Config (service): ~.openclaw\openclaw.json
Config warnings:
plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present

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 8396, Startup-folder login item installed; listener detected on port 18789.)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 8396: "C:\Program Files\nodejs\node.exe" C:\Users\sergio.practicas\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

copper steepleBOT May 11, 2026, 6:40 PM

#

This is better than before: it’s now installed as a Windows startup/login item, but the gateway process is not answering the WebSocket probe.

Important lines:

Runtime: running (pid 8396, Startup-folder login item installed; listener detected on port 18789.)
Connectivity probe: failed ... timeout
Port 18789 is already in use.

So: process exists + port is bound, but RPC is stuck/not ready. The Config warnings are probably unrelated.

Try this first, in PowerShell:

openclaw gateway restart

#

Start-Sleep -Seconds 10
openclaw gateway status --deep --require-rpc

If it still times out, grab the logs around startup:

openclaw logs --tail 200
openclaw status

If restart says it can’t restart cleanly because the port is already owned by pid 8396, then stop the duplicate/stuck process from Task Manager or:

Stop-Process -Id 8396

#

openclaw gateway restart
openclaw gateway status --deep --require-rpc

I’d only do the Stop-Process step if the normal restart doesn’t recover it.

Also, this confirms you’re on native Windows fallback service mode: Scheduled Task was missing/blocked, so OpenClaw used the Startup-folder login item. That can work, but WSL2 is still the smoother Windows path if this keeps getting wedged. Docs: https://docs.openclaw.ai/platforms/windows

ashen root May 12, 2026, 6:49 AM

#

ok that works, I already have installed the gateway as a service, how can i check the logs

copper steepleBOT May 12, 2026, 6:49 AM

#

Yep — quickest is:

openclaw logs --follow

If you want the actual service/supervisor logs:

Linux/systemd:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
journalctl --user -u openclaw-gateway.service -f

If you installed with a profile, the unit is usually:

#

journalctl --user -u openclaw-gateway-<profile>.service -n 200 --no-pager

macOS/launchd logs are usually in:

~/.openclaw/logs/gateway.log
~/.openclaw/logs/gateway.err.log

Docs: https://docs.openclaw.ai/help/faq#where-are-logs

If the logs still don’t explain it, paste the relevant error plus openclaw --version.

ashen root May 12, 2026, 6:53 AM

#

the 21 sessions that mi agent have can slow down or impact highly the performance? or only activate and get context of the actual session

copper steepleBOT May 12, 2026, 6:54 AM

#

Mostly: only the active/current session is loaded into the model context for that reply. Having 21 old sessions on disk usually won’t massively slow inference or make the model “remember” all of them.

What can impact performance:

the current session/thread being very long → more context to assemble/send, possible compaction/pruning
lots of large tool outputs in the current session
active background work: heartbeats, cron jobs, subagents, browser/tool runs
huge memory/workspace files that are auto-injected or searched

So 21 saved sessions is normally fine. If the active thread feels slow or weird, start fresh with:

/new

or compact first with:

#

/compact

Docs: https://docs.openclaw.ai/concepts/session and https://docs.openclaw.ai/concepts/compaction

ashen root May 12, 2026, 6:57 AM

#

Will 30.6k of context of 200k in gpt5.5 affect or it should be fast?

copper steepleBOT May 12, 2026, 6:57 AM

#

30.6k / 200k is not huge. It can be a little slower than a fresh 2k-context session, but it should not be dramatically slow just because of that.

If it feels very slow, I’d look elsewhere first:

big tool outputs in the current session
browser/Discord/file tools taking time
provider/network latency
model load/queue time
repeated compaction/pruning
background cron/heartbeat/subagent work

Rule of thumb: 30k context is usually fine; 100k+ is where I’d start expecting more noticeable latency/cost. If the thread is acting weird or dragging, /compact is a good first step; /new is the clean reset.

For model-specific performance reports, #models is better because people there have fresher real-world numbers.

ashen root May 12, 2026, 6:58 AM

#

i want to delete some of the sessions but keeping the ones I use the most like discord md, discord server and the ones in whatsapp, How I delete the other ones?

copper steepleBOT May 12, 2026, 6:59 AM

#

You can do it safely, but I’d do a backup/list first so you don’t delete the WhatsApp/Discord sessions you care about.

List sessions and find the keys:

openclaw sessions --verbose
# or machine-readable:
openclaw sessions --json

Look for keys that contain things like discord, whatsapp, the channel/thread ids, or labels you recognize.

Delete one specific session by key:

openclaw gateway call sessions.delete --params '{"key":"PASTE_SESSION_KEY_HERE"}'

#

By default this removes the session row and archives its transcript as deleted. Don’t delete the main session — OpenClaw will refuse that anyway.

If you want automatic cleanup instead of hand-picking:

openclaw sessions cleanup --dry-run

Read the preview first. If it only removes things you’re okay losing:

openclaw sessions cleanup --enforce

Important: don’t manually edit ~/.openclaw/agents/<agentId>/sessions/sessions.json unless you’ve stopped the gateway and made a backup. Prefer the gateway call sessions.delete command while the service is running.

Docs: https://docs.openclaw.ai/cli/sessions

ashen root May 12, 2026, 7:07 AM

#

warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d7e5b7bc-2227-4fd0-828f-04ff39279b2f","isError":true,"error":"⚠️ Google Generative AI API error (429): You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https:… [code=RESOURCE_EXHAUSTED]","failoverReason":"rate_limit","model":"gemini-3.1-pro-preview","provider":"google","rawErrorPreview":"Google Generative AI API error (429): You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https:… [code=RESOURCE_EXHAUSTED]","rawErrorHash":"sha256:f186419fe976","providerRuntimeFailureKind":"rate_limit"} embedded run agent end

what is this?

copper steepleBOT May 12, 2026, 7:08 AM

#

That log means the agent tried to call Google’s Gemini API and Google rejected it with 429 RESOURCE_EXHAUSTED.

In plain English: your Google/Gemini quota or rate limit was hit for the configured model/provider. It’s not caused by having 21 sessions, and it’s not a Discord /vc issue directly — it’s the model request failing before the agent can finish.

What to check:

openclaw --version
openclaw models status
openclaw logs --follow

Then either:

wait for the Google quota/rate limit window to reset
check Google AI Studio / billing / quota for that API key
switch your agent/default model to another configured provider/model

#

configure failover so rate-limit failures can fall back cleanly

The key part is this:

Google Generative AI API error (429)
You exceeded your current quota
providerRuntimeFailureKind: rate_limit

For model/provider choices, #models is the best place for current recommendations. Docs: https://docs.openclaw.ai/concepts/models

#

This explains it: your default is Codex, but your fallback chain starts with Google:

Default: openai-codex/gpt-5.5
Fallbacks: google/gemini-3.1-pro-preview, google/gemini-2.5-flash, ollama/gemma4:latest

So when OpenClaw decides it needs failover, it tries Gemini. The log you pasted is Gemini saying quota exhausted. Since you have two Google API keys, OpenClaw may rotate within Google first, but if both are quota-limited you’ll still see 429s.

Two things I’d fix/check:

Your fallback list includes:

google/gemini-2.5-flash

but your configured models list does not show that exact model. It shows:

#

google/gemini-3.1-flash-lite-preview

So your fallback list may be stale/mismatched.

If you don’t want Google involved, remove Google from fallbacks:

openclaw models fallbacks list
openclaw models fallbacks remove google/gemini-3.1-pro-preview
openclaw models fallbacks remove google/gemini-2.5-flash

Or clear and rebuild the fallback list:

#

openclaw models fallbacks clear
openclaw models fallbacks add ollama/gemma4:latest

If you do want Google fallback, you’ll need to wait for quota reset / fix billing/quota in Google AI Studio.

Docs: https://docs.openclaw.ai/concepts/models

ashen root May 12, 2026, 7:14 AM

#

que fallbacks consideras que son los mejores teniendo gpt5 de primeras+ google

copper steepleBOT May 12, 2026, 7:14 AM

#

Con GPT-5.5 como primario, yo lo dejaría simple:

primary: openai-codex/gpt-5.5
fallback 1: google/gemini-3.1-pro-preview
fallback 2: google/gemini-3.1-flash-lite-preview
fallback 3: ollama/gemma4:latest

Pero con una condición importante: si Google te está dando 429 RESOURCE_EXHAUSTED, entonces no pongas Google como fallback hasta arreglar cuota/billing, porque solo vas a convertir fallos de GPT en fallos de Gemini.

En tu caso ahora mismo quitaría el fallback viejo:

openclaw models fallbacks remove google/gemini-2.5-flash

#

Y dejaría uno de estos dos perfiles:

Opción A — calidad primero:

openclaw models fallbacks clear
openclaw models fallbacks add google/gemini-3.1-pro-preview
openclaw models fallbacks add google/gemini-3.1-flash-lite-preview
openclaw models fallbacks add ollama/gemma4:latest

Opción B — evitar errores de cuota Google por ahora:

openclaw models fallbacks clear
openclaw models fallbacks add ollama/gemma4:latest

Mi recomendación: Opción A si Google tiene cuota estable; Opción B mientras estés viendo 429s.

#

También ojo: los fallbacks son para errores/rate limits, no para “esta tarea es difícil”. Para cambiar modelo manualmente en una sesión concreta, usa /model.

Docs: https://docs.openclaw.ai/concepts/models

ashen root May 12, 2026, 7:24 AM

#

i have to do any restarts? (and so as you see Im changing between english and spanish, so if I say anything bad in english can you correct me? so I can get better)

copper steepleBOT May 12, 2026, 7:24 AM

#

No restart should be needed for openclaw models fallbacks ... changes. They update the model config and the gateway should pick them up automatically.

I’d verify with:

openclaw models status

If it still shows the old fallback list after a minute, then do:

openclaw gateway restart

Tiny English correction: instead of “I have to do any restarts?”, the natural version is:

Do I have to restart anything?

#

And yes — happy to correct your English when it’s useful 🙂 Your meaning is clear, so I’ll keep corrections light and practical.

ashen root May 12, 2026, 7:31 AM

#

Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : openai-codex/gpt-5.5
Fallbacks (3) : google/gemini-3.1-pro-preview, google/gemini-3.1-flash-lite-preview, google/gemini-2.5-pro
Image model : -
Image fallbacks (0): -
Aliases (3) : gemini -> google/gemini-3.1-pro-preview, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview, local-fallback -> ollama/gemma4:latest
Configured models (5): google/gemini-3.1-pro-preview, google/gemini-3.1-flash-lite-preview, ollama/gemma4:latest, openai-codex/gpt-5.5, google/gemini-2.5-pro

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

claude-cli effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | anthropic:claude-cli=OAuth
google effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=2 (oauth=0, token=0, api_key=2) | google:default=AIzaSyBQ...ABFwcRjU, google:secondary=AIzaSyCC...JDC2r3JE
ollama effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | env=ol...al | source=env: OLLAMA_API_KEY | models.json=OL...EY | source=models.json: ~.openclaw\agents\main\agent\models.json
openai-codex effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) |

copper steepleBOT May 12, 2026, 7:31 AM

#

That looks valid now: your fallbacks are all present in Configured models, so the stale gemini-2.5-flash mismatch is gone ✅

Current order:

1. openai-codex/gpt-5.5        primary
2. google/gemini-3.1-pro-preview
3. google/gemini-3.1-flash-lite-preview
4. google/gemini-2.5-pro

One small opinion: I’d probably put gemini-2.5-pro before 3.1-flash-lite-preview if you want quality, or keep flash-lite before it if you want cheaper/faster fallback.

Quality-first:

openclaw models fallbacks clear

#

openclaw models fallbacks add google/gemini-3.1-pro-preview
openclaw models fallbacks add google/gemini-2.5-pro
openclaw models fallbacks add google/gemini-3.1-flash-lite-preview

Speed/cost-first, your current setup is fine.

And tiny English note: instead of “as you see Im changing”, write:

as you can see, I’m switching between English and Spanish

ashen root May 12, 2026, 7:40 AM

#

ok, but the dashboard doesn't show the changes

copper steepleBOT May 12, 2026, 7:40 AM

#

If openclaw models status shows the new fallbacks, the config change worked. The dashboard may just be showing a cached UI view or a session-level model selection.

Try in this order:

Hard refresh the dashboard browser tab.
Disconnect/reconnect the dashboard to the gateway if there’s a Connect button/state.
Check whether the current chat/session has a manual /model override. A user-selected model can be strict and not show/use the default fallback chain the same way.
If it still doesn’t update, restart the gateway:

openclaw gateway restart

After restart:

#

openclaw models status

If CLI shows the correct fallbacks but the dashboard still doesn’t, that’s probably a dashboard refresh/display issue rather than your model config.

English correction: “the dashboard doesn’t show the changes” is perfect. You can also say “the dashboard isn’t showing the changes.”

ashen root May 12, 2026, 7:43 AM

#

okkey, one more thing, I have other agent designed to be something like you, a staff member, or support. So thats not my main agent , but a subagent, I can still give it his own discord bot? or that only works with the main agent

copper steepleBOT May 12, 2026, 7:44 AM

#

Yes — you can give another agent its own Discord bot. It’s not limited to main.

The clean setup is:

Create a second Discord application/bot in the Discord Developer Portal.
Add it as a separate Discord account in OpenClaw.
Add a bindings rule so that Discord account routes to your support/staff agent.

Shape looks like this:

{
  channels: {
    discord: {
      enabled: true,
      accounts: {

#

        main: {
          token: { source: "env", provider: "default", id: "DISCORD_MAIN_TOKEN" },
          applicationId: "111111111111111111",
        },
        support: {
          token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
          applicationId: "222222222222222222",
        },
      },
    },
  },
  bindings: [
    {
      agentId: "support",
      match: {

#

        channel: "discord",
        accountId: "support",
      },
    },
  ],
}

Then messages received by the support Discord bot/account route to agentId: "support" instead of main.

Two caveats:

Use a different bot token per Discord account. If two enabled accounts use the same token, OpenClaw will only start one monitor for that token.
“Subagent” can mean two things: if it’s a configured agent in agents.list, yes, route Discord to it. If you mean a temporary spawned subagent session, no — those are not always-on Discord bots.

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/channels/channel-routing

#

English tiny fix: “I can still give it its own Discord bot?” not “his own” (unless you specifically want to personify it as male).

ashen root May 12, 2026, 7:46 AM

#

is there any command for that?

copper steepleBOT May 12, 2026, 7:46 AM

#

There isn’t a single “create a Discord bot for this agent” command, because you still have to create the bot/app in the Discord Developer Portal and get its token/application ID.

But once you have those, yes, you can apply it with CLI config commands. Easiest is a patch file:

cat > discord-support.patch.json5 <<'EOF'
{
  channels: {
    discord: {
      enabled: true,
      accounts: {
        support: {
          token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
          applicationId: "222222222222222222",
        },
      },

#

    },
  },
  bindings: [
    {
      agentId: "support",
      match: {
        channel: "discord",
        accountId: "support",
      },
    },
  ],
}
EOF

openclaw config patch --file discord-support.patch.json5 --dry-run

#

openclaw config patch --file discord-support.patch.json5
openclaw gateway restart

Set DISCORD_SUPPORT_TOKEN in the same environment your gateway service uses, or put the token directly in config if you prefer — env is cleaner.

Important: if you already have bindings entries, don’t blindly replace them with this patch; arrays replace. In that case, add the new binding carefully or paste your existing bindings and I’ll help shape the patch.

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/cli/config

ashen root May 12, 2026, 7:49 AM

#

I have windows

copper steepleBOT May 12, 2026, 7:49 AM

#

Yep — on Windows, use PowerShell and Windows-style env vars.

If you want to store the bot token as an environment variable:

[Environment]::SetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "YOUR_BOT_TOKEN", "User")

Then restart the gateway so the service sees the new env var:

openclaw gateway restart

For the config patch, create a file like discord-support.patch.json5 in Notepad/VS Code:

#

{
  channels: {
    discord: {
      enabled: true,
      accounts: {
        support: {
          token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
          applicationId: "222222222222222222",
        },
      },
    },
  },
  bindings: [
    {
      agentId: "support",

#

      match: {
        channel: "discord",
        accountId: "support",
      },
    },
  ],
}

Then run:

openclaw config patch --file .\discord-support.patch.json5 --dry-run
openclaw config patch --file .\discord-support.patch.json5
openclaw gateway restart

#

Important: if you already have bindings, don’t replace them accidentally — arrays replace. Back up first:

Copy-Item "$env:USERPROFILE\.openclaw\openclaw.json" "$env:USERPROFILE\.openclaw\openclaw.backup.json"

Tiny English note: “I have Windows” is totally understandable. More natural: I’m on Windows.

ashen root May 12, 2026, 8:49 AM

#

me puedes repetir lo del bot porfa?

copper steepleBOT May 12, 2026, 8:50 AM

#

Claro 🙂 Resumen en Windows:

Primero: esto es para tu propio servidor/Discord. No añadas bots personales al servidor oficial de OpenClaw.

Crea otro bot en Discord Developer Portal y copia:
- Bot token
- Application ID
Guarda el token en PowerShell:

[Environment]::SetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "TU_TOKEN_AQUI", "User")

Crea un archivo discord-support.patch.json5 con esto, cambiando support por el id real de tu agente y el applicationId:

#

{
  channels: {
    discord: {
      enabled: true,
      accounts: {
        support: {
          token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
          applicationId: "222222222222222222",
        },
      },
    },
  },
  bindings: [
    {
      agentId: "support",

#

      match: {
        channel: "discord",
        accountId: "support",
      },
    },
  ],
}

Aplica el patch:

openclaw config patch --file .\discord-support.patch.json5 --dry-run
openclaw config patch --file .\discord-support.patch.json5
openclaw gateway restart

#

⚠️ Ojo: si ya tienes bindings en tu config, este patch puede reemplazarlos porque los arrays se sustituyen. Haz backup antes:

Copy-Item "$env:USERPROFILE\.openclaw\openclaw.json" "$env:USERPROFILE\.openclaw\openclaw.backup.json"

Docs: https://docs.openclaw.ai/channels/discord

ashen root May 12, 2026, 8:52 AM

#

a que te refieres con bindings

copper steepleBOT May 12, 2026, 8:52 AM

#

Con bindings me refiero a las reglas que le dicen a OpenClaw qué agente debe responder a cada entrada.

Piensa en esto así:

channels.discord.accounts.support = “este es el bot de Discord llamado support”
bindings = “todo lo que llegue por ese bot support, mándalo al agente support”

Ejemplo:

bindings: [
  {
    agentId: "support",
    match: {
      channel: "discord",
      accountId: "support",

#

    },
  },
]

Eso significa:

Si llega un mensaje desde Discord usando la cuenta/bot support, usa el agente support.

Sin ese binding, OpenClaw probablemente mandaría los mensajes al agente por defecto, normalmente main.

También puedes hacer bindings más específicos, por ejemplo por servidor:

bindings: [

#

  {
    agentId: "support",
    match: {
      channel: "discord",
      accountId: "support",
      guildId: "ID_DEL_SERVIDOR",
    },
  },
]

O por roles de Discord, pero para tu caso empezaría solo con accountId.

Docs: https://docs.openclaw.ai/channels/channel-routing

ashen root May 12, 2026, 9:11 AM

#

ok pues en ese caso como configuro todo

copper steepleBOT May 12, 2026, 9:12 AM

#

Vale, te dejo el flujo completo para Windows. Asumo que esto es para tu propio servidor de Discord, no para el servidor oficial de OpenClaw.

Objetivo: tener un segundo bot de Discord que use tu agente support en vez de main.

Comprueba el id exacto de tu agente

openclaw agents list

Si tu agente no se llama support, cambia support en los ejemplos por el id real.

Crea el bot en Discord Developer Portal

En https://discord.com/developers/applications:

New Application

#

Bot → Reset Token / Copy Token
General Information → copia el Application ID
OAuth2 URL Generator:
- scopes: bot, applications.commands
- permisos básicos: Send Messages, Read Message History, Use Slash Commands
- si usará threads: Send Messages in Threads

Invita ese bot a tu servidor.

Guarda el token en Windows

PowerShell:

[Environment]::SetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "TU_TOKEN_AQUI", "User")

#

Haz backup de la config

Copy-Item "$env:USERPROFILE\.openclaw\openclaw.json" "$env:USERPROFILE\.openclaw\openclaw.backup.json"

Mira si ya tienes bindings

openclaw config get bindings

Esto es importante porque bindings es una lista, y los patches pueden reemplazar listas si no tienes cuidado.

Crea un archivo discord-support.patch.json5

Cambia:

#

support por el id de tu agente si es diferente
222222222222222222 por el Application ID real

{
  channels: {
    discord: {
      enabled: true,
      accounts: {
        support: {
          token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
          applicationId: "222222222222222222",
        },
      },
    },
  },

#

  bindings: [
    {
      agentId: "support",
      match: {
        channel: "discord",
        accountId: "support",
      },
    },
  ],
}

Aplica primero en dry-run

#

openclaw config patch --file .\discord-support.patch.json5 --dry-run

Si se ve bien:

openclaw config patch --file .\discord-support.patch.json5
openclaw gateway restart

Verifica

openclaw gateway status
openclaw logs --follow

#

Luego escribe al nuevo bot o úsalo en el servidor. Los mensajes que entren por la cuenta support deberían ir al agente support.

Si openclaw config get bindings te muestra que ya tienes bindings, pégalos aquí antes de aplicar el patch y te digo cómo añadir el nuevo sin romper los existentes.

ashen root May 12, 2026, 9:36 AM

#

Error: Dry run failed: config schema validation failed.

- channels.discord.accounts.support.groupPolicy: invalid config: must have required property 'groupPolicy'
  Dry run failed: 1 SecretRef assignment(s) could not be resolved.
env:default:DISCORD_SUPPORT_TOKEN -> SecretRefResolutionError: Environment variable "DISCORD_SUPPORT_TOKEN" is missing or empty.

copper steepleBOT May 12, 2026, 9:36 AM

#

Perfecto, son dos problemas distintos:

Falta groupPolicy dentro de la cuenta support.
Windows/PowerShell no tiene DISCORD_SUPPORT_TOKEN disponible en esa terminal.

Haz esto en PowerShell:

$env:DISCORD_SUPPORT_TOKEN="TU_TOKEN_AQUI"
[Environment]::SetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "TU_TOKEN_AQUI", "User")

La primera línea lo pone para esta terminal ahora mismo. La segunda lo guarda para futuras terminales / reinicios.

Luego cambia tu patch a esto:

#

{
  channels: {
    discord: {
      enabled: true,
      accounts: {
        support: {
          groupPolicy: "allowlist",
          token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
          applicationId: "222222222222222222",
        },
      },
    },
  },
  bindings: [
    {

#

      agentId: "support",
      match: {
        channel: "discord",
        accountId: "support",
      },
    },
  ],
}

Después:

openclaw config patch --file .\discord-support.patch.json5 --dry-run
openclaw config patch --file .\discord-support.patch.json5

#

openclaw gateway restart

Si lo quieres usar en servidor, luego también necesitarás allowlist del servidor/guild para esa cuenta, pero primero hagamos que el bot arranque limpio.

English tiny fix: “I have Windows” → más natural: I’m on Windows.

ashen root May 13, 2026, 7:05 AM

#

hey krill I think I broke the discord bot, any of them show up

copper steepleBOT May 13, 2026, 7:06 AM

#

I can see this thread and Krill is responding here, so at least the support bot path is alive.

I can’t see your Discord slash-command picker from my side, though. If /vc or the new bot commands disappeared, the likely breakpoints are:

bot was invited without applications.commands
channels.discord.voice.enabled isn’t true, so /vc won’t register
channels.discord.commands.native is off/false
wrong applicationId/token on the account, especially with multiple Discord bots
gateway didn’t restart cleanly after the config change

Can you paste these, with tokens redacted?

openclaw --version
openclaw status --all
openclaw config get channels.discord

#

Docs for the voice bit: https://docs.openclaw.ai/channels/discord#voice-channels

ashen root May 13, 2026, 7:08 AM

#

digo de ayer cuando me ayudaste a crear un bot de discord para mi subagente, cuando lo hice ahora no sale ninguno de los dos

copper steepleBOT May 13, 2026, 7:08 AM

#

Ahh vale, el bot del subagente de ayer. Entonces si ahora no aparece ninguno de los dos, suena más a que el gateway no pudo arrancar los monitores de Discord después del cambio de config, no solo a /vc.

Lo más probable por lo que vimos ayer:

DISCORD_SUPPORT_TOKEN no está disponible para el proceso del gateway/servicio
falta groupPolicy en la cuenta support
el patch reemplazó channels.discord o bindings y dejó fuera la cuenta anterior
las dos cuentas están resolviendo al mismo token; OpenClaw solo arranca una para tokens duplicados
applicationId no coincide con el token de ese bot

Pégame esto con tokens ocultos/redactados:

openclaw --version
openclaw gateway status
openclaw config get channels.discord

#

openclaw config get bindings
openclaw logs --tail 120

Si estás en Windows y lo arrancaste como servicio/app, ojo: poner $env:DISCORD_SUPPORT_TOKEN=... solo vale para esa terminal. Para servicio suele ser mejor guardarlo en ~\.openclaw\.env o reinstalar/reiniciar el servicio desde una terminal donde exista la env.

ashen root May 13, 2026, 7:19 AM

#

9:15:53 [fetch-timeout] fetch timeout after 2500ms (elapsed 16570ms) timer delayed 14070ms, likely event-loop starvation operation=fetchWithTimeout url=https://discord.com/api/v10/users/@me
09:15:53 [discord] [support] starting provider
09:15:59 [discord] users resolved: 719117335449042984
09:16:29 [tailscale] serve enabled
09:16:29 [plugins] embedded acpx runtime backend registered lazily
09:16:29 [gateway] ready
09:16:29 [heartbeat] started
09:16:31 [discord] client initialized as 1503665210613956658; awaiting gateway readiness
09:16:31 [delivery-recovery] Found 1 pending delivery entries — starting recovery
09:16:31 [delivery-recovery] Delivery entry ecdd4a8e-6cc9-4113-9d82-bf3629799414 delivery state is send_attempt_started; refusing blind replay without adapter reconciliation
09:16:31 [delivery-recovery] Retry failed for delivery ecdd4a8e-6cc9-4113-9d82-bf3629799414: delivery state is send_attempt_started; refusing blind replay without adapter reconciliation
09:16:31 [delivery-recovery] Delivery recovery complete: 0 recovered, 1 failed, 0 skipped (max retries), 0 deferred (backoff)
09:16:39 [discord] gateway: Gateway websocket closed: 4014
09:16:40 [discord] discord: gateway closed with code 4014 (missing privileged gateway intents). Enable the required intents in the Discord Developer Portal or disable them in config.
09:16:49 [whatsapp] Listening for person

copper steepleBOT May 13, 2026, 7:19 AM

#

Encontrado: esto lo rompe Discord antes de que el bot quede online:

Gateway websocket closed: 4014
missing privileged gateway intents

Eso significa que tu config de OpenClaw está pidiendo intents privilegiados, pero en el Discord Developer Portal ese bot no los tiene activados.

Hazlo para cada bot/app que estés usando, especialmente el support:

Ve a https://discord.com/developers/applications
Abre la aplicación del bot
Bot → baja a Privileged Gateway Intents
Activa:
- Message Content Intent ← requerido
- Server Members Intent ← recomendado / necesario si usas allowlists por usuarios/roles

#

Presence Intent solo si lo configuraste/lo necesitas

Guarda cambios
Reinicia OpenClaw:

openclaw gateway restart

Después mira logs otra vez. Lo sano sería ver algo tipo “client initialized … gateway ready” sin el 4014.

El timeout de users/@me parece starvation/lentitud al arrancar, pero el error fatal aquí es el 4014. 🦞

ashen root May 13, 2026, 7:27 AM

#

PS C:\Users\sergio.practicas> openclaw logs --tail 120
OpenClaw does not recognize option "--tail".
Try: openclaw logs 120 --help

copper steepleBOT May 13, 2026, 7:27 AM

#

Sí, mi culpa — en tu versión el comando no usa --tail.

Usa esto:

openclaw logs 120

O para seguirlos en vivo:

openclaw logs --follow

Pero con lo que ya pegaste, la causa principal es clara: 4014 missing privileged gateway intents. Primero activa los intents en el Developer Portal para el/los bots y reinicia:

#

openclaw gateway restart

Luego si todavía no aparecen, pégame:

openclaw logs 120
openclaw config get channels.discord

ashen root May 13, 2026, 7:33 AM

#

🦞 OpenClaw 2026.5.10-beta.3 (6d7dcd9) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

{
"enabled": true,
"token": "OPENCLAW_REDACTED",
"groupPolicy": "open",
"allowFrom": [
"719117335449042984"
],
"threadBindings": {
"spawnSessions": true
},
"voice": {
"enabled": true,
"connectTimeoutMs": 60000,
"reconnectGraceMs": 60000
},
"applicationId": "1491751369529364601",
"accounts": {
"support": {
"groupPolicy": "allowlist",
"token": {
"source": "env",
"provider": "default",
"id": "DISCORD_SUPPORT_TOKEN"
},
"applicationId": "1503665210613956658"
}
}
}

copper steepleBOT May 13, 2026, 7:34 AM

#

Gracias, esto ayuda. Tu config tiene dos detalles importantes:

El bot support tiene:

"groupPolicy": "allowlist"

pero no tiene guilds allowlist dentro de accounts.support. Entonces aunque arranque, en servidor/guild queda bloqueado. Para ese bot necesitas algo así:

accounts: {
  support: {
    groupPolicy: "allowlist",
    allowFrom: ["719117335449042984"],
    guilds: {

#

      "TU_SERVER_ID": {
        requireMention: true,
        users: ["719117335449042984"],
      },
    },
    voice: {
      enabled: true,
      connectTimeoutMs: 60000,
      reconnectGraceMs: 60000,
    },
    token: { source: "env", provider: "default", id: "DISCORD_SUPPORT_TOKEN" },
    applicationId: "1503665210613956658",
  }
}

#

El log anterior dice 4014 missing privileged gateway intents. Eso se arregla en el Developer Portal de la app support: Bot → Privileged Gateway Intents → activa Message Content Intent. Si usas allowlist por usuarios/roles/guild, activa también Server Members Intent.

Para confirmar el server ID:

openclaw config get channels.discord.guilds

Si no tienes nada ahí, copia el Server ID de Discord y lo ponemos tanto en el bot principal como en accounts.support.

ashen root May 13, 2026, 7:35 AM

#

PS C:\Users\sergio.practicas> openclaw config get channels.discord.guilds
Config warnings:

plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present

🦞 OpenClaw 2026.5.10-beta.3 (6d7dcd9) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Config path not found: channels.discord.guilds. Run openclaw config validate to inspect config shape.

copper steepleBOT May 13, 2026, 7:35 AM

#

Perfecto: eso confirma que no tienes allowlist de servidor configurada (channels.discord.guilds no existe). Para que aparezca/funcione en el servidor, añade el guild. El server ID de este hilo es:

1456350064065904867

Crea un archivo discord-guild.patch.json5 con esto:

{
  channels: {
    discord: {
      guilds: {
        "1456350064065904867": {
          requireMention: true,
          users: ["719117335449042984"],

#

        },
      },
      accounts: {
        support: {
          guilds: {
            "1456350064065904867": {
              requireMention: true,
              users: ["719117335449042984"],
            },
          },
          allowFrom: ["719117335449042984"],
          voice: {
            enabled: true,
            connectTimeoutMs: 60000,
            reconnectGraceMs: 60000,

#

          },
        },
      },
    },
  },
}

Luego:

openclaw config patch --file .\discord-guild.patch.json5 --dry-run
openclaw config patch --file .\discord-guild.patch.json5
openclaw gateway restart

#

Y muy importante: si sigue saliendo 4014, entra al Developer Portal de cada app/bot y activa Message Content Intent + Server Members Intent. Sin eso Discord cierra el websocket y el bot no queda online.

ashen root May 13, 2026, 7:52 AM

#

Error: Dry run failed: config schema validation failed.

- channels.discord.guilds: invalid config: must be object
- channels.discord.accounts.support.guilds: invalid config: must be object

copper steepleBOT May 13, 2026, 7:53 AM

#

Ese error casi siempre pasa cuando guilds quedó como lista/array ([...]) o como texto, pero tiene que ser objeto/mapa ({...}). Probemos sin copiar desde Discord, creando el archivo directamente con PowerShell:

@'
{
  channels: {
    discord: {
      guilds: {
        "1456350064065904867": {
          requireMention: true,
          users: ["719117335449042984"],
        },
      },
      accounts: {
        support: {
          guilds: {

#

            "1456350064065904867": {
              requireMention: true,
              users: ["719117335449042984"],
            },
          },
          allowFrom: ["719117335449042984"],
          voice: {
            enabled: true,
            connectTimeoutMs: 60000,
            reconnectGraceMs: 60000,
          },
        },
      },
    },
  },

#

}
'@ | Set-Content -Encoding UTF8 .\discord-guild.patch.json5

openclaw config patch --file .\discord-guild.patch.json5 --dry-run

Si eso aún falla, pégame el contenido exacto del archivo:

Get-Content .\discord-guild.patch.json5

Las warnings de mem0 y telegram no son el problema aquí.

ashen root May 13, 2026, 8:02 AM

#

Error: Dry run failed: config schema validation failed.

- channels.discord.guilds: invalid config: must be object
- channels.discord.accounts.support.guilds: invalid config: must be object
  {
  channels: {
  discord: {
  guilds: {
  "1456350064065904867": {
  requireMention: true,
  users: ["719117335449042984"],
  },
  },
  accounts: {
  support: {
  guilds: {
  "1456350064065904867": {
  requireMention: true,
  users: ["719117335449042984"],
  },
  },
  allowFrom: ["719117335449042984"],
  voice: {
  enabled: true,
  connectTimeoutMs: 60000,
  reconnectGraceMs: 60000,
  },
  },
  },
  },
  },
  }

copper steepleBOT May 13, 2026, 8:05 AM

#

Vale, ya encontré el detalle raro: en esta versión el patch se está atragantando con el ID numérico usado como key dentro de guilds. Usa una key con nombre y mete el ID real en slug.

Prueba este archivo en vez del anterior:

@'
{
  channels: {
    discord: {
      guilds: {
        openclaw_server: {
          slug: "1456350064065904867",
          requireMention: true,
          users: ["719117335449042984"],
        },
      },

#

      accounts: {
        support: {
          groupPolicy: "allowlist",
          guilds: {
            openclaw_server: {
              slug: "1456350064065904867",
              requireMention: true,
              users: ["719117335449042984"],
            },
          },
          allowFrom: ["719117335449042984"],
          voice: {
            enabled: true,
            connectTimeoutMs: 60000,
            reconnectGraceMs: 60000,

#

          },
        },
      },
    },
  },
}
'@ | Set-Content -Encoding UTF8 .\discord-guild.patch.json5

openclaw config patch --file .\discord-guild.patch.json5 --dry-run

Si dry-run pasa:

openclaw config patch --file .\discord-guild.patch.json5

#

openclaw gateway restart

Yo lo validé contra la schema local: con key numérica falla; con openclaw_server + slug pasa. 🦞

ashen root May 13, 2026, 8:26 AM

#

vale, ahora ya ha pasado pero solo me sale un bot, el del subagente, quiero que salgan amob

copper steepleBOT May 13, 2026, 8:27 AM

#

Bien, ya avanzamos 🦞

Si ahora solo aparece el del subagente, el problema ya no es el guilds; seguramente el bot default/principal no está arrancando o Discord lo está cerrando.

Mira en logs si aparecen dos providers:

openclaw logs 120

Busca algo como:

[discord] [default] starting provider
[discord] [support] starting provider

#

Si solo ves [support], revisa estas 3 cosas del bot principal:

Que el token principal siga configurado y no sea el mismo que DISCORD_SUPPORT_TOKEN.
- Si ambos resuelven al mismo token, OpenClaw solo arranca uno.
Que applicationId: "1491751369529364601" sea el Application ID del bot principal, no del support.
En Developer Portal del bot principal, activa también:
- Message Content Intent
- Server Members Intent

Pégame la parte de logs donde sale discord después del restart, por ejemplo:

openclaw logs 120 | Select-String discord

Y si puedes también:

#

openclaw config get channels.discord.token
openclaw config get channels.discord.accounts.support.token

No pegues tokens reales si salen; solo dime si son distintos (env, redacted, etc.).

ashen root May 13, 2026, 8:29 AM

#

PS C:\Users\sergio.practicas\Documents> openclaw logs 120
Too many arguments for this command.
Try: openclaw logs 120 --help
PS C:\Users\sergio.practicas\Documents> openclaw logs 120 | Select-String discord
Too many arguments for this command.
Try: openclaw logs 120 --help

copper steepleBOT May 13, 2026, 8:30 AM

#

Otro fallo mío con el comando, perdón 😅 En esta versión es:

openclaw logs --limit 120

Y filtrado:

openclaw logs --limit 120 | Select-String discord

Para lo de “que salgan ambos”, revisa además esto: tu config mostró voice.enabled solo en el Discord principal, y el patch que aplicamos lo añadió también al support. Pero el bot principal puede no aparecer si su token no está llegando al gateway.

Comprueba rápido:

#

openclaw config get channels.discord.token
openclaw config get channels.discord.accounts.support.token

Deben ser distintos. Si el principal sale como redacted string __OPEN…ED__ y support como env DISCORD_SUPPORT_TOKEN, bien.

Luego pega el filtrado correcto:

openclaw logs --limit 120 | Select-String discord

Ahí deberíamos ver si arranca [default] y [support], o si el principal cae por 4014, token inválido, duplicate token, etc.

ashen root May 13, 2026, 8:33 AM

#

2026-05-13T08:10:09.800Z info gateway/reload {"subsystem":"gateway/reload"} config change detected; evaluating reload
(meta.lastTouchedAt, channels.discord.accounts.support.guilds, channels.discord.accounts.support.allowFrom,
channels.discord.accounts.support.voice, channels.discord.guilds)
2026-05-13T08:11:02.158Z info gateway/channels {"subsystem":"gateway/channels"} restarting discord channel
2026-05-13T08:11:10.168Z info gateway/reload {"subsystem":"gateway/reload"} config hot reload applied
(channels.discord.accounts.support.guilds, channels.discord.accounts.support.allowFrom,
channels.discord.accounts.support.voice, channels.discord.guilds)
2026-05-13T08:16:45.146Z info gateway {"subsystem":"gateway"} http server listening (11 plugins: acpx, browser,
device-pair, discord, file-transfer, google, memory-core, phone-control, talk-voice, whatsapp, zalouser; 166.6s)
2026-05-13T08:17:03.470Z warn fetch-timeout {"subsystem":"fetch-timeout"}
{"timeoutMs":2500,"elapsedMs":9091,"timerDelayMs":6591,"eventLoopDelayHint":"timer delayed 6591ms, likely event-loop
starvation","operation":"fetchWithTimeout","url":"https://discord.com/api/v10/users/@me"} fetch timeout reached;
aborting operation
2026-05-13T08:17:03.483Z warn [fetch-timeout] fetch timeout after 2500ms (elapsed 9091ms) timer delayed 6591ms, likely
event-loop starvation operation=fetchWithTimeout url=https://discord.com/api/v10/users/@me
2026-05-13T08:17:03.490Z info channels/discord {"subsystem":"channels/discord"} [support] starting provider
2026-05-13T08:17:18.070Z info channels/discord {"subsystem":"channels/discord"} discord channels unresolved:
openclaw_server (guild:openclaw_server)
2026-05-13T08:17:18.079Z info channels/discord {"subsystem":"channels/discord"} discord users resolved:
719117335449042984
2026-05-13T08:17:18.086Z info channels/discord {"subsystem":"channels/discord"} discord channel users resolved:
719117335449042984
2026-05-13T08:17:31.044Z warn fetch-timeout {"subsystem":"fetch-timeout"}

copper steepleBOT May 13, 2026, 8:35 AM

#

Vale: el log dice que solo está arrancando [support]. No aparece [default] starting provider, así que el bot principal ni está llegando a inicializarse.

Además tenemos este aviso raro:

discord channels unresolved: openclaw_server (guild:openclaw_server)

Eso viene del workaround con openclaw_server. Mejor cambiémoslo a "*" y borremos esa key. Así evitamos que intente resolver openclaw_server como si fuera un canal/guild real.

Aplica este patch:

@'
{
  channels: {

#

    discord: {
      gatewayInfoTimeoutMs: 60000,
      gatewayReadyTimeoutMs: 60000,
      gatewayRuntimeReadyTimeoutMs: 60000,
      guilds: {
        openclaw_server: null,
        "*": {
          requireMention: true,
          users: ["719117335449042984"],
        },
      },
      accounts: {
        support: {
          gatewayInfoTimeoutMs: 60000,
          gatewayReadyTimeoutMs: 60000,

#

          gatewayRuntimeReadyTimeoutMs: 60000,
          guilds: {
            openclaw_server: null,
            "*": {
              requireMention: true,
              users: ["719117335449042984"],
            },
          },
        },
      },
    },
  },
}
'@ | Set-Content -Encoding UTF8 .\discord-both-bots.patch.json5

#

openclaw config patch --file .\discord-both-bots.patch.json5 --dry-run
openclaw config patch --file .\discord-both-bots.patch.json5
openclaw gateway restart

Luego:

openclaw logs --limit 160 | Select-String discord

Lo que queremos ver es algo como:

[default] starting provider

#

[support] starting provider

Si después de esto sigue saliendo solo [support], el siguiente sospechoso es el token/app del bot principal: token duplicado, token inválido, falta de privileged intents, o bot principal no invitado al server con applications.commands.

copper steepleBOT May 13, 2026, 8:54 AM

#

Entonces ya casi seguro es esto: al añadir accounts.support, tu bot principal quedó en la config top-level, pero el runtime multi-account está arrancando solo las cuentas bajo accounts. Hay que crear explícitamente accounts.default para el bot principal.

Primero aplica este patch — no toca tokens todavía:

@'
{
  channels: {
    discord: {
      defaultAccount: "default",
      accounts: {
        default: {
          enabled: true,
          groupPolicy: "open",
          allowFrom: ["719117335449042984"],
          threadBindings: { spawnSessions: true },

#

          voice: {
            enabled: true,
            connectTimeoutMs: 60000,
            reconnectGraceMs: 60000,
          },
          guilds: {
            "*": {
              requireMention: true,
              users: ["719117335449042984"],
            },
          },
          applicationId: "1491751369529364601",
        },
      },
    },

#

  },
}
'@ | Set-Content -Encoding UTF8 .\discord-default-account.patch.json5

openclaw config patch --file .\discord-default-account.patch.json5 --dry-run
openclaw config patch --file .\discord-default-account.patch.json5
openclaw gateway restart

Después mira:

openclaw logs --limit 160 | Select-String discord

Si ahora aparece [default] pero dice token missing / not configured, entonces falta copiar el token principal dentro de accounts.default. En ese caso hazlo sin pegar el token aquí:

#

$env:DISCORD_BOT_TOKEN="TOKEN_DEL_BOT_PRINCIPAL"
[Environment]::SetEnvironmentVariable("DISCORD_BOT_TOKEN", "TOKEN_DEL_BOT_PRINCIPAL", "User")

@'
{
  channels: {
    discord: {
      accounts: {
        default: {
          token: { source: "env", provider: "default", id: "DISCORD_BOT_TOKEN" },
        },
      },
    },
  },
}

#

'@ | Set-Content -Encoding UTF8 .\discord-default-token.patch.json5

openclaw config patch --file .\discord-default-token.patch.json5 --dry-run
openclaw config patch --file .\discord-default-token.patch.json5
openclaw gateway restart

Luego deberían salir los dos: [default] y [support].

ashen root May 13, 2026, 9:00 AM

#

2026-05-13T08:16:45.146Z info gateway {"subsystem":"gateway"} http server listening (11 plugins: acpx, browser, device-pair,
discord, file-transfer, google, memory-core, phone-control, talk-voice, whatsapp, zalouser; 166.6s)
2026-05-13T08:17:03.470Z warn fetch-timeout {"subsystem":"fetch-timeout"}
{"timeoutMs":2500,"elapsedMs":9091,"timerDelayMs":6591,"eventLoopDelayHint":"timer delayed 6591ms, likely event-loop
starvation","operation":"fetchWithTimeout","url":"https://discord.com/api/v10/users/@me"} fetch timeout reached; aborting
operation
2026-05-13T08:17:03.483Z warn [fetch-timeout] fetch timeout after 2500ms (elapsed 9091ms) timer delayed 6591ms, likely
event-loop starvation operation=fetchWithTimeout url=https://discord.com/api/v10/users/@me
2026-05-13T08:17:03.490Z info channels/discord {"subsystem":"channels/discord"} [support] starting provider
Log tail truncated (increase --max-bytes).
2026-05-13T08:17:18.070Z info channels/discord {"subsystem":"channels/discord"} discord channels unresolved: openclaw_server
(guild:openclaw_server)
2026-05-13T08:17:18.079Z info channels/discord {"subsystem":"channels/discord"} discord users resolved: 719117335449042984
2026-05-13T08:17:18.086Z info channels/discord {"subsystem":"channels/discord"} discord channel users resolved:
719117335449042984
2026-05-13T08:17:31.044Z warn fetch-timeout {"subsystem":"fetch-timeout"}
{"timeoutMs":10000,"elapsedMs":14685,"operation":"fetchWithTimeout","url":"https://discord.com/api/v10/users/@me"} fetch
timeout reached; aborting operation
2026-05-13T08:17:31.050Z warn [fetch-timeout] fetch timeout after 10000ms (elapsed 14685ms) operation=fetchWithTimeout
url=https://discord.com/api/v10/users/@me
2026-05-13T08:17:37.194Z info channels/discord {"subsystem":"channels/discord"} discord co

copper steepleBOT May 13, 2026, 9:00 AM

#

Ese log todavía parece del arranque viejo (08:17) y además está cortado:

Log tail truncated (increase --max-bytes)

Saca uno más grande después del último restart:

openclaw logs --limit 300 --max-bytes 1000000 | Select-String "discord|channels/discord|starting provider|4014|token|configured|duplicate|default|support"

Y confirma si el patch creó accounts.default:

openclaw config get channels.discord.defaultAccount

#

openclaw config get channels.discord.accounts.default
openclaw config get channels.discord.accounts.support

Si accounts.default existe pero no tiene token, añade el token principal ahí con el segundo patch que te pasé. En multi-account, no me fío de que el token top-level se use para arrancar el default; mejor dejarlo explícito en accounts.default.token.

ashen root May 13, 2026, 9:05 AM

#

09:01:40+00:00 info channels/discord {"subsystem":"channels/discord"} [default] starting provider (@JARVIS)
09:01:40+00:00 info channels/discord {"subsystem":"channels/discord"} discord users resolved: 719117335449042984
09:01:40+00:00 info channels/discord {"subsystem":"channels/discord"} discord channel users resolved: 719117335449042984
09:01:42+00:00 warn Config warnings:

plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present
09:02:02+00:00 error channels/whatsapp {"subsystem":"channels/whatsapp"} [default] channel exited: {"error":{"data":null,"isBoom":true,"isServer":false,"output":{"statusCode":408,"payload":{"statusCode":408,"error":"Request Time-out","message":"Connection was lost"},"headers":{}}},"date":"2026-05-13T09:02:02.863Z"}
09:02:02+00:00 info channels/whatsapp {"subsystem":"channels/whatsapp"} [default] auto-restart attempt 1/10 in 5s
09:02:19+00:00 info channels/discord {"subsystem":"channels/discord"} discord: gateway metadata lookup failed transiently; using default gateway url (Failed to get gateway information from Discord: fetch failed | fetch failed | other side closed)
09:02:19+00:00 info channels/discord {"subsystem":"channels/discord"} discord client initialized as 1491751369529364601; awaiting gateway readiness

ahora se ha activoad el agente pricipal pero no el secundario

copper steepleBOT May 13, 2026, 9:05 AM

#

Genial, el principal ya volvió. Ahora falta ver por qué support no entra.

Si después de poner accounts.default desapareció support, normalmente es una de estas:

accounts.support.enabled quedó en false o incompleto
DISCORD_SUPPORT_TOKEN no está disponible para el gateway después del restart
el patch de accounts.default reemplazó parte de accounts.support
support está arrancando pero el log filtrado no llegó hasta esa parte

Pégame estos tres, con tokens redactados si aparecen:

openclaw config get channels.discord.accounts
openclaw config get channels.discord.defaultAccount
openclaw status --all

#

Y para logs, sin que se corte:

openclaw logs --limit 500 --max-bytes 2000000 | Select-String "channels/discord|\[default\]|\[support\]|DISCORD_SUPPORT_TOKEN|token|configured|disabled|4014|duplicate"

Si support.token sigue siendo env, confirma también en esa misma terminal:

[Environment]::GetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "User")

No pegues el valor; solo dime si devuelve algo o queda vacío.

slow flameBOT May 13, 2026, 9:07 AM

#

ashen root May 13, 2026, 9:08 AM

#

{
"support": {
"groupPolicy": "allowlist",
"token": {
"source": "env",
"provider": "default",
"id": "DISCORD_SUPPORT_TOKEN"
},
"applicationId": "1503665210613956658",
"guilds": {
"": {
"requireMention": true,
"users": [
"719117335449042984"
]
}
},
"allowFrom": [
"719117335449042984"
],
"voice": {
"enabled": true,
"connectTimeoutMs": 60000,
"reconnectGraceMs": 60000
},
"gatewayInfoTimeoutMs": 60000,
"gatewayReadyTimeoutMs": 60000,
"gatewayRuntimeReadyTimeoutMs": 60000
},
"default": {
"enabled": true,
"groupPolicy": "open",
"allowFrom": [
"719117335449042984"
],
"threadBindings": {
"spawnSessions": true
},
"voice": {
"enabled": true,
"connectTimeoutMs": 60000,
"reconnectGraceMs": 60000
},
"guilds": {
"": {
"requireMention": true,
"users": [
"719117335449042984"
]
}
},
"applicationId": "1491751369529364601"
}
}

PS C:\Users\sergio.practicas> openclaw config get channels.discord.defaultAccount
Config warnings:

plugins.entries.openclaw-mem0: plugin openclaw-mem0: providerAuthEnvVars is deprecated compatibility metadata for provider env-var lookup; mirror mem0, openclaw-mem0-oss env vars to setup.providers[].envVars before the deprecation window closes
plugins.entries.telegram: plugin disabled (bundled (disabled by default)) but config is present

🦞 OpenClaw 2026.5.10-beta.3 (6d7dcd9) — Your task has been queued; your dignity has been deprecated.

default

copper steepleBOT May 13, 2026, 9:09 AM

#

La config de support se ve bien. Si solo arranca [default], el sospechoso #1 ahora es que el proceso del gateway no está viendo DISCORD_SUPPORT_TOKEN.

Haz esta comprobación:

[Environment]::GetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "User")

Si sale vacío, guárdalo otra vez — sin pegarlo aquí:

[Environment]::SetEnvironmentVariable("DISCORD_SUPPORT_TOKEN", "TOKEN_DEL_BOT_SUPPORT", "User")

Y además yo lo dejaría explícito en .env, que suele ser más fiable para el gateway en Windows:

#

New-Item -ItemType Directory -Force $env:USERPROFILE\.openclaw | Out-Null
Add-Content $env:USERPROFILE\.openclaw\.env "DISCORD_SUPPORT_TOKEN=TOKEN_DEL_BOT_SUPPORT"

Luego marca support explícitamente enabled:

@'
{
  channels: {
    discord: {
      accounts: {
        support: {
          enabled: true,
        },

#

      },
    },
  },
}
'@ | Set-Content -Encoding UTF8 .\discord-support-enable.patch.json5

openclaw config patch --file .\discord-support-enable.patch.json5 --dry-run
openclaw config patch --file .\discord-support-enable.patch.json5
openclaw gateway restart

Después:

openclaw status --all

#

openclaw logs --limit 500 --max-bytes 2000000 | Select-String "\[default\]|\[support\]|DISCORD_SUPPORT_TOKEN|SecretRef|token|configured|disabled|4014"

Si support sigue sin aparecer ahí, pégame ese filtrado. Pero ahora que default ya arranca, casi seguro falta el token del segundo bot en el entorno real del gateway.

ashen root May 13, 2026, 9:11 AM

#

vale ya se activaron los dos, por cierto lo del .evn he copiado sin quererr el comando entero sin modificar, como lo elimino

copper steepleBOT May 13, 2026, 9:12 AM

#

Buenísimo, los dos vivos 🎉

Para borrar la línea mala del .env, haz backup primero y elimina cualquier línea que tenga el placeholder TOKEN_DEL_BOT_SUPPORT:

Copy-Item $env:USERPROFILE\.openclaw\.env $env:USERPROFILE\.openclaw\.env.bak
(Get-Content $env:USERPROFILE\.openclaw\.env) | Where-Object { $_ -notmatch 'TOKEN_DEL_BOT_SUPPORT' } | Set-Content -Encoding UTF8 $env:USERPROFILE\.openclaw\.env

Luego comprueba:

Get-Content $env:USERPROFILE\.openclaw\.env

Si ves una línea literal mala tipo:

#

DISCORD_SUPPORT_TOKEN=TOKEN_DEL_BOT_SUPPORT

ya debería haber desaparecido. Después deja solo la buena:

Add-Content $env:USERPROFILE\.openclaw\.env "DISCORD_SUPPORT_TOKEN=TU_TOKEN_REAL"
openclaw gateway restart

No pegues el token aquí.

ashen root May 13, 2026, 9:21 AM

#

09:18:58+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":12,"host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":54181,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:54181->127.0.0.1:18789"} closed before connect conn=2ac05753-64e4-4253-8c09-c69697995289 peer=127.0.0.1:54181->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
09:18:58+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":462,"host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":55022,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:55022->127.0.0.1:18789"} closed before connect conn=a5b99f40-e7cf-4c6b-b911-a1388703314b peer=127.0.0.1:55022->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
09:19:01+00:00 info gateway {"subsystem":"gateway"} agent model: openai-codex/gpt-5.5 (thinking=medium, fast=off)
09:19:01+00:00 info gateway {"subsystem":"gateway"} http server listening (11 plugins: acpx, browser, device-pair, discord, file-transfer, google, memory-core, phone-control, talk-voice, whatsapp, zalouser; 162.2s)
09:19:01+00:00 info gateway {"subsystem":"gateway"} log file: C:\Users\SERGIO~1.PRA\AppData\Local\Temp\openclaw\openclaw-2026-05-13.log
09:19:05+00:00 warn gateway {"subsystem":"gateway"} security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.
09:19:05+00:00 info gateway {"subsystem":"gateway"} starting channels and sidecars...
09:19:13+00:00 info channels/discord {"subsystem":"channels/discord"} [support] delaying provider startup 10s to reduce Discord startup rate limits
09:19:13+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"startup-sidecars-

copper steepleBOT May 13, 2026, 9:21 AM

#

Eso no parece un fallo nuevo.

closed before connect ... 127.0.0.1 ... code=1006: normalmente es algún cliente local/CLI/UI abriendo websocket y cerrándolo antes de completar handshake. Si el gateway sigue arrancando, suele ser ruido.
[support] delaying provider startup 10s: normal en multi-bot, OpenClaw lo retrasa para evitar rate limits de Discord.
startup-sidecars-...: pegaste la línea cortada; necesito el resto solo si luego aparece error o no arrancan los bots.

Lo único que sí miraría aparte es esto:

gateway.controlUi.allowInsecureAuth=true

No rompe Discord, pero es una warning de seguridad. Cuando acabes de arreglar bots, ejecuta:

openclaw security audit

#

Para confirmar que ya está todo bien:

openclaw logs --limit 300 --max-bytes 2000000 | Select-String "\[default\]|\[support\]|client initialized|gateway readiness|4014|error"

Si ves client initialized para ambos y no hay 4014/error, ya está sano.

ashen root May 13, 2026, 9:23 AM

#

09:20:22+00:00 info channels/discord {"subsystem":"channels/discord"} discord client initialized as 1491751369529364601; awaiting gateway readiness
09:20:45+00:00 info channels/discord {"subsystem":"channels/discord"} discord client initialized as 1503665210613956658; awaiting gateway readiness
09:20:45+00:00 info cron {"module":"cron","storePath":"C:\Users\sergio.practicas\.openclaw\cron\jobs.json"} {"enabled":true,"jobs":2,"nextWakeAtMs":1778738400000} cron: started
09:20:45+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 2891ms conn=0b446a06…e637 id=5ffaa99f…301d
09:20:54+00:00 info gateway/channels/whatsapp {"subsystem":"gateway/channels/whatsapp"} Listening for personal WhatsApp inbound messages.
09:20:54+00:00 info [whatsapp] Listening for personal WhatsApp inbound messages.
09:21:13+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 207ms conn=2a9fc28c…9fc9 id=20f056b6…b9c1
09:21:14+00:00 info discord-auto-reply {"module":"discord-auto-reply"} {"channelId":"1491755095950364714","reason":"no-mention"} discord: skipping guild message

algo por aqui?

copper steepleBOT May 13, 2026, 9:24 AM

#

Sí — esto ya se ve bien:

discord client initialized as 1491751369529364601
Discord client initialized as 1503665210613956658

Eso confirma que los dos bots arrancaron: principal + support/subagente.

La línea:

reason="no-mention" discord: skipping guild message

no es error. Significa que en servidor tienes requireMention: true, así que el bot ignora mensajes normales si no lo mencionas. Si quieres que responda sin mención en ese server, cambia requireMention a false en guilds."*" para la cuenta que quieras.

#

Para /vc: si ambos bots ya están inicializados pero el comando no aparece, revisa estas dos cosas en Discord:

Que ambos bots fueron invitados con scope applications.commands.
Que el bot tenga permisos en el canal: View Channel, Send Messages, Read Message History, Connect, Speak.

Pero por logs: Discord ya está levantado para ambos. 🦞

ashen root May 13, 2026, 9:24 AM

#

se acaban de deconectar, les e mandado un mensaje a cada uno para ver que respondain y no han dichoo nada

copper steepleBOT May 13, 2026, 9:25 AM

#

Uf, vale — entonces necesitamos el log justo después de esos mensajes, porque “no responde” puede ser dos cosas distintas:

Están conectados pero ignoran el mensaje porque requireMention: true → en servidor solo responden si los mencionas.
Se cayó el gateway de Discord → veremos closed, 4014, READY timeout, channel exited, etc.

Prueba primero mencionándolos explícitamente en el servidor. Si les escribiste en DM, eso debería entrar por allowFrom, pero en canal/thread con requireMention: true no responderán sin mención.

Pégame esto:

openclaw logs --limit 500 --max-bytes 2000000 | Select-String "discord|\[default\]|\[support\]|gateway websocket closed|closed|READY|ready|channel exited|4014|no-mention|unauthorized|pairing|required|skipping|error"

Y también:

#

openclaw status --all

Si quieres que respondan sin mencionarlos, aplica este patch:

@'
{
  channels: {
    discord: {
      guilds: {
        "*": { requireMention: false },
      },
      accounts: {
        default: {

#

          guilds: { "*": { requireMention: false } },
        },
        support: {
          guilds: { "*": { requireMention: false } },
        },
      },
    },
  },
}
'@ | Set-Content -Encoding UTF8 .\discord-no-mention.patch.json5

openclaw config patch --file .\discord-no-mention.patch.json5 --dry-run
openclaw config patch --file .\discord-no-mention.patch.json5
openclaw gateway restart

#

Pero primero prefiero ver si hay un closed/error, porque dices que “se desconectaron” y eso suena más grave que solo no-mention.

ashen root May 13, 2026, 9:29 AM

#

por los limites de discord no puedo subir tanto

copper steepleBOT May 13, 2026, 9:29 AM

#

Sí, normal — no pegues todo. Saca solo lo importante con filtros pequeños.

Ejecuta estos, uno por uno, y pega solo la salida:

openclaw logs --limit 120 --max-bytes 500000 | Select-String "gateway websocket closed|4014|channel exited|READY timeout|missing privileged|Invalid token|unauthorized|SecretRef|DISCORD_SUPPORT_TOKEN"

Luego este para ver si ignoró tus mensajes:

openclaw logs --limit 120 --max-bytes 500000 | Select-String "discord-auto-reply|no-mention|skipping guild message|pairing|required|allowlist|unauthorized"

Y este para ver si ambos siguen conectados:

#

openclaw logs --limit 120 --max-bytes 500000 | Select-String "client initialized as|\[default\]|\[support\]"

Si los mensajes fueron en el servidor/thread y ves no-mention, no están desconectados: simplemente no responden porque requireMention: true. En ese caso menciona al bot o ponemos requireMention: false.

ashen root May 13, 2026, 9:36 AM

#

2026-05-13T09:14:10.299Z info channels/discord {"subsystem":"channels/discord"} discord gateway: Gateway websocket closed:
1000
2026-05-13T09:14:10.340Z info channels/discord {"subsystem":"channels/discord"} discord gateway: Gateway websocket closed:
1000
2026-05-13T09:26:38.361Z info channels/discord {"subsystem":"channels/discord"} discord gateway: Gateway websocket closed:
1006
2026-05-13T09:26:38.391Z info channels/discord {"subsystem":"channels/discord"} discord gateway: Gateway websocket closed:
1006PS C:\Users\sergio.practicas\Documents> openclaw logs --limit 120 --max-bytes 500000 | Select-String "client initialized as|[default]|[support]"
Log tail truncated (increase --max-bytes).

2026-05-13T09:19:13.676Z info channels/discord {"subsystem":"channels/discord"} [support] delaying provider startup 10s to
reduce Discord startup rate limits
2026-05-13T09:19:14.031Z info channels/whatsapp {"subsystem":"channels/whatsapp"} [default] starting provider (+34687981750)
2026-05-13T09:19:23.772Z info channels/discord {"subsystem":"channels/discord"} [default] starting provider
2026-05-13T09:19:53.781Z info channels/discord {"subsystem":"channels/discord"} [support] starting provider
2026-05-13T09:20:22.883Z info channels/discord {"subsystem":"channels/discord"} discord client initialized as
1491751369529364601; awaiting gateway readiness
2026-05-13T09:20:45.228Z info channels/discord {"subsystem":"channels/discord"} discord client initialized as
1503665210613956658; awaiting gateway readiness
2026-05-13T09:26:33.812Z info channels/whatsapp {"subsystem":"channels/whatsapp"} [default] auto-restart attempt 1/10 in 5s

copper steepleBOT May 13, 2026, 9:36 AM

#

Sí, ahí está el problema:

discord gateway ... closed: 1006

1000 era cierre normal por restart/reload. 1006 es cierre anormal del websocket de Discord. Como salen dos líneas, probablemente se cayeron los dos clientes Discord a la vez.

Haz lo simple primero:

openclaw gateway restart

Espera 1-2 min y confirma:

#

openclaw logs --limit 200 --max-bytes 1000000 | Select-String "\[default\]|\[support\]|client initialized as|Gateway websocket closed|channel exited|auto-restart|READY|4014|1006"

Si vuelven a salir:

client initialized as 1491751369529364601
client initialized as 1503665210613956658

y no vuelve el 1006, fue una caída transitoria.

Si el 1006 vuelve otra vez, entonces el problema ya es de conexión/Discord/websocket, no de config. En ese caso prueba también subir timeouts del gateway de Discord para ambas cuentas:

#

@'
{
  channels: {
    discord: {
      gatewayReadyTimeoutMs: 120000,
      gatewayRuntimeReadyTimeoutMs: 120000,
      accounts: {
        default: {
          gatewayReadyTimeoutMs: 120000,
          gatewayRuntimeReadyTimeoutMs: 120000,
        },
        support: {
          gatewayReadyTimeoutMs: 120000,
          gatewayRuntimeReadyTimeoutMs: 120000,
        },

#

      },
    },
  },
}
'@ | Set-Content -Encoding UTF8 .\discord-timeouts.patch.json5

openclaw config patch --file .\discord-timeouts.patch.json5 --dry-run
openclaw config patch --file .\discord-timeouts.patch.json5
openclaw gateway restart

Pero primero reinicia normal; quiero ver si se reconectan limpio.

ashen root May 13, 2026, 9:39 AM

#

vale no habia leido esto y acabo de comprobar que se han reinicado ellos solos y han vuelto a aparecer pero solo el principal me ha contestado

copper steepleBOT May 13, 2026, 9:40 AM

#

Vale, eso ya es mejor: si se reiniciaron solos, el 1006 fue caída/reconnect del websocket.

Que solo conteste el principal suele ser una de estas dos cosas:

El bot support recibe el mensaje, pero no está enrutado al subagente correcto.
El bot support lo ignora por allowlist/mention/pairing.

Comprueba el binding del subagente:

openclaw config get bindings

Debería existir algo parecido a esto:

#

{
  agentId: "support",
  match: {
    channel: "discord",
    accountId: "support",
  },
}

Si no está, añádelo con cuidado sin borrar bindings existentes. Primero pégame tu openclaw config get bindings y te digo el patch exacto.

Y para ver si support está ignorando el mensaje:

openclaw logs --limit 200 --max-bytes 1000000 | Select-String "support|discord-auto-reply|skipping|no-mention|allowlist|pairing|unauthorized|routed|binding|accountId"

#

Si le escribiste en un canal/thread, asegúrate de mencionarlo explícitamente, porque ahora support.guilds."*".requireMention está en true.

#The /vc command doesn't appear on the Discord server, but it does on MD