**Bug: Specific Discord channels unresponsive after 4.15 → 5.12 upgrade**

[still solstice]

OpenClaw 5.12 | Gateway mode: local | NAS (Linux/Docker) | Gemini 2.5 Flash default

Symptom:
Bot shows typing indicator, then stops — no reply delivered. Affects specific channels only. Other channels in the same server respond normally.

Affected channels: #1456350065223270433, #greenhouse, #sprinklers, #blueiris
Working channels: #general, #art, #research, #logs

No consistent difference in permissions, token counts, or session state between working and non-working channels. Bot can send outbound messages to the dead channels (cron jobs post fine) but cannot respond to inbound messages.

What I've tried:

• Cleared all sessions (openclaw sessions cleanup + direct JSON deletion)
• Cleared delivery queue
• Set typingMode: message
• Set maxConcurrent: 1
• Re-invited bot via OAuth2
• Verified Discord bot permissions on affected channels
• Disabled mem0 plugin entirely
• Gateway restarts (temporarily helps, reverts on next interaction)

Logs show:

work=[active=agent:main:discord:channel:1495208351049580665(processing/model_call,q=1,age=3s) 
queued=agent:main:discord:channel:1495208351049580665(processing/model_call,q=1,age=3s)]

Same channel appears as both active AND queued — looks like a deadlock.

Additional context:

• Problem started immediately after 4.15 → 5.12 upgrade
• mem0 plugin was briefly installed during troubleshooting but is now fully disabled
• channels.discord.token stored as plaintext (required to fix SecretRef issue in 5.12)
• plugins.allow explicitly lists ["acpx", "discord", "whatsapp"]

Any ideas what's different about these specific channels vs the working ones?

[magic panther]

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

[storm gate]

I checked the current docs/source. My read: this is probably not a Discord permission difference.

In 5.x, guild channels are isolated as session keys like agent:<agentId>:discord:channel:<channelId>, and inbound auto-replies are serialized per session lane. So a bad/stalled run in #greenhouse can block only #greenhouse while #art keeps working. Seeing the same channel in both active and queued can be normal if one run is active and the next inbound message is waiting behind it; it becomes suspicious if that state persists and never drains.

Two things I’d check next:

1. Confirm whether this is the 5.x “message tool vs automatic final reply” path:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

Then restart the gateway and test one affected channel. Current Discord docs call out “typing/token usage but no Discord message” when group chat visible replies are set to message-tool behavior and the model misses message(action=send).

[storm gate]

2. Capture the stuck-session diagnostics around one failed channel:

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

After reproducing, look for session.long_running, session.stalled, session.stuck, lane wait exceeded, suppressed final, or provider/model errors near that channel’s session key.

Docs I checked:
https://docs.openclaw.ai/channels/troubleshooting
https://docs.openclaw.ai/concepts/queue
https://docs.openclaw.ai/channels/discord
https://docs.openclaw.ai/help/faq

If visibleReplies: "automatic" fixes it, it points at response delivery/tool-calling rather than Discord routing. If it does not, I’d file this as a GitHub issue with the stuck work=[...] line plus ~50 log lines before/after the failed run: https://github.com/openclaw/openclaw/issues

[still solstice]

Krill, the config validator rejected visibleReplies at both channels.discord.messages.groupChat.visibleReplies and channels.discord.guilds.<id>.visibleReplies with "must NOT have additional properties". Ask Krill for the exact config path that's valid in 5.12.

[storm gate]

Yep, that rejection makes sense. I gave you the wrong nesting.

The valid path is top-level, not under channels.discord:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

So the exact key is:

[storm gate]

messages.groupChat.visibleReplies

Valid values are:

"automatic"
"message_tool"

There does not appear to be a valid per-Discord-guild/per-channel visibleReplies override in the schema. messages.groupChat.visibleReplies applies to group/channel rooms globally; messages.visibleReplies is the broader global default for source turns.

Docs reference:
https://docs.openclaw.ai/channels/discord
https://docs.openclaw.ai/channels/troubleshooting
https://docs.openclaw.ai/gateway/config-channels

[storm gate]

Sorry for the bad path earlier. Claw caught in the config schema. 🦞

[still solstice]

That's the fix — messages.groupChat.visibleReplies: automatic was the key all along.

[storm gate]

Glad that fixed it. The important bit for future readers is:

{
  messages: {
    groupChat: {
      visibleReplies: "automatic"
    }
  }
}

If this is solved, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index the exact config path for the next person who hits this after upgrading.

[still solstice]

I would like to mark it as solved, but I don't see where /how to do that.