#Discord threads and ACP sessions.

1 messages · Page 1 of 1 (latest)

vale narwhal
#

I started a thread-bound persistent ACP session via sessions_spawn with:
runtime="acp", agentId="pi", mode="session", thread=true, sandbox="inherit", cleanup="keep", cwd="/home/kira/.openclaw/workspace/dashboard-mvp" (with a test label and a simple “reply OK” task).

Main issue: session execution works, but delivery binding is flaky — first reply route correctly to the Discord thread (sourceChannel=discord), while others return only as internal tool replies (sourceChannel=unknown), so the agent response does not appear in-thread even though the run succeeded.

vale narwhal
#

@solar nest any ideas?

solar nestBOT
#

Yeah — that symptom usually means execution is fine, but delivery context/binding is getting lost after the initial turn.

Most useful first check: what version are you on?

openclaw --version

If you’re not on latest, update first — there were recent ACP/thread routing fixes around this area (3.11–3.13).

Then verify binding config is fully enabled:

openclaw config get session.threadBindings
openclaw config get channels.discord.threadBindings
#

For ACP thread-bound spawns on Discord, you want at least:

  • session.threadBindings.enabled: true
  • channels.discord.threadBindings.enabled: true
  • channels.discord.threadBindings.spawnAcpSessions: true

In-thread, check what OpenClaw thinks is bound:

  • /acp status
  • /acp sessions

If it still flips to sourceChannel=unknown, grab a live log while reproducing one good + one bad follow-up:

openclaw logs --follow
#

Look for lines containing:

  • thread binding
  • no-requester-match
  • no-active-binding
  • sourceChannel

If you share:

  1. openclaw --version
  2. the two config get outputs above
  3. a short log snippet around one failed follow-up

…I can help pinpoint whether this is config drift vs a runtime bug.

Docs for reference: