Slack channel session replies are generated but never posted (silent outbound failure)

Summary

In OpenClaw 2026.5.7 on macOS 15.3.1 (arm64, node 22.22.2), Slack channel messages create agent sessions and the model generates valid responses, but the responses are never posted back to Slack via chat.postMessage. No errors are logged. The deliveryContext on the session is set correctly. This is silent data loss from the user's perspective — they see no reply at all.

Environment

• OpenClaw 2026.5.7 (eeef486), installed via pnpm (npm latest 2026.5.7 confirms up to date)
• macOS 15.3.1 (arm64), Node 22.22.2
• Slack channel: Socket Mode, single workspace, single bot
• Plugins loaded: bonjour, browser, device-pair, file-transfer, memory-core, phone-control, slack, talk-voice, telegram
• Channel ON, tokens valid, auth.test returns ok: true
• Bot has scopes: chat:write,channels:read,im:history,channels:history,groups:read,im:read,mpim:read,im:write,mpim:write,app_mentions:read,groups:history
• Bot Event Subscriptions: app_mention, message.channels, message.groups
• Socket Mode enabled in app; apps.connections.open returns ok: true with no warnings
• ~/.openclaw/openclaw.json has channels.slack.channels.<id>.requireMention=false for the affected channel(s)

Symptoms

1. User posts a message in a configured Slack channel (e.g. #daily-tasks, channel id C0B2T9J8LGJ)
2. OpenClaw correctly receives the event and creates a new session under key agent:main:slack:channel:<channel-id> (visible in openclaw status --deep)
3. The session's transcript file (~/.openclaw/agents/main/sessions/<sessionId>.jsonl) shows the user message and a complete assistant reply with stopReason: "stop" and clean text content
4. The sessions.json registry has the correct deliveryContext:

   {
     "channel": "slack",
     "to": "channel:C0B3PDW1X7S",
     "accountId": "default"
   }

5. However: the message never appears in Slack. Verified by:
   • Polling conversations.history via the Slack API — only user messages and a manual chat.postMessage test from curl are visible; no bot replies from sessions
   • grep -i "chat\.postMessage\|slack.*sendMessage" ~/.openclaw/logs/gateway.log — zero matches over the full session of attempts (vs. dozens of [telegram] sendMessage ok lines for the same time window)
   • gateway.err.log has no Slack-related errors after the socket connects (the historical Socket Mode is not turned on lines are pre-fix; once fixed, no further errors of any kind)
   • The delivery queue ~/.openclaw/session-delivery-queue/ is empty
6. Outbound delivery from OpenClaw to Slack does work when invoked directly. A manual curl -X POST https://slack.com/api/chat.postMessage with the bot token from config succeeds. So the token, scopes, and channel membership are fine — the issue is internal to the session→delivery pipeline.

Affected scope

• Confirmed on Slack channel sessions (channel: target)
• Confirmed on Slack DM (im: target) — DMs don't even create a new session under the post-restart logs (separate but possibly related symptom)
• Telegram delivery for the same gateway runs without any issue ([telegram] sendMessage ok lines on every assistant turn)

Steps to reproduce

1. Configure a Slack channel in channels.slack.channels.<channelId> with enabled: true, requireMention: false
2. Ensure the bot has channels:history (or groups:history for private), chat:write, app_mentions:read
3. Event Subscriptions: message.channels (and/or message.groups)
4. Socket Mode ON
5. Restart gateway
6. Post a message in that channel from a non-bot user
7. Observe: session created, assistant message generated in transcript, no message in Slack, no chat.postMessage in logs

What I checked / ruled out

• ✅ Slack tokens valid (auth.test ok)
• ✅ Socket Mode enabled in Slack app (apps.connections.open returns no warning)
• ✅ Event Subscriptions enabled with required events
• ✅ Bot is a member of the channels (conversations.info returns is_member: true)
• ✅ Required OAuth scopes granted (post-reinstall)
• ✅ Per-channel requireMention: false set in config
• ✅ groupPolicy: open at channel level
• ✅ Session created with correct deliveryContext
• ✅ Model generates complete reply with stopReason: stop
• ✅ Outbound chat.postMessage works when invoked directly with the same bot token
• ❌ No outbound chat.postMessage calls in the gateway log at any point
• ❌ No error logged in gateway.err.log to explain the missing send
• ❌ Delivery queue is empty (so it's not "queued and stuck")

Hypothesis

Somewhere between assistant message generated and provider.send() for Slack channel sessions, the delivery is being short-circuited. Possibly:

• A condition guard returns early without logging (the slack-auto-reply module logs skipping channel message for channels not in the allowlist — perhaps a similar silent skip exists for already-routed sessions)
• The delivery context is correctly attached to the session but not consumed at reply time for slack:channel: keys (vs. slack:im: or telegram:direct: which do work)
• A race between session creation and config reload around channel allowlists

I have not stepped into the dist code far enough to confirm; happy to provide more transcript samples or run with --verbose --ws-log full if helpful.

Severity

High in practice for any Slack channel user, because there's no surfaced error and no user-visible indication that anything failed — they just see no reply.

Workaround

Currently none. requireMention=false and manual chat.postMessage via curl both confirm the rest of the stack is fine; the bug is specifically in the session-to-Slack outbound dispatch.

Related observation

The openclaw.runtime-context JSON envelope (which is documented as out-of-band trusted metadata) is sometimes appearing inside the user message body for Telegram messages. This is a separate, possibly related delivery/envelope-handling issue worth tracking.

Generated with assistance during a live debugging session by an OpenClaw agent.