Discord channel replies silently dropped by announce-decider in 2026.5.22

Summary

After updating from 2026.5.20 to 2026.5.22, agent replies to Discord channel messages (i.e. guild channels, not DMs) never reach Discord. The agent generates a real reply, the mcp__openclaw__sessions_send tool returns status: accepted, but the announce-decider sub-agent consistently emits ANNOUNCE_SKIP and the message is dropped. DMs to the bot still work normally.

Worked on 2026.5.20. Broken on 2026.5.22. (Did not test 2026.5.21.)

Environment

• OpenClaw 2026.5.22 (Gateway + CLI both a374c3a)
• Node 22.22.2, macOS 26.4.1 arm64
• Channel: @openclaw/[email protected] (NPM installed, pinned)
• Agent runtime: claude-cli (Claude Code 2.1.150, sonnet model)
• Single-user, private Discord guild, groupPolicy: allowlist, requireMention: false
• Multi-agent setup: main, oracle, architect. Oracle bound to its channel; main handles others.

Reproduce

1. Post any message in a Discord guild channel that's in the allowlist (e.g. "hi are you there?")
2. Watch /tmp/openclaw/openclaw-*.log — agent runs, generates response (typically 200-500 raw lines)
3. No ✅ Sent via Discord line follows
4. Final visible event for the session is [agent:nested] ... channel=webchat ANNOUNCE_SKIP

What I observed in the bundled code

In dist/openclaw-tools-QeySpphx.js, buildAgentToAgentAnnounceContext builds the announce-decider's prompt:

"Agent-to-agent announce step: [session lines] Original request: ... Round 1 reply: ... Latest reply: ... If you want to remain silent, reply exactly ANNOUNCE_SKIP. Any other reply will be posted to the target channel. After this reply, the agent-to-agent conversation is over."

The announce-decider sub-agent runs with this prompt + the target session's history loaded, and reliably emits ANNOUNCE_SKIP. I suspect it's biased by past ANNOUNCE_SKIP patterns in the session history (we have a project-cron that uses that exact token for "no daily briefing today"), but I could not confirm by reading the decider's full inputs in the obfuscated bundle.

The downstream dispatcher path (isAnnounceSkip(announceReply) check around the sessionsSendA2ADeps.callGateway({ method: "send", ... }) block) then no-ops the Discord send.

Confirmed via agent transcripts

In ~/.claude/projects/<workspace>/<sid>.jsonl:

• Substantive reply IS generated by the main agent (e.g. multi-paragraph Overlapse status with bullets and questions).
• Agent then calls mcp__openclaw__sessions_send with sessionKey: "agent:main:discord:channel:<channel-id>".
• Tool result: { status: "accepted", delivery: { status: "pending", mode: "announce" } }.
• Agent also tried to: "channel:<id>" → Error: Either sessionKey or label is required.
• Agent tried sessionKey: "channel:<id>" → Error: No session found: channel:<id>.
• Only sessionKey: "agent:main:discord:channel:<id>" is accepted, and that's the path the announce-decider gates.

Tried & did not fix

• session.agentToAgent.maxPingPongTurns: 0 — disables the ping-pong loop but the initial announce-decider step still runs and still skips.
• Enabling skills.entries.discord + adding channels.discord.token SecretRef so the skill becomes "ready" (which the docs imply provides the message tool, but no message tool surfaces in the agent's deferred tool list).
• Resetting the polluted channel sessions in agents/main/sessions/sessions.json.
• Removing the architect agent binding (same behavior fall-through to main).

What I'd hope for

Either:

• A documented config knob to bypass the announce-decider for direct channel chats (something like channels.discord.dispatch: "direct"); OR
• The announce-decider becoming ANNOUNCE_SKIP-resistant when the latest reply is a normal substantive response (currently it seems too eager to skip).

Happy to share full transcript files / gateway logs if that helps.

Workaround in the meantime

Using DMs to the bot, which bypass the announce-decider and deliver reliably.