UI issue after rollback

[bright path]

after rolling back to 2026.4.23 from 2026.5.17, i cant manage skills in the webui

[paper sierra]

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

[wispy cosmos]

I checked the docs/current protocol: 2026.4.23 should still have the Skills UI and the skills.* gateway calls, so this sounds more like rollback/cache/state mismatch than “skills management was removed.”

I’d try this in order:

openclaw --version
openclaw gateway status
openclaw doctor
openclaw gateway restart

Then hard-refresh the Control UI, or open it in a private/incognito window. If that fixes it, the browser had newer 2026.5.17 UI state/assets cached against the older gateway.

Also check whether the skill backend itself is fine:

[wispy cosmos]

openclaw skills list --verbose
openclaw skills check

If CLI skills work but the web UI still can’t manage them, grab the browser console error plus the relevant gateway log lines:

openclaw logs --follow

Useful refs: https://docs.openclaw.ai/help/faq, https://docs.openclaw.ai/install/updating, https://docs.openclaw.ai/tools/skills, https://docs.openclaw.ai/web/control-ui

[bright path]

before clicking on a skill in the webui opened it up and you could set the optins for that skill, now nothing happens. i did a browser cache clear

[wispy cosmos]

Got it. I checked the 2026.4.23 UI source: clicking an installed skill card is supposed to set skillsDetailKey and open the dialog with enable/disable, install action, API key/env bits. So if the click does literally nothing after a cache clear, I’d suspect either a JS exception or mismatched rollback assets/runtime.

Two quick checks:

openclaw --version
openclaw gateway status
openclaw skills list --verbose

Then in the browser: open DevTools → Console, click a skill, and see if an exception appears. That console error is probably the useful clue.

If this rollback was from a source/git install, make sure the UI was rebuilt after checking out 2026.4.23:

pnpm install

[wispy cosmos]

pnpm build
pnpm ui:build
openclaw gateway restart

For npm/global rollback, I’d still restart the gateway and confirm openclaw gateway status points at the expected installed package, because otherwise the browser can be talking to a gateway/UI pair that are not actually from the same build.

[bright path]

i run that in the docker container?

[wispy cosmos]

Yes, if your gateway is running in Docker, run the OpenClaw CLI checks inside the gateway container, or through your compose helper.

Typical compose form:

docker compose exec openclaw-gateway openclaw --version
docker compose exec openclaw-gateway openclaw gateway status
docker compose exec openclaw-gateway openclaw skills list --verbose
docker compose exec openclaw-gateway openclaw skills check
docker compose logs -f openclaw-gateway

If your compose file uses an openclaw-cli service, use:

docker compose run --rm openclaw-cli --version

[wispy cosmos]

docker compose run --rm openclaw-cli skills list --verbose
docker compose run --rm openclaw-cli skills check

For the rebuild bit: run git checkout v2026.4.23 / git pull / docker compose build / docker compose up -d on the Docker host, not manually inside a running container. Runtime container changes are ephemeral.

Docs: https://docs.openclaw.ai/install/docker-vm-runtime

[bright path]

im using the offical docker image, do i still do a git pull?

[wispy cosmos]

No, not for the official image. git pull only applies if you’re building from a local source checkout.

For the official Docker image, change/pin the image tag, pull it, then recreate the container. Something like:

# in the directory with your docker-compose.yml / .env
docker compose pull
docker compose up -d

If you want to stay on 2026.4.23, make sure your compose/.env image is pinned to that tag instead of latest, e.g.:

OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:2026.4.23

Then:

[wispy cosmos]

docker compose pull
docker compose up -d
docker compose exec openclaw-gateway openclaw --version

If your service name differs, replace openclaw-gateway. The important bit is: official image = pull/recreate; source checkout = git pull/build.

[bright path]

OpenClaw 2026.4.23

[wispy cosmos]

Good, that confirms the running CLI is on 2026.4.23.

At this point the next signal is the browser console, because the installed-skill click path in 2026.4.23 is entirely client-side: it should open a dialog without needing another gateway request. If nothing happens, a JS exception is likely stopping the render.

Please check:

1. DevTools → Console
2. Click one installed skill
3. Copy the red error line/stack here

Also try clearing site data, not just cache. In Chrome/Edge: DevTools → Application → Storage → Clear site data, then reload the Control UI and reconnect. Cache clearing can leave local/session storage behind.

One more useful Docker check:

docker compose exec openclaw-gateway openclaw skills list --verbose

[wispy cosmos]

docker compose exec openclaw-gateway openclaw skills check

If those work and the console shows a UI exception, that’s probably a Control UI bug worth filing with the console error at https://github.com/openclaw/openclaw/issues.

[bright path]

Uncaught (in promise) DOMException: HTMLDialogElement.showModal: Dialog element is not connected

[wispy cosmos]

Yep, that error explains it. This is a 2026.4.23 Control UI bug in the skill detail dialog: it calls showModal() before the dialog is connected to the DOM. I checked current source and this has already been patched later with an isConnected/microtask guard.

Practical options:

1. Move to a newer image tag that includes the fix, if you can.
2. If you need to stay on 2026.4.23, manage the skill settings from CLI/config for now.

For enable/disable, use the skill key from:

docker compose exec openclaw-gateway openclaw skills list --verbose

Then set it like:

[wispy cosmos]

docker compose exec openclaw-gateway openclaw config set skills.entries.<skillKey>.enabled false --strict-json
docker compose exec openclaw-gateway openclaw gateway restart

Use true to enable it again. For API keys, the config path is skills.entries.<skillKey>.apiKey, but be careful with secrets; env/SecretRef is better than pasting keys directly.

This is worth filing as a regression with exactly that console error: https://github.com/openclaw/openclaw/issues

[bright path]

i can enable and disable the skills fine, but i can change the settings on them

[wispy cosmos]

Right, that tracks: enable/disable is the inline toggle, but the settings/API-key/install options live in the dialog, and that dialog is what’s broken by the showModal bug.

Workaround is config CLI until you move off 2026.4.23:

# find the exact skillKey
docker compose exec openclaw-gateway openclaw skills list --verbose

Then set per-skill config under skills.entries.<skillKey>:

# preferred for a primary API key: reference an env var instead of storing plaintext
docker compose exec openclaw-gateway openclaw config set skills.entries.<skillKey>.apiKey '{"source":"env","provider":"default","id":"GEMINI_API_KEY"}' --strict-json

# or set arbitrary env vars for that skill