Bug type

Regression (worked before, now fails)

Summary

On Windows 10, upgrading to 2026.3.13 causes the local gateway to reissue the operator device token without operator.read, leaving status/probe/health broken even while the gateway service and agent runtime still work.

Steps to reproduce

1. Upgrade a local Windows install to OpenClaw 2026.3.13.
2. Start or restart the local gateway service.
3. Confirm openclaw gateway status reports the service running and RPC probe: ok.
4. Run openclaw status, openclaw gateway probe --json, openclaw gateway health --json, and openclaw gateway call status.
5. Inspect D:\OpenClaw\.openclaw\identity\device-auth.json.
6. Move device-auth.json aside and rerun openclaw gateway call status.
7. Inspect the regenerated device-auth.json.

Expected behavior

The local operator device token should include the read scope needed for normal diagnostics, including operator.read. openclaw status, openclaw gateway probe, and openclaw gateway health should report the gateway as reachable when the service, channels, and agent runtime are healthy. Regenerating device-auth.json should not drop required read scopes.

Actual behavior

At the same time, openclaw gateway status reports the service running with RPC probe: ok, Telegram remains healthy, and an openclaw agent smoke test still returns normal model output. But openclaw status reports unreachable (missing scope: operator.read), openclaw gateway probe --json times out, and openclaw gateway health --json closes with code 1000. If I temporarily move identity/device-auth.json out of the way, openclaw gateway call status immediately works again. After the gateway regenerates device-auth.json, it writes the same incomplete scope set again and the higher-level status/probe/health commands regress again.

OpenClaw version

2026.3.13

Operating system

Windows 10.0.19045 (x64)

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw local CLI -> local gateway ws://127.0.0.1:18789 -> openai-codex/gpt-5.4

Config file / key location

D:\OpenClaw.openclaw\openclaw.json ; D:\OpenClaw.openclaw\identity\device-auth.json ; D:\OpenClaw.openclaw\devices\paired.json

Additional provider/model setup details

Gateway setup is local loopback with token auth (gateway.mode=local, gateway.bind=loopback, gateway.auth.mode=token). Node runtime is 24.7.0. Telegram channel health remains OK and a direct openclaw agent smoke test still succeeds. The key local finding is that the active operator token in identity/device-auth.json is regenerated without operator.read, even though the paired-device store still contains operator.read.

Logs, screenshots, and evidence

openclaw status
Gateway: local | ws://127.0.0.1:18789 (local loopback) | unreachable (missing scope: operator.read)

openclaw gateway health --json
gateway connect failed: Error: gateway closed (1000):
Error: gateway closed (1000 normal closure): no close reason

openclaw gateway probe --json
connect.error = timeout

Gateway log excerpt
handshake timeout conn=... remote=127.0.0.1
res x status ... errorMessage=missing scope: operator.read
res x system-presence ... errorMessage=missing scope: operator.read
res x config.get ... errorMessage=missing scope: operator.read

Regenerated identity/device-auth.json scopes
operator.admin
operator.approvals
operator.pairing

Workaround observation
If `identity/device-auth.json` is moved aside, `openclaw gateway call status` works again until the gateway regenerates a new under-scoped token.

Impact and severity

Affected: Windows local gateway users using token auth and local operator diagnostics.
Severity: High for operations and troubleshooting because core runtime may still work while health/probe/status give false negatives.
Frequency: 100 percent repro on this machine.
Consequence: Local read diagnostics become unreliable, some local operator RPC paths fail, and it is hard to tell whether the gateway is actually down or just under-scoped.

Additional information

Last known good on this machine: 2026.3.11. First known bad for the missing-scope symptom: 2026.3.13. Version 2026.3.12 had related handshake regressions, but this report adds a stronger Windows-specific repro showing the gateway reissues the local operator device token without operator.read. Likely overlaps with #45560, #45835, #44714, and probe-semantics PR #45622.