Browser plugin runtime deps stale path after 2026.4.25 → 2026.4.26 upgrade

[bleak prairie]

What I'm trying to do:
Get the browser plugin working after upgrading OpenClaw from 2026.4.25 → 2026.4.26. Want to use Lightpanda as the browser backend via CDP.

What's happening instead:
openclaw browser start fails with ERR_MODULE_NOT_FOUND referencing a runtime deps path from the previous version that no longer exists.

Error:

GatewayClientRequestError: INVALID_REQUEST: Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/civil/.openclaw/plugin-runtime-deps/openclaw-2026.4.25-74d3c00a3608/dist/command-format-CgOiLUfR.js' imported from /home/civil/.openclaw/plugin-runtime-deps/openclaw-2026.4.25-74d3c00a3608/dist/extensions/browser/register.runtime.js

Setup:

• OpenClaw 2026.4.26 (pnpm global install)
• Node.js v22.22.2
• Debian 13 (systemd user service)
• Browser config: default managed profile (removed Lightpanda for now)

What I've tried:

• Patched browser plugin package.json from 2026.4.25 → 2026.4.26 (it ships with wrong version)
• rm -rf ~/.openclaw/plugin-runtime-deps/* + openclaw doctor --fix → rebuilt to 2026.4.26-206fd5b853ba
• systemctl --user stop/start openclaw-gateway → confirmed new PID (2770054)
• Cleared Node.js compile cache (/tmp/node-compile-cache/*)
• Created old runtime deps dir with copied files

None of it worked. The error still references 2026.4.25-74d3c00a3608 even though:

• That directory doesn't exist anymore
• No file on disk references the old module hash (command-format-CgOiLUfR.js)
• The register.runtime.js at the error path references the NEW hash (command-format-BORwwHyH.js)
• The error timestamp is AFTER the gateway restart

Config (browser section):

{
  "browser": {
    "enabled": true,
    "headless": true,
    "noSandbox": false
  }
}

Full logs available if needed.

[dusk coyote]

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

[quiet atlas]

This smells less like Lightpanda/browser config and more like CLI ↔ running Gateway install drift or a stale bundled-runtime mirror.

There’s a known similar failure shape: shell openclaw reports a newer version, but the installed Gateway service is still launched from an older OpenClaw path; browser/plugin errors then look misleading until the Gateway service is re-registered. (github.com) OpenClaw also stages bundled plugin deps under OPENCLAW_PLUGIN_STAGE_DIR, $STATE_DIRECTORY, or ~/.openclaw/plugin-runtime-deps, rather than mutating the package install. (docs.openclaw.ai)

I’d do this next:

openclaw gateway status
openclaw status --all
systemctl --user cat openclaw-gateway
systemctl --user show openclaw-gateway -p ExecStart -p Environment -p FragmentPath
readlink -f "$(command -v openclaw)"
ps -ef | grep -E 'openclaw|plugin-runtime-deps|node' | grep -v grep

If ExecStart or the process list points at anything old / different from the shell CLI install, fix the service registration, not the plugin files:

systemctl --user stop openclaw-gateway
openclaw gateway install --force
systemctl --user daemon-reload
openclaw gateway start
openclaw gateway status
openclaw browser doctor --deep
openclaw browser start

Before install --force, save systemctl --user cat openclaw-gateway if you had custom env/hardening.

I’d also stop copying old runtime-deps dirs around — that can mask the real state. If it still references 2026.4.25-* after the forced service reinstall, this is probably a real 2026.4.26 packaging/runtime-deps regression. Please file a GitHub issue with:

• openclaw status --all
• openclaw gateway status
• systemctl --user cat openclaw-gateway