Bug type

Behavior bug (UI/UX state update issue)

Beta release blocker

No

Summary

Discord intermediate status reaction emojis (🔧, 🔍, 🛠️, etc.) are not displayed during tool/skill execution phases. Only the initial (👀), waiting (⏳), warning (⚠️), and final (🧠) indicators appear, leaving users with no visible feedback during the actual processing pipeline.

Steps to reproduce

1. Send a Discord message that triggers multi-step tool processing (e.g., weather query + radar query + web search, or a complex skill invocation)
2. Observe the Discord reaction sequence on the user's message
3. Note the long silent period between ⏳ and the final 🧠 emoji

Minimal reproducible example:

User: "milyen időjárás lesz budapesten és nézd meg a repülőket a radarral"

This triggers: web_fetch (weather) → exec (radar script) → exec (radar script with filter) → multiple tool calls.

Expected behavior

The Discord reaction emoji should update continuously to reflect the current processing stage:

• 👀 — Agent sees message (appears immediately)
• ⏳ — Processing started (appears immediately)
• 🔧 or 🔍 or 📡 — During active tool/skill execution (should appear during tool calls)
• 🧠 — LLM synthesis/response generation (appears at the end)
• Final response delivered

Intermediate reactions should replace the previous one, giving the user real-time feedback on what is currently happening.

Actual behavior

The observed reaction sequence is:

1. 👀 — Appears immediately ✓
2. ⏳ — Appears immediately ✓
3. (long silent period — 10-30 seconds with no reaction updates)
4. ⚠️ — Appears sometimes after extended processing
5. 🧠 + Discord "Bot is typing..." indicator — Appears ONLY at the very end, during the final LLM summary generation, after all tool/skill execution has completed
6. Final response delivered

The 🔧, 🔍, 🛠️, ⚙️, and other intermediate processing indicators are never displayed during the tool execution window. The user sees a static ⏳ for the entire duration of tool processing with no indication of progress or current activity.

OpenClaw version

2026.6.6

Operating system

Ubuntu 24.04 (AWS EC2 t3.small)

Install method

npm global

Model

kimi/k2p6

Provider / routing chain

openclaw → kimi (kimi/k2p6)

Additional provider/model setup details

Default configuration. Discord integration enabled via the standard discord plugin. No custom middleware or reaction handlers configured.

Logs, screenshots, and evidence

Typical processing timeline for the weather + radar request:

[16:22:00] User sends message: "milyen időjárás lesz budapesten és nézd meg a repülőket"
[16:22:00] 👀 reaction added to user message
[16:22:00] ⏳ reaction replaces 👀
[16:22:01] Tool call: web_fetch (weather wttr.in) — NO reaction change
[16:22:03] Tool call: read (SKILL.md) — NO reaction change
[16:22:05] Tool call: exec (radar.py) — NO reaction change
[16:22:10] Tool call: exec (radar.py --filter) — NO reaction change
[16:22:15] Tool call: exec (radar.py --limit) — NO reaction change
[16:22:30] ⚠️ appears (warning — reason unknown)
[16:22:35] 🧠 reaction appears + Discord "Bot is typing..." starts
[16:22:37] LLM response generated and sent

Expected vs Actual timeline:

Impact and severity

• Affected: All Discord users processing multi-step requests with tools/skills
• Severity: Medium-High (significant UX degradation)
• Frequency: 100% — every tool chain longer than 2-3 steps exhibits this behavior
• Consequence:
  • Users perceive the bot as "frozen" or unresponsive during 10-30 second processing windows
  • No way to distinguish between slow processing, rate limits, or actual errors
  • Users may send duplicate messages thinking the first one was lost
  • Debugging and support burden increases because users cannot self-diagnose processing state

Additional information

• Discord typing indicator works: The "Bot is typing..." indicator appears correctly at the end during LLM inference, proving the Discord adapter CAN send real-time UI updates
• Base reaction mechanism works: 👀, ⏳, ⚠️ all function correctly, proving the core reaction API is accessible
• Gap is specifically in the middle: The issue is exclusively in the tool/skill execution phase, not the initial or final phases
• Not a Discord rate limit: The reactions that DO appear are added/removed without issues. If rate limits were the cause, the final 🧠 would also fail to appear
• Not a permission issue: The bot has full reaction permissions (evidenced by working reactions at start and end)
• Related observations: The ⏳ reaction is often replaced by 🧠 at the end, but never by any intermediate tool-specific reaction during processing
• Possible code areas: agentTurn processing loop, tool_call lifecycle hooks, Discord adapter reaction state machine, or the turn processing pipeline's status emission logic

Related issues

• Potentially related to status update timing in the agent processing pipeline
• May intersect with [Bug]: 10sec latency+before the message send to llm from 2026.2.26 to 2026.4.5 always exist #61953 (10mp latency message küldés előtt) if there is a general delay in Discord UI updates