openclaw - 💡(How to fix) Fix [Bug]: Discord typing indicator lingers after tool-only visible reply is already posted

Summary

In Discord group/channel turns that use messages.groupChat.visibleReplies: "message_tool", the visible reply can land in-channel and the native Discord typing indicator still hangs around for several seconds afterward.

This is not an infinite stuck-typing regression. It looks like cleanup is happening locally, but Discord never gets an actual typing clear when the visible reply is delivered through the message tool path.

Corrected environment

• Running OpenClaw CLI/runtime: 2026.5.22 (openclaw --version)
• Running @openclaw/discord plugin: 2026.5.22 (openclaw plugins list)
• Separate local source checkout inspected during debugging: /home/brandon/openclaw at ec3c1f64ae699f2ad9a18bc7199f5ab49881a99c, whose package.json is 2026.5.3
• Surface: Discord guild channel
• Runtime shape: group chat with tool-only visible replies

Important correction: the first draft of this report accidentally quoted the version of the local source checkout (2026.5.3) instead of the actually running install (2026.5.22). The repro is against the live 2026.5.22 runtime/plugin pair.

Current config in the reproducing install

{
  messages: {
    groupChat: {
      visibleReplies: "message_tool"
    }
  },
  session: {
    typingIntervalSeconds: 600
  },
  channels: {
    discord: {
      groupPolicy: "open",
      guilds: {
        "1476401394025234442": {
          requireMention: false
        }
      }
    }
  }
}

Notes:

• No explicit session.typingMode or agents.defaults.typingMode is set.
• Per docs, group message_tool turns still start typing immediately by default.
• The typingIntervalSeconds: 600 setting is probably a bad local config and makes timing behavior worse, but it does not explain why typing survives for a few seconds after the visible reply has already been posted.

Steps to reproduce

1. Run Discord in a guild/channel room with messages.groupChat.visibleReplies: "message_tool".
2. Make sure the bot is allowed to answer without mention (requireMention: false or equivalent open-group setup).
3. Send a simple prompt that produces a visible message(action=send) reply.
4. Watch the Discord client.

Actual behavior

• The visible reply posts successfully.
• Discord continues showing the bot as typing for a few more seconds after the message is already visible.

Expected behavior

Once the visible reply is posted to Discord, the typing indicator should clear immediately, or OpenClaw should avoid sending/refreshing a native typing event close enough to final visible delivery that the client keeps showing stale typing after the answer is already there.

Code-path evidence

During investigation, the current Discord path appears to wire only a typing start, not a real stop:

• extensions/discord/src/monitor/message-handler.process.ts
  • createChannelReplyPipeline({ typing: { start: () => sendTyping(...) } })
• extensions/discord/src/monitor/typing.ts
  • sendTyping() only posts to Routes.channelTyping(...)
• src/channels/typing.ts
  • createTypingCallbacks() can call fireStop(), but if no stop callback exists it only stops the local keepalive loop
• extensions/discord/src/channel.ts
  • heartbeat exposes sendTyping, but there is no matching Discord clearTyping

So on Discord, tool-only visible delivery seems to rely on local lifecycle cleanup plus Discord’s native typing timeout, instead of an actual clear tied to successful visible delivery.

Why this looks like a real product bug instead of only a config problem

The bad typingIntervalSeconds: 600 config is real and should be fixed locally, but the core UX problem still seems to be:

• tool-only visible replies are allowed and documented for groups
• Discord typing starts immediately for those runs
• successful visible delivery through the message tool is not coupled to a Discord-side typing clear
• if the last typing event fires shortly before the visible send, the client can keep showing typing after the answer is already on screen

Suspected fix direction

Any of these would probably solve it:

1. Couple confirmed visible message tool delivery on the source Discord target to immediate typing cleanup before/at final send.
2. Prevent any new Discord typing send once a visible source reply has been committed.
3. Add a Discord-specific strategy for post-send typing suppression when native clear is unavailable.

I did not patch this locally because I wanted to file the runtime/config evidence first.