openclaw - 💡(How to fix) Fix ACPX stale child session can respawn and inject old task output into Telegram thread [2 comments, 3 participants]

Summary

After fixing the local ACPX npx adapter problem, a Claude ACP child session continued to inject stale background-task output into the requester Telegram thread. Killing the ACP wrapper process was not sufficient: the gateway respawned the wrapper because the persisted ACPX session state remained open.

This looks separate from #73202. #73202 covered live npx adapter resolution at gateway startup. This report is about ACP child session lifecycle, stale session resumption, and delivery routing back into an active Telegram agent thread.

Environment

• OpenClaw: 2026.4.25 stable, build aa36ee6
• macOS: 26.4.1 arm64
• Node: 22.22.2
• Gateway: LaunchAgent, local loopback, reachable
• ACPX plugin enabled
• Claude ACP adapter configured via plugins.entries.acpx.config.agents.claude.command
• Telegram default account enabled and connected

What happened

1. A Telegram user asked the main/default bot to reset context and continue normal work.
2. Instead of the normal main agent response, the Telegram thread received stale ACP background-task notifications like:
   • Compacting...
   • Background task done: V8.2.3 MR remediation Claude Code (run 6340).
3. The task text sent to the ACP run was not the intended MR task. It was the later Telegram prompt intended for the main bot.
4. openclaw tasks list --runtime acp --status running --json showed no running ACP tasks.
5. openclaw tasks audit --json still showed many ACP task flows with:
   • syncMode: task_mirrored
   • owner/requester pointing back to the default Telegram direct session
   • repeated stale goal text from the older ACP task
   • terminal statuses (succeeded or failed)
   • notifyPolicy: done_only
6. The persisted ACPX session state still had:
   • closed: false
   • same Claude ACP session ID
   • same ACP record ID
   • old cwd from the original task
   • recent last_request_id
   • wrapper PID recorded
7. Killing the wrapper and child Claude process stopped it briefly, but the gateway later started a new wrapper process for the same persisted ACP session.

Expected behavior

• Terminal ACP tasks should not continue to route output into the original requester Telegram thread as if they are the live main agent.
• Killing an ACP child process should not cause the gateway to silently resume a stale terminal session unless an active task explicitly requires it.
• If an ACP session is terminal, failed, cancelled, or orphaned, ACPX should mark it closed or quarantine it.
• A Telegram direct session should not be hijacked by stale ACP task-flow delivery after the user has returned to normal agent conversation.

Actual behavior

• A stale Claude ACP session remained open and resumable after terminal task flows.
• The gateway respawned the Claude ACP wrapper after manual kill.
• New Telegram prompts were captured/delivered through the stale ACP flow.
• The user saw misleading "Background task done" messages in the live bot thread.

Local mitigation

I removed only the Claude ACP adapter registration:

"plugins": {
  "entries": {
    "acpx": {
      "enabled": true,
      "config": {
        "agents": {}
      }
    }
  }
}

ACPX remains enabled so Codex ACP can still be used. This stopped the immediate Claude ACP respawn path locally.

Why this seems upstream-worthy

This is not just a bad local task. The surprising behavior is that OpenClaw had terminal ACP task flows and no running ACP tasks, while a persisted ACPX session remained closed:false and could respawn/re-deliver into the requester Telegram thread. The system needs a lifecycle guard between task-flow completion, ACP process supervision, persisted session state, and channel delivery.

Suggested fixes

• Mark ACPX sessions closed when their owning task flow reaches terminal state and no active wait/session consumer remains.
• Do not auto-respawn ACP wrappers for terminal/orphaned ACP sessions.
• Add openclaw acp sessions list/close/cancel or equivalent doctor repair for orphaned ACPX sessions.
• Quarantine stale ACP delivery if the requester channel session has moved on or if the task flow goal/request ID does not match the latest user turn.
• Surface stale open ACPX sessions in openclaw doctor and openclaw tasks audit.