OpenClaw+GPT 5.4 replied over a hundred of Discord messages when not mentioned

[orchid socket]

Hi, something very bad happened. OpenClaw+GPT 5.4 replied over a hundred of Discord messages when not mentioned (the guild is configured to reply only when mentioned, but from time to time, things I address to another bot will trigger one openclaw bot (who wasn't even mentioned before in the discord thread) to reply but only once, I've asked openclaw and claude code to debug this in the past, and it was inconclusive).

The reply started with long messages that is on topic, but completely making things up; then degrade to short messages self-confirming; eventually become repeated Yes. . Many messages looks like thinking, but they are sent by discord tool as replies. I have to reset the bot token to stop it.

Any clues? Sorry I'm still using openclaw 2026.4.14 because recently I fear openclaw upgrades so I did it only seldomly. Can anyone help me? Thanks!

[frozen pumice]

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

[orchid socket]

Here is the debug report from Claude Code:

Root cause found. Session file: 2026-05-06T07-59-59-250Z_32e4c5b5...jsonl

What happened:

The forked session for channel 1500673522761203836 hit an infinite loop caused by openclaw:bootstrap-context:full firing after every assistant response.

The loop pattern (runs ~200 times, 08:18–08:40 UTC):

1. Assistant replies
2. bootstrap-context:full fires → injects "[Thread starter - for context]" as a new user message
3. Model treats it as a real incoming message and responds again
4. Repeat

The model was in a "reviewing draft" mode and kept affirming each injection: "Yes. That's the right framing.", "Yes. That's crisp.", ... eventually degrading to just "Yes."

After a pre-compaction memory flush at ~08:36, it switched to replying NO_REPLY instead — correct behavior, just very late.

Timeline:

• 07:59:59 UTC — session forked from parent (channel 1472085765314842664), 24682 parent tokens
• 08:18–08:36 UTC — ~100+ "Yes." messages sent to Discord
• 08:36–08:40 UTC — ~50+ "NO_REPLY" responses (not sent to Discord, but model still looping)
• 09:07 UTC — openclaw SIGTERM, process restarted
• Post-restart — Discord bot token returned 401 Unauthorized, so Discord is currently disconnected

[orchid socket]

@wise orchid any clues?

[wise orchid]

Yeah — that pattern smells much more like a bot-to-bot / self-trigger loop than “normal mention gating failed once”. Token reset was the right emergency stop.

Immediate things I’d check/mitigate before turning the token back on:

1. Check whether Discord has allowBots: true anywhere. If yes, change it to allowBots: "mentions" or remove it. Docs explicitly warn that allowBots=true can create bot-to-bot loops.
2. Add ignoreOtherMentions: true on the guild/channel so messages mentioning another bot/user but not this bot get dropped.
3. Check thread bindings / focused sessions. Bound Discord threads can bypass normal mention requirements because they’re treated as an active session. If the incident happened inside a thread, run /unfocus in that thread or disable/raise strictness around thread bindings while debugging.
4. Make sure the bot knows its own identity: set channels.discord.applicationId if startup application lookup is flaky. OpenClaw normally ignores its own messages by bot user id; if identity resolution is broken, loops get much scarier.
5. Temporarily keep the Discord channel disabled or token unset until you capture logs/config. Don’t paste tokens.

Useful sanitized report to collect:

openclaw status --all
openclaw logs --since 2h | grep -Ei 'discord-preflight|allowBots|mention|required|drop|message tool|send'

Config shape I’d expect for a public-ish guild/thread:

{
  channels: {
    discord: {
      groupPolicy: "allowlist",
      allowBots: "mentions",
      guilds: {
        "GUILD_ID": {
          requireMention: true,
          ignoreOtherMentions: true,
          channels: {
            "CHANNEL_ID": { requireMention: true, ignoreOtherMentions: true }
          }
        }
      }
    }

  }
}

Docs: https://docs.openclaw.ai/channels/discord and troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

Also: because this hit 100+ sends, I’d file it as a GitHub issue with the redacted config + log slice + whether allowBots, thread bindings, and applicationId were set: https://github.com/openclaw/openclaw/issues

[orchid socket]

I have already configured required to mention early on. But I wasn't aware of ignoreOtherMentions: true Maybe this could be the fix.

For the 100 plus sends, hopefully this would also prevent it to be triggered. I might need to get back to the log sanitization much later because I'm busy with something else.

[wise orchid]

Yep, ignoreOtherMentions: true is worth trying here. It’s specifically for the case where a guild/channel message mentions someone else but not your bot; with requireMention: true, adding it makes the bot stricter about “this mention wasn’t for me.”

Shape should be under the guild or specific channel, e.g.:

channels: {
  discord: {
    guilds: {
      "YOUR_GUILD_ID": {
        requireMention: true,
        ignoreOtherMentions: true,
        channels: {
          "YOUR_CHANNEL_ID": {
            requireMention: true,
            ignoreOtherMentions: true,
          },