openclaw - 💡(How to fix) Fix [Bug]: Slack async exec completion replies escape originating thread [3 comments, 3 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In a Slack channel thread, an assistant reply triggered by an async exec completion event is delivered as a top-level channel message instead of staying in the originating Slack thread.

Steps to reproduce

1. Start OpenClaw with Slack enabled and channels.slack.replyToModeByChatType.channel set to all.

2. In Slack, send a message to the assistant inside an existing channel thread.

3. In that threaded assistant turn, start an exec/tool command that completes asynchronously after the assistant turn has ended.

4. Exact command used for the observed repro:

   python3 - <<'PY'
   print('ROUTING_REPRO_MARKER_20260426_1408')
   PY

   The command was started with a very short foreground wait so OpenClaw returned before completion and later injected the async completion event.

5. Wait for the async completion event.

6. Let the assistant relay the completion output back to Slack.

Expected behavior

The assistant's async completion relay should be posted in the original Slack thread that started the command.

Actual behavior

The assistant's async completion relay was posted as a top-level message in the same Slack channel, not in the original thread.

The relayed message contained this marker:

ROUTING_REPRO_MARKER_20260426_1408

Normal assistant replies before and after this async completion were delivered correctly in the original Slack thread, so the failure appears specific to async completion-event routing rather than general Slack thread delivery.

OpenClaw version

2026.4.23 (a979721)

Operating system

macOS / Darwin 25.3.0 (arm64)

Install method

Homebrew/global CLI install

Model

openai-codex/gpt-5.5

Provider / routing chain

OpenClaw -> OpenAI Codex provider

Additional provider/model setup details

No special model routing detail appears necessary for this repro. No provider credentials or account-specific details are included here.

Logs, screenshots, and evidence

Sanitized observed sequence:

1. Slack thread-started assistant session posts a normal reply correctly in-thread.
2. Assistant starts an async exec command from that same threaded session.
3. Async exec completes successfully and emits marker:
   ROUTING_REPRO_MARKER_20260426_1408
4. Assistant relays the completed command output.
5. Relay message appears at Slack channel root instead of as a thread reply.
6. Subsequent normal assistant replies in the same session again appear in the original thread.

Relevant sanitized Slack config:

{
  "channels": {
    "slack": {
      "replyToModeByChatType": {
        "channel": "all"
      },
      "thread": {
        "requireExplicitMention": true
      }
    }
  }
}

Impact and severity

Affected: Slack channel-thread users using async/tool completion flows.

Severity: High for active Slack workspaces, because async/tool completion replies can escape the original thread and clutter the channel root.

Frequency: Reproduced once with the minimal async exec marker above; similar async/background thread leaks have been observed repeatedly in real Slack use.

Consequence: Follow-up messages lose conversation context and appear in the wrong Slack location.

Additional information

This looks related to, but narrower than, #62736. The previously discussed subagent path was less clean in this environment; the async exec completion marker above is the clearest deterministic repro.

A likely area to inspect is how async completion events preserve the originating user-facing Slack route. The completion event should carry or recover an immutable route including provider/channel target/account/thread id, instead of deriving delivery from the internal async event source.

Suggested regression test:

1. Create a synthetic Slack channel-thread session with channel reply mode all.
2. Trigger an async exec completion event after the original assistant turn has ended.
3. Assert the outgoing Slack payload includes the original thread id.
4. Assert it is not sent as a top-level channel message.