openclaw - 💡(How to fix) Fix [Bug]: sessions_spawn fails with thread_binding_invalid on Discord channels [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Spawning a Codex ACP session as a thread from a top-level Discord channel fails with thread_binding_invalid on [email protected].

Steps to reproduce

1. Send a message in a Discord channel where the agent is active
2. Ask the agent to open a Codex ACP session as a thread (sessions_spawn with runtime="acp", thread=true)
3. Spawn fails before a thread is created

Expected behaviour

A new thread gets created in the channel and the ACP session is bound to it. This is what happens when I create the thread manually first and then bind ACP to that thread - so the end-state works, just not via the agent-initiated path.

Actual behaviour

The spawn errors with:

errorCode: "thread_binding_invalid"
Session binding adapter failed to bind target conversation

No thread is created.

OpenClaw version

2026.4.21

Logs, screenshots, and evidence

Turning on verbose logging and working backwards, the conversationId reaching the binding adapter has a channel: prefix on it (my channel id came through as channel:<snowflake> rather than just <snowflake>). That gets handed to Discord's REST API where it 404s. The 404 looks like it's caught by a logVerbose so the outer error is the generic thread_binding_invalid rather than the 404 itself.

Grepping for where the conversationId gets set ended at this line in dist/extensions/discord/thread-bindings.manager-*.js (line 414 on 4.21 for me):

const conversationId = normalizeOptionalString(input.conversation.conversationId) ?? "";

I can't tell for sure where the channel: / user: / dm: prefix is being prepended upstream. It does look like this spot isn't stripping it before passing to Discord, though. Stripping the prefix locally does make the spawn succeed, at least on my machine.

Impact and severity

Affected: Discord users trying to spawn ACP sessions as threads directly from a channel message. Severity: Annoying - blocks the agent-initiated thread workflow. Frequency: Always (observed on every attempt). Consequence: Users have to create the thread manually first and bind ACP to it, which defeats the point of thread=true on the spawn.

Additional information

This used to work for me on an earlier version but I can't remember which one - sorry, that's the best I've got for a last-known-good. First known bad on my end is 2026.4.10, and I've been running a small local edit at that line since 2026-04-11 that strips a leading channel: / user: / dm: from the conversationId before it's passed on. That has kept the spawn working for me since.