Bug type

Behavior bug (incorrect output/state without crash)

Summary

sessions_send reaches the target ACP worker session and gets an internal reply, but the reply is not posted visibly into the target worker’s bound Discord thread/channel.`

Steps to reproduce

1.	Spawn a persistent ACP worker thread in a worker channel.
2.	From a separate coordinator channel session, send a minimal sessions_send instruction to that worker, such as “Reply with one word only: test-reply”.
3.	Observe that the sender session reports an internal worker reply.
4.	Observe that no visible assistant reply appears in the target worker’s bound Discord thread.
5.	Confirm that ordinary visible bot posts into the worker lane still work.

Expected behavior

A message sent from one coordinating session to an active ACP worker session should result in the worker’s reply appearing visibly in the target worker’s bound Discord thread.

Actual behavior

sessions_send reaches the target ACP worker session and returns the worker reply internally to the sender session, but that reply is not posted visibly into the target worker’s bound Discord thread. Ordinary visible bot posts into that worker lane still work.

OpenClaw version

Version: OpenClaw 2026.3.11

Operating system

macOS 26.3.1

Install method

Global npm install

Model

openai-codex/gpt-5.4

Provider / routing chain

Discord -> OpenClaw Gateway -> ACP bridge (acpx) -> openai-codex provider -> openai-codex/gpt-5.4

Config file / key location

~/.openclaw/openclaw.json Relevant keys: • channels.discord.guilds.<guild_id>.channels • channels.discord.threadBindings • tools.sessions.visibility • tools.agentToAgent • tools.profile

Additional provider/model setup details

Auth profile: openai-codex:default via OAuth. ACP backend enabled with acpx. Discord channel sessions enabled. Worker threads spawned with persistent ACP thread binding. PM coordination tested from the main Discord channel session, while target workers were active ACP sessions bound to Discord threads. No custom proxy or external router in front of the OpenAI Codex provider beyond the OpenClaw Gateway and ACP bridge.

Logs, screenshots, and evidence

Observed behavior:
	1.	A coordinator session sent a minimal sessions_send instruction to an active ACP worker session bound to a Discord thread.
	2.	The coordinator session reported that the target worker session replied internally with the expected one-word response.
	3.	No visible assistant reply appeared in the target worker’s bound Discord thread/channel.
	4.	Ordinary visible OpenClaw Bot posts into that same worker lane did appear successfully, showing that raw Discord posting into the lane was working.
	5.	This isolates the failure to reply surfacing, not basic channel access or worker execution.

Representative redacted PM/session outputs:
	•	“sessions_send returned  internally from the active worker session, but no visible reply was posted into the active Discord worker thread.”
	•	“visible OpenClaw posts can appear in the worker lane, but sessions_send-triggered worker replies are not being surfaced through that same path.”

Conclusion from reproduced behavior:
	•	PM/coordinator-to-worker dispatch succeeds.
	•	Worker execution succeeds.
	•	Internal return to the sender session succeeds.
	•	Visible mirroring of the worker reply back into the target Discord thread fails.

Most likely failing layer:
ACP session-routing/delivery bridge between sessions_send response handling and the target session’s Discord deliveryContext.

Impact and severity

Affected users/systems/channels:
• Affects any OpenClaw Discord setup using one channel/session as a coordinator and separate ACP worker sessions bound to Discord threads
• Affects coordinator channels, worker channels, and their bound ACP Discord threads
• Affects autonomous multi-worker orchestration patterns, especially PM/manager-to-worker coordination

Severity:
• Workflow-blocking for coordinator/worker use in Discord
• Not a data-loss issue in the reproduced case
• High severity for anyone relying on visible worker replies in Discord as part of operational coordination

Frequency:
• Reproduced consistently in this setup
• PM/coordinator dispatch succeeded, internal worker reply succeeded, but visible reply surfacing to the target Discord thread failed each time tested

Consequence:
• Worker replies are not visibly surfaced in the target Discord thread/channel
• Coordinator-to-worker orchestration is only half-functional
• Users cannot rely on Discord as the visible execution/coordination surface
• Forces manual verification, manual relaying, or external artifact checking
• Breaks the expected autonomous PM/coordinator workflow even when worker execution itself succeeds

Additional information

Not known to be a confirmed public regression from a previously working version in this environment. Reproduced on OpenClaw 2026.3.11.

Important triage context:
• Discord posting itself is not the blocker. Ordinary visible OpenClaw Bot posts into the target worker lane/channel succeed.
• ACP worker execution itself is not the blocker. The target worker session does execute and returns internally.
• The failure appears specifically when sessions_send targets an active ACP worker session that has a Discord-bound delivery context: the worker reply is returned internally to the sender/coordinator session, but is not mirrored visibly into the target worker’s bound Discord thread/channel.
• This suggests the failing layer is the ACP session-routing/delivery bridge between sessions_send response handling and Discord delivery-context reply surfacing.
• The bug is especially impactful for Discord-based coordinator/worker patterns where visible worker replies in the target lane are required for autonomous orchestration.