#sessions_spawn(runtime="acp") says ACP not configured, but host gateway shows acpx loaded and ACP ba

1 messages · Page 1 of 1 (latest)

placid rapids
#

Summary:
On Ubuntu host tc1-kenobi, OpenClaw host-side ACP appears correctly installed and active, but ACP spawns from a Telegram-bound assistant session fail immediately with:

ACP runtime backend is not configured. Install and enable the acpx runtime plugin.

Host-side evidence:

• @openclaw/acpx installed from ClawHub
• plugin enabled
• openclaw plugins inspect acpx shows Status: loaded
• openclaw plugins list shows acpx enabled
• /home/cmb/.openclaw/extensions/acpx/node_modules/.bin/acpx --version returns 0.6.1
• ~/.openclaw/openclaw.json contains:
• acp.enabled = true
• acp.backend = "acpx"
• acp.dispatch.enabled = true
• plugins.entries.acpx.enabled = true
• gateway restarts cleanly
• gateway logs show:
• embedded acpx runtime backend registered lazily

Critical mismatch:
When ACP spawn is attempted via sessions_spawn(runtime="acp", ...), it fails immediately with the “not configured” error, and no corresponding ACP request/error appears in the host gateway logs.

Conclusion:
The failure appears to happen upstream of the host gateway/runtime, not on the Ubuntu host itself.

Environment:

• OpenClaw: 2026.5.7
• Host: Ubuntu
• Surface: Telegram direct session

modern epochBOT
#

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

pearl radishBOT
#

This is a good write-up. The key thing I’d check next is from the same Telegram-bound assistant session, not just from the Ubuntu shell/gateway process.

ACP runtime backend is not configured is emitted when the in-process ACP runtime registry has no backend registered. So host CLI evidence like plugins inspect acpx: loaded proves the Gateway/plugin side is healthy, but it doesn’t fully prove the assistant runtime handling that Telegram turn sees the same ACP backend registry/config.

Please try these in the Telegram session that is failing:

/acp doctor
/status

What I’d look for:

  • /acp doctor should show configuredBackend: acpx and registeredBackend: acpx / healthy: yes.
  • If it shows registeredBackend: (none) there while the host logs say acpx loaded, that strongly points to a session/runtime wiring bug or stale assistant runtime, not an acpx install problem.
  • If /status/tooling does not advertise ACP availability, same conclusion.