Description

After an ACP task (Codex) completes in a Discord thread, subsequent messages sent by the user in the parent channel (not the thread) are still routed to the thread session. The channel session only recovers after the second message.

Environment

• OpenClaw version: 2026.3.31
• Channel: Discord (guild channels with threadBindings.enabled: true)
• ACP backend: acpx with Codex
• Config: session.threadBindings.idleHours: 2 (also reproduced with default 24h)

Steps to Reproduce

1. In a Discord channel, initiate a task that spawns a Codex ACP session
2. A thread "🤖 codex" is automatically created, bound to the ACP session
3. Wait for Codex to complete the task
4. The channel receives the completion notification
5. Send a new message in the parent channel (not in the thread)

Observed Behavior

• The first message sent in the parent channel after task completion is routed to the thread session — the agent replies inside the thread instead of in the channel
• Only the second message sent in the channel is correctly handled by the channel session

Expected Behavior

• After ACP task completion, the thread binding should be immediately released (or at least not "refreshed" by the completion event)
• Messages sent in the parent channel should always be handled by the channel session, regardless of whether a recently-completed thread exists
• The thread should only capture messages actually sent inside the thread

Root Cause Hypothesis

The task flow completion event is delivered through the parent session, which refreshes the thread binding's "last active" timestamp. This causes the session router to treat the thread as still active and route the next channel message into it. After that first (misrouted) message is processed, the binding state updates and subsequent messages route correctly.

Suggested Fix

• Do not refresh thread binding timestamps when delivering internal task completion events
• Or: immediately unbind the thread session when the associated ACP task reaches a terminal state (succeeded/failed/cancelled)
• Or: add a completion_only flag to thread bindings that prevents user message routing but allows completion delivery

Related

• [Bug]: Task flow completion leaks internal routing metadata into Discord channel #59025 (task completion metadata leakage)
• [Bug]: Telegram forum topic loses ACP/OpenCode routing after heavy bound turn; topic recovers only after gateway restart and then fails again under load #44492 (Telegram topic loses ACP routing after heavy bound turn)
• Prevent fake-progress messages with a runtime pre-send policy layer #50690 (pre-send policy layer)

Additional Context

This issue is specific to the new task flow routing in 2026.3.31 ("route one-task ACP and subagent updates through a parent task-flow owner context"). The previous webhook-based delivery did not have this problem because completion notifications were sent via Discord webhook directly, bypassing session routing entirely.