Summary

ACP child runs can complete successfully, but the final result is not delivered back to a direct chat channel. In my case this is reproducible with WhatsApp direct chat and Codex via runtime="acp".

This looks like a behavior gap between:

• WhatsApp -> OpenClaw -> ACP/acpx -> Codex which works
• Codex final result -> original direct chat which does not happen

Including lobster-biscuit per the issue guide.

Repro Steps

1. Enable ACP with acpx and set acp.defaultAgent = "codex".

2. Enable and link the WhatsApp channel.

3. From a WhatsApp direct chat, send:

   请把这个任务交给 Codex 执行，并把 Codex 的原始最终结果转发给我：只回复 CODEX_OK。

4. Wait for the ACP child run to complete.

Expected

The final Codex result should be delivered back to the originating direct chat, for example:

CODEX_OK

Actual

The ACP child run completes and the result appears in logs, but there is no final outbound message to the originating WhatsApp chat.

Observed logs:

03:23:13 info gateway/channels/whatsapp/inbound {"subsystem":"gateway/channels/whatsapp/inbound"} Inbound message +8618721113719 -> +8618721113719 (direct, 130 chars)
03:23:29 info CODEX_OK

What is missing after completion:

• no web-auto-reply with text:"CODEX_OK"
• no gateway/channels/whatsapp/outbound for the final ACP result

Environment

• OpenClaw version: 2026.3.13
• Install type: Homebrew/macOS
• ACP backend: acpx
• ACP default agent: codex
• Channel: WhatsApp direct chat
• Gateway health: OK
• acpx plugin status: loaded

Relevant config:

{
  "acp": {
    "enabled": true,
    "dispatch": { "enabled": true },
    "backend": "acpx",
    "defaultAgent": "codex"
  },
  "plugins": {
    "entries": {
      "acpx": {
        "enabled": true
      }
    }
  },
  "channels": {
    "whatsapp": {
      "enabled": true
    }
  }
}

Impact

This breaks the end-to-end user expectation for direct chat channels:

• user asks OpenClaw in chat to use Codex
• OpenClaw actually dispatches to Codex
• Codex completes
• but the final result is never returned to the original chat

This makes ACP usable as an execution layer, but not as a complete chat-facing delegation flow for direct chat surfaces.

Workarounds

• Local runtime patch to explicitly route ACP child output back to the original direct chat target
• Use non-chat/manual inspection of logs to confirm completion

I tested a local patch and confirmed that direct outbound delivery can work, but I reverted it to stay on official behavior before filing this issue.

Notes

From reading the docs, this may be related to how sessions_spawn(runtime="acp", streamTo="parent") currently emits progress/system events to the parent session without a guaranteed final direct-channel delivery step for non-threaded direct chats.