Summary

On my installed OpenClaw build (2026.4.5 from npm), Discord ACP thread spawns fail with:

• thread_binding_invalid
• Session binding adapter failed to bind target conversation

This happens for sessions_spawn({ runtime: "acp", thread: true, mode: "session" }) in a normal Discord guild text channel, even when:

• session.threadBindings.enabled = true
• channels.discord.threadBindings.enabled = true
• channels.discord.threadBindings.spawnAcpSessions = true
• the bot has Administrator, CreatePublicThreads, SendMessagesInThreads, and ManageThreads

What I verified

Discord itself is healthy:

• normal Discord thread creation succeeds
• webhook creation succeeds
• direct use of the thread binding manager succeeds when given a raw numeric channel id

The failure reproduces specifically when the ACP thread-binding path uses a canonical Discord target like:

• channel:1487184723871531109

instead of the raw parent channel id:

• 1487184723871531109

Minimal diagnosis

In the installed build, the ACP thread-binding preparation path appears to resolve the Discord conversation as channel:<id>, then later passes that canonical target into child thread binding as if it were the parent channel id.

For Discord child thread creation, that value needs to be normalized back to the raw channel id before binding.

I verified this by reproducing both cases directly against the installed build:

• conversationId = "1487184723871531109" + child placement => works
• conversationId = "channel:1487184723871531109" + child placement => fails with the same binding error

Repro shape

Discord channel context:

sessions_spawn({
  runtime: "acp",
  agentId: "claude",
  thread: true,
  mode: "session",
  cwd: "...",
  task: "Say hi"
})

Expected:

• OpenClaw creates a Discord thread
• binds the ACP session to that thread

Actual:

• thread_binding_invalid
• Session binding adapter failed to bind target conversation

Notes

I looked at current upstream source and it seems this normalization path may already be correct on main, so this may be a release/bundled artifact regression rather than a source-of-truth logic bug.

I’m sending a small regression-test PR alongside this issue so the Discord ACP thread-spawn path stays covered.