#acp commands not working in threads

12 messages · Page 1 of 1 (latest)

bronze meadow
#

any /acp commands within the discord thread that started with /acp bind here doesn't do anything. all OpenClaw replies to is "done"

the /acp commands work inside the parent thread, but it operates under the context of the parent thread ( this is annoying because I have to pass the long thread ids as a workaround)

plucky oliveBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

rustic skyBOT
#

Yeah, I’m pretty sure this is a real bug, not a config mistake.

/acp spawn ... --bind here is documented to bind the current Discord channel or thread in place, and spawnAcpSessions is only needed for --thread auto|here, not for --bind here:
https://docs.openclaw.ai/tools/acp-agents
https://docs.openclaw.ai/channels/discord

What it looks like is happening:

  • normal inbound thread messages resolve the current-conversation binding correctly
  • native Discord /acp slash commands in that same thread do not resolve that binding the same way
  • so the slash command gets ACKed and falls back to a generic "done" reply, or resolves against the parent thread context instead

So the short version is: Discord thread + /acp ... --bind here seems broken for follow-up native /acp commands.

Workarounds for now:

  1. Prefer /acp spawn codex --thread here instead of --bind here if you want that thread to be the ACP workspace
    • this uses the thread-binding path instead
    • requires channels.discord.threadBindings.spawnAcpSessions=true
#
  1. Otherwise keep targeting from the parent with explicit --thread <id> or --session <key>

One quick check first, what does openclaw --version show? If you’re already on the latest build, I’d treat this as GitHub-issue-worthy, because the docs say it should work.

bronze meadow
#

whats the difference between /acp spawn --thread here vs /acp spawn --bind here ?

rustic skyBOT
#

Short version:

  • /acp spawn ... --thread here

    • thread-specific
    • requires you to already be inside a thread
    • binds the ACP session to that thread via the thread-binding path
    • on Discord, this path depends on channels.discord.threadBindings.spawnAcpSessions=true

  • /acp spawn ... --bind here

    • generic current-conversation binding
    • pins whatever conversation you’re in, channel or thread, without creating a child thread
    • does not need spawnAcpSessions

Practical difference:

  • in an existing Discord thread, they’re supposed to feel very similar
  • but right now, for your bug, --thread here is the better workaround because Discord native /acp follow-ups seem to resolve thread bindings more reliably than current-conversation binds
bronze meadow
#

your advice are bad, even in a thread , that was spanwed using --thread ehre, any /acp commands are ignored / reutnred done

rustic skyBOT
#

You’re right, that advice was bad. Sorry. I dug deeper, and this looks broader than --bind here.

I now think native /acp commands in Discord threads are broken in general right now, including threads started with --thread here.

Why I think that:

  • the "Done." reply is the native slash-command fallback when the command got ACKed but no real reply payload was rendered
  • Discord thread message routing and Discord thread native /acp slash-command routing go through different code paths
  • the thread message path appears to resolve bindings differently than the native slash path

So I would not keep tweaking config for this one. It smells like a real bug.

What I’d trust as the current workaround:

  • run the /acp lifecycle commands from outside the thread, and target explicitly with --thread <id> or --session <key>

What would help confirm it fast:

  • paste openclaw --version
#

If you’re on latest, I’d file this as a bug with this repro:

  1. create or use a Discord thread
  2. run /acp spawn codex --thread here
  3. then run /acp status in that same thread
  4. result is just "Done."

Issue link: https://github.com/openclaw/openclaw/issues

If you want, I can write the bug report text for you so you can paste it in directly.

bronze meadow
#

whats the difference between acp.runtime.ttlMinutes vs plugins.entries.acpx.config.timeoutSeconds in openclaw.json

rustic skyBOT
#

They control different clocks.

  • acp.runtime.ttlMinutes

    • idle lifetime for ACP runtime workers
    • after a session sits unused that long, OpenClaw can clean up the cached runtime/handle
    • this is about how long the ACP worker stays warm between commands
    • it does not limit a single command/turn

  • plugins.entries.acpx.config.timeoutSeconds

    • per-turn timeout for the embedded acpx runtime
    • if one ACP turn runs longer than this, that turn gets aborted
    • this is about how long one command is allowed to run
    • default is 120

So the mental model is:

  • ttlMinutes = “how long can this ACP session sit idle before cleanup?”