#2026.2.19-2

1 messages · Page 1 of 1 (latest)

grim birch
#

Thanks for documenting this, saved me a ton of time! Ran into the exact same issue on Ubuntu after 2026.2.19-2.

Followed your steps and they got me most of the way there, but I had one extra step needed. After the gateway reinstall + restart, I still had a pending scope repair request that needed a second approval. Here's what fully worked for me:

sudo rm -rf /tmp/jiti
sudo chown -R $USER:$USER ~/.openclaw
systemctl --user stop openclaw-gateway.service
rm -rf ~/.openclaw/devices/
rm -rf ~/.openclaw/identity/
openclaw gateway install --force
systemctl --user daemon-reload
systemctl --user start openclaw-gateway.service
openclaw gateway restart
openclaw devices approve # pairs the device
openclaw devices approve # approves the operator.write scope repair

The key thing I was missing: the device kept generating a new pending repair request even after the initial pair was approved. You can confirm it's fully resolved with openclaw devices list; no pending entries, and the paired device should show scopes including operator.write and operator.read alongside operator.admin.

Had my AI assistant (running inside OpenClaw) spawn 3 simultaneous subagents as a live test, all came back clean after the second approve.

For what it's worth, this scope regression is documented in the ~/.npm-global/lib/node_modules/openclaw/CHANGELOG.md the relevant lines were under ## 2026.2.19 (Unreleased) in the Fixes section:

Security/Gateway/Agents: remove implicit admin scopes from agent tool gateway calls... Ships in the next npm release.

Security/Gateway: centralize gateway method-scope authorization and default non-CLI gateway callers to least-privilege method scopes...

So 2026.2.20 should resolve this properly. Until then, the double-approve workaround does the job.

Agree on your protip openclaw gateway install --force after every update should probably just be the standard procedure.

sturdy loom
#

what an obscure bug. should be documented on their docs for future users

grim birch
#

lol but real. Maybe I’ll do a bug report but the number of issues and pr’s are still insane.

For devs reading this: the root issue is that on upgrade, existing paired devices automatically generate a repair request to add operator.write under the new scope model, but the gateway rejects the scope upgrade with "pairing required" instead of auto-granting it. The device ends up stuck, it has operator.admin but can't get operator.write without manual intervention. The logs show: scopesFrom=operator.admin,operator.approvals,operator.pairing

scopesTo=operator.write cause=pairing-required

Scope migration for existing paired devices on upgrade seems to be the gap openclaw gateway install --force doesn't cover it.

vague panther
grim birch