openclaw - 💡(How to fix) Fix ACP: keep thread-bound follow-ups parent-orchestrated by default, not raw pass-through [1 participants]

Summary

Thread-bound ACP follow-ups are currently too easy to treat as raw pass-through to the child session, instead of remaining parent-orchestrated by default.

In practice, the first prompt is often synthesized correctly by the parent assistant, but later shorthand follow-ups like:

• "ừa bắt nó làm tiếp như m suggest đi"
• "ok triển khai phase 2 đi"
• "bảo nó làm tiếp theo hướng đó"

can end up being forwarded as-is to the ACP child harness.

Expected behavior

Thread binding should preserve child session continuity, but not imply raw-message forwarding semantics.

Default behavior should be:

1. parent assistant reads the user's shorthand follow-up
2. parent resolves references from parent-thread context
3. parent rewrites the follow-up into an explicit child task
4. parent sends the rewritten task to the bound ACP child session

Raw verbatim relay should happen only when the user explicitly asks for exact forwarding.

Why this matters

Users often speak to the parent orchestrator in shorthand. If the raw message is passed through directly, the child receives low-context prompts and the orchestration UX breaks down.

This is especially visible in ACP thread-bound coding workflows where the user expects:

• user message -> parent interprets and expands
• parent prompt -> child executes

not:

• user message -> raw forward -> child guesses

Evidence / current architecture notes

Observed locally:

• initial ACP thread spawn used sessions_spawn(runtime="acp", thread=true, mode="session")
• first child prompt was explicitly synthesized by the parent
• later shorthand follow-up was effectively treated as pass-through
• child saw the raw user text rather than a rewritten explicit task

Potentially relevant code paths:

• src/gateway/server-methods/sessions.ts
• src/gateway/session-subagent-reactivation.ts
• thread-bound session continuation / reactivation behavior after sessions.send

The current accepted note for ACP session spawns says:

"thread-bound ACP session stays active after this task; continue in-thread for follow-ups."

That note is correct for continuity, but ambiguous enough that it can lead to a pass-through mental model in parent orchestration.

Proposed direction

• Keep thread-bound ACP continuity
• Clarify policy: continuity != verbatim relay
• Ensure parent remains the default interpreter/orchestrator for follow-ups
• Only relay exact raw messages when the user explicitly requests verbatim forwarding

Acceptance criteria

• existing thread-bound ACP child session exists
• user sends shorthand continuation request
• parent rewrites it into a self-contained child task
• child receives rewritten task, not raw user message
• exact raw relay occurs only on explicit request