openclaw - 💡(How to fix) Fix [Feature] Default ACP thread-binding preset (or opt-in config flag) — third-party channels currently re-implement ~870 LOC each

Problem

sessions_spawn(runtime="acp", mode="session", thread=true) fails with thread_binding_invalid on every channel that does not register a SessionBindingAdapter. Today this includes the most-used third-party channel — WeChat / openclaw-weixin — and several first-party channels (slack, line). The result on those channels is a degenerate "agent replies once and stops" experience: the spawned ACP session runs one turn, never continues, and the user has no way to keep the conversation going.

This bug just bit me again live with openclaw-weixin → claude-agent-acp:

session: d71a7917-3a3c-477d-9402-5ac70d812178
spawnedBy: agent:main:openclaw-weixin:<bot>:direct:<sender>
runtimeMs: 133153
usage:    0 tokens
stopReason: stop
contents: 1 placeholder text message ("我先读取 ppt-master skill 的 strategist 定义...")
            then status=done, no tool use, no follow-up

Snapshot of who has thread-binding today

Reading upstream/main aeba1d6b47:

The shared base (src/infra/outbound/account-scoped-conversation-bindings.ts, ~350 LOC) and the manifest seam (src/channels/plugins/types.adapters.ts:837-843's conversationBindings.createManager) already exist, but the integration cost per channel is still steep enough that:

1. New channel plugins ship without thread binding (LINE has the manifest field but no adapter — the manifest is an empty promise)
2. Third-party plugin maintainers re-invent ~870 LOC to wire it up (Tencent/openclaw-weixin#56)

Proposal

Add createDefaultDmThreadBindingManager(...) preset to openclaw/plugin-sdk/thread-bindings-runtime so plugin authors can register a working adapter in ~10 LOC instead of 870.

Default binding key: (accountId, conversationId, senderId) — three-tuple, not (accountId, conversationId).

Why per-sender as the default

OpenClaw already has three layers of group-safety guardrails for normal sessions:

For ACP mode="session", layer (c) is bypassed: ACP state lives in the persistent runtime process (cwd, modified files, tool result cache) — not in the per-turn context load. So contextVisibility: "allowlist" cannot retroactively isolate group members from each other once they share an ACP session. Default per-sender keying is the equivalent guardrail at the binding layer, applied before that state ever gets shared.

For 1:1 channels behavior degrades to (accountId, conversationId) — same as imessage/bluebubbles today.

For groups, sharing one ACP session across all members must be opt-in (allowSharedGroupBinding: true).

Open question for review

I lead with the preset proposal but I'd happily take a less aggressive landing if it helps merge:

• (A) Preset with per-sender default + allowSharedGroupBinding opt-in — my preference. New channels and third-party plugins get a working adapter for free; existing channels can adopt incrementally.
• (B) Preset + opt-in config flag — preset exists in plugin-sdk but plugins must explicitly call enableDefaultThreadBinding() to opt in. No default behavior change. This is the safest landing if (A) is too aggressive — even just shipping the preset as a documented helper is a big win for plugin authors.
• (C) Decide on review. Issue body sketches (A); the call is the maintainer's.

Related (would benefit from this preset existing)

• #53548 "Decouple mode=session from thread binding requirement" — adjacent; even with #53548 landing, channels without an adapter still can't do mode=session, thread=true. Both fixes are useful and land in different places.
• Tencent/openclaw-weixin#56 — concrete proof of the duplication cost. If this preset lands, that PR can shrink from ~870 LOC to ~10.
• #60737, #42986 — related channel-specific feature requests that would naturally consume the preset.

Secondary proposal: manifest sanity check

Channels that declare conversationBindings in their manifest but never register an adapter at runtime should emit a manifest-registry warn-level diagnostic. LINE is the example today — declares defaultTopLevelPlacement: "current" but has no adapter, so the manifest is an empty promise.

Environment

• upstream/main aeba1d6b47
• The bug reproduces on every openclaw 2026.5.x release I've tested (2026.5.5, 2026.5.6, 2026.5.7)
• ACP runtime: @agentclientprotocol/[email protected]