Summary

OpenClaw needs a first-class workflow for ACP on direct-message / non-thread surfaces (for example Telegram DM, webchat DM, Feishu DM, Slack DM) so long-running coding-agent work can proactively notify the user when it finishes.

Today, ACP behavior on DM / non-thread surfaces falls into an awkward gap:

• mode: "session" requires thread: true
• but many DM surfaces do not support ACP thread binding
• mode: "run" can be accepted, but there is no consistent first-class parent/user notification path after completion
• users are forced into ad-hoc fallbacks such as manual sessionKey bridging, polling, or waiting until the next user message

This makes ACP coding-agent workflows feel incomplete on the exact surfaces where users most naturally want them: private chats.

Problem statement

There are really two separate concerns that are currently entangled:

1. Session persistence / logical continuity
   • keep an ACP session alive or at least resumable across turns
2. User-facing completion delivery / proactive notification
   • once the ACP run finishes, notify the parent session or the user

On thread-capable surfaces, thread binding often solves both at once.
On direct chats and non-thread surfaces, neither currently has a first-class product path.

Current user impact

On DM / non-thread surfaces, users who want to say things like:

• "Run this in Claude/Codex and tell me when it's done"
• "Start a coding task in private chat and notify me when the task finishes"
• "Kick off a long ACP run from DM and keep me posted"

hit one of these outcomes:

• mode: "session" is blocked by thread binding requirements
• mode: "run" completes without a clean proactive notification path
• operators must build local workarounds:
  • track childSessionKey
  • manually use sessions_send
  • add visibility / agent-to-agent config
  • poll sessions_history or other status manually
  • or only discover results when the user sends another message

That fallback is possible, but it is not a good default UX.

Expected behavior

OpenClaw should support a clear DM-safe ACP story, ideally one of these:

Option A — decouple persistence from thread binding

Allow mode: "session" without requiring thread: true.

That would enable a headless persistent ACP session that is not platform-thread-bound but can still:

• receive follow-up messages
• receive child/session announces
• surface completion back to the parent session

Option B — first-class completion relay for mode: "run"

Keep run as one-shot, but add a first-class completion delivery path for non-thread surfaces:

• parent session receives a runtime completion event when the ACP run finishes
• or OpenClaw automatically relays final output back to the originating DM session
• or OpenClaw offers an explicit built-in notifyParent / notifyUserOnComplete path

Option C — built-in DM notification workflow

If neither A nor B is immediately possible, provide an explicit productized fallback:

• store ACP run identity + originating session metadata
• on completion, emit a parent/user notification event
• avoid requiring userland polling or manual sessionKey bridging

Why this matters

ACP is especially valuable for:

• long-running coding tasks
• multi-step planning and implementation
• background work that should report back later

Those workflows are highly natural in DMs/private chats.
Right now OpenClaw works best when the surface already supports thread binding, which leaves DM users with a noticeably worse ACP experience.

Suggested design direction

A strong direction would be:

1. Decouple session persistence from thread binding

   • mode: "session" should mean durable logical session
   • thread: true should mean platform thread binding, only when supported

2. Add a parent/user completion relay for ACP runs

   • every ACP run should have a reliable completion delivery path
   • especially for DM / non-thread surfaces

3. Preserve channel safety

   • DM completion relay should notify only the originating conversation/user
   • no cross-chat leakage
   • explicit origin metadata should be used for delivery

Related issues

This looks adjacent to existing ACP/session issues, but distinct in focus:

• #23414 — mode="session" requires thread=true
• #47348 — Telegram DM ACP unusable (run failures + session blocked)
• #37869 — ACP session accepted but never closes the loop
• #35028 — ACP transcript/history persistence gap
• #41116 — Discord DM ACP thread binding failure

This issue is specifically about the product gap for proactive completion delivery on DM / non-thread surfaces.

Minimal ask

Please define and support an official path for:

"Start ACP from a private chat, let it work, and proactively notify the user when it finishes."

Without requiring operators to build custom polling / bridge logic around sessionKeys.