openclaw - 💡(How to fix) Fix ACPX extension declares acpx 0.5.3; acpx 0.6.0 needed for reliable ACP thread sessions after upgrade [2 comments, 3 participants]

Summary

After upgrading OpenClaw to 2026.4.24, ACP thread sessions only verified successfully after reinstalling [email protected] plugin-locally under the bundled ACPX extension.

The bundled extension still appears to declare acpx: 0.5.3, and the OpenClaw upgrade wiped the previous plugin-local [email protected] override. Reapplying the plugin-local 0.6.0 install restored ACP thread proof success.

This is probably best treated as a packaging / compatibility question rather than a confirmed runtime bug: should the bundled @openclaw/acpx extension depend on [email protected], or should OpenClaw preserve/document extension-local ACPX overrides during upgrades?

Environment

• OpenClaw: 2026.4.24 (cbcfdf6)
• Platform: macOS arm64, Node 25.8.2
• ACP backend: acpx
• ACP runtime path used through OpenClaw sessions_spawn, not direct PTY scraping
• Bundled extension metadata after upgrade:
  • extension: @openclaw/acpx
  • extension version: 2026.4.20
  • declared dependency: acpx: 0.5.3
• Plugin-local installed package after workaround:
  • installed acpx: 0.6.0
  • .bin/acpx -> ../acpx/dist/cli.js

What happened

1. Before the OpenClaw upgrade, I had a plugin-local [email protected] override installed under the bundled ACPX extension.
2. Upgraded OpenClaw to 2026.4.24 using the pinned global package upgrade flow, then regenerated/restarted the gateway.
3. Post-upgrade, the extension directory still existed, but the plugin-local ACPX install was gone:
   • dist/extensions/acpx/node_modules/acpx/package.json missing
   • dist/extensions/acpx/node_modules/.bin/acpx missing
4. The extension package still declared acpx: 0.5.3.
5. Reinstalled [email protected] plugin-locally under dist/extensions/acpx/.
6. Restarted the gateway.
7. ACP thread proof succeeded after the local 0.6.0 install.

Verification after workaround

After reinstalling plugin-local [email protected] and restarting the gateway:

• openclaw doctor --non-interactive: exit 0, Errors: 0
• Smoke suite: 36 total / 33 pass / 0 fail / 1 warn / 2 limited
• ACP thread proof via OpenClaw ACP runtime succeeded with marker:
  • ACP_424_V060_OK
• Managed browser profile sanity check also passed separately.

The remaining smoke non-pass items were non-blocking in this environment:

• WARN: ACP identity reconcile 3/3 resolved
• LIMITED: main inference skipped because fast smoke was used
• LIMITED: direct Claude CLI credentials optional, not the configured main fallback path

Expected behavior / question

One of the following would make the path less fragile:

1. Bundle [email protected] with the OpenClaw ACPX extension if it is the expected compatible version.
2. Document that @openclaw/acpx currently expects [email protected] and that 0.6.0 is unsupported / not needed.
3. If extension-local overrides are supported, preserve them across OpenClaw upgrades or document that upgrades wipe them and users must reapply.

Why this matters

The workaround is effective but fragile: every OpenClaw upgrade can overwrite/remove the plugin-local [email protected] install, causing ACP thread runtime verification to regress until the override is reapplied.

Happy to provide more sanitized details if useful.