Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Summary

Discord inbound works and the model generates replies, but final assistant replies do not appear in Discord.

Environment

• OpenClaw: 2026.4.27
• macOS: 26.3.1 arm64
• Node: 22.22.0
• Gateway: local LaunchAgent, healthy
• Default model: openai-codex/gpt-5.5
• Discord streaming: off
• WhatsApp: disabled

Repro

1. Restart gateway.
2. Confirm openclaw status --deep shows Gateway reachable and Discord OK.
3. Send in Discord #general from a user account:
   @clawc brown reply exactly reinvite-fixed

Expected

Bot posts:
reinvite-fixed

Actual

No visible Discord reply.

Evidence

• User-authored Discord message reaches OpenClaw.
• Session history shows assistant generated exactly reinvite-fixed.
• Session status is done.
• Reply does not appear in Discord.
• Raw Discord API send/read works.
• Re-inviting the bot with fresh scopes/permissions did not fix it.
• Codex auth is healthy.

Relevant paths

• Failed session transcript:
  /Users/moltbot/.openclaw/agents/codex/sessions/d046e2b3-17a0-4997-9264-32308c3a7798.jsonl

openclaw-discord-global-failed-send.log
openclaw-sfc-main-failed-send.log

Notes

systemSent=true appears in session metadata, but source inspection suggested that is not proof of Discord delivery;
it is set during session setup/metadata, before actual outbound delivery.

Steps to reproduce

1. Run OpenClaw gateway on 2026.4.27 with Discord enabled.
2. Confirm openclaw status --deep shows Gateway reachable and Discord OK/configured.
3. In Discord #general, from a user account, send:
   @clawc brown reply exactly reinvite-fixed
4. Check Discord for the bot reply.
5. Check local OpenClaw session history for the same channel.

Expected behavior

The bot should post reinvite-fixed in the same Discord channel. This is the expected behavior for a Discord channel
reply after a user mention is received and the assistant produces final text.

Actual behavior

No visible Discord reply appears. Local OpenClaw session history shows the user-authored Discord message was received
and the assistant generated reinvite-fixed; the session status is done, but the generated final reply does not
render in Discord.

OpenClaw version

2026.4.27 (cbc2ba0)

Operating system

macOS 26.3.1 arm64

Install method

Global npm/pnpm-style install under /Users/moltbot/homebrew, running as a macOS LaunchAgent via openclaw gateway.

Model

openai-codex/gpt-5.5

Provider / routing chain

Discord channel inbound -> local OpenClaw gateway -> codex agent -> openai-codex/gpt-5.5 -> Discord channel reply delivery.

Additional provider/model setup details

• Codex auth was verified healthy with openclaw models status; openai-codex:default ok expires in 10d.
• Default agent model: openai-codex/gpt-5.5.
• Opus lane exists separately with claude-cli, but was not the route under test.
• Discord streaming was set to off during repro.
• WhatsApp was disabled during repro.
• Re-inviting the same Discord bot with refreshed scopes/permissions did not fix the issue.

Logs, screenshots, and evidence

Impact and severity

Affected users/systems/channels:

• Discord channel integration for this OpenClaw gateway.
• Reproduced in #general and #sfc-main.

Severity:

• Blocks workflow. Discord appears to accept messages and the bot starts processing, but no assistant reply is
  delivered visibly.

Frequency:

• Reproduced consistently during this debugging session after gateway restart, token/auth verification, and bot
  re-invite.

Consequence:

• Missed replies in Discord even though local generation succeeds. Users cannot rely on Discord as an OpenClaw channel
  and must use local/web/terminal fallback.

Additional information

• Raw Discord API send/read worked using the same bot, so basic Discord token/permissions were not obviously broken.
• openclaw status --deep showed Gateway reachable and Discord OK/configured.
• systemSent=true appears in session metadata, but local source inspection suggested this is not proof of Discord
  delivery; it appears to be set during session setup/metadata rather than after outbound Discord send acknowledgement.
• A test on 2026.4.29-beta.1 introduced separate Codex auth/runtime noise, so the clean repro is reported against
  2026.4.27.
• Earlier logs showed intermittent event-loop/liveness warnings and Discord slash-command deploy 429s, but the clean
  repro had Codex auth healthy and Discord configured.