feat: add configurable OpenClaw runtime version for the add-on

[slawa19]

What problem are you trying to solve?

The add-on currently installs a fixed OpenClaw version during Docker image build.

For example, openclaw_assistant/Dockerfile currently installs openclaw@2026.5.28 together with node-llama-cpp@3.18.1.

Because this version is baked into the Docker image, users cannot persistently run a newer OpenClaw version until the add-on image itself is updated.

If a user manually installs a newer OpenClaw version inside the running container, that change is lost after add-on/container restart or rebuild, because the container is recreated from the image.

This becomes a problem when OpenClaw releases move faster than the Home Assistant add-on image. Users may need a newer OpenClaw version for bug fixes, provider/model support, or gateway behavior fixes, but currently the only durable options are to wait for a new add-on release or fork the add-on repository.

Proposed solution

Add an add-on configuration option that allows users to select the OpenClaw version used at runtime.

Suggested option name: openclaw_version.

Suggested behavior:

• Empty value: keep current behavior and use the OpenClaw version bundled in the Docker image.
• Specific version, for example 2026.6.6: install and run openclaw@2026.6.6.
• Optional value latest: install and run openclaw@latest.

The implementation could use the existing persistent npm mechanism when persist_node_global: true, so the selected OpenClaw version can survive add-on/container restarts and rebuilds.

It would also be useful to log the selected version and binary path clearly at startup.

Example startup log:

• Bundled OpenClaw version: 2026.5.28
• Requested OpenClaw version: 2026.6.6
• Installing package: openclaw@2026.6.6
• Using OpenClaw binary: /data/node-global/bin/openclaw
• Active OpenClaw version: 2026.6.6

Default behavior should remain unchanged when openclaw_version is empty.

Alternatives considered

• Waiting for add-on releases: safest, but it can block users who need fixes or provider/model updates already available in OpenClaw.
• Forking the add-on: works, but is too heavy for regular users and creates maintenance overhead.
• Manually installing OpenClaw inside the container: not durable, because container filesystem changes are lost after add-on/container restart or rebuild.
• Dynamically updating the Dockerfile: not practical at runtime, because the Dockerfile is only used when building the image. A runtime version override is the practical alternative.

Suggested UX / configuration flow

The user opens the Home Assistant add-on configuration and sets the desired OpenClaw version.

Example configuration values:

• persist_node_global: true
• openclaw_version: "2026.6.6"

On startup, the add-on checks the requested version.

If openclaw_version is empty, the add-on uses the bundled OpenClaw version.

If openclaw_version is set, the add-on installs that version into the persistent npm prefix and ensures that selected binary is used for openclaw gateway run.

The startup logs should show the bundled version, requested version, selected binary path, and active version.

Impact

This helps Home Assistant add-on users who need to run a newer OpenClaw version before the add-on image is updated.

It is especially useful when:

• OpenClaw releases a bug fix.
• A new provider/model configuration requires a newer OpenClaw version.
• Gateway behavior changes in OpenClaw but the add-on image still contains an older version.
• Advanced users want to test a newer OpenClaw version without forking the add-on.

The default behavior would remain unchanged for users who do not set openclaw_version.

Scope

• This is specific to the Home Assistant add-on (not upstream OpenClaw core).
• I can help test this on my setup.