Skip to content

openclaw status reports missing operator.read while gateway is healthy; gateway probe times out on same loopback endpoint #50691

@StarShipSoundStudios

Description

@StarShipSoundStudios

Environment

  • OpenClaw: 2026.3.13 (61d171a)
  • OS: Windows 10 (x64), Node 24.13.1
  • Gateway mode: local
  • Bind: loopback
  • Auth mode: token
  • Gateway URL: ws://127.0.0.1:18789

Summary

I’m seeing contradictory gateway/auth behavior on the same machine/session:

  • openclaw gateway status reports service running, listener active, and RPC probe: ok.
  • openclaw status reports:
    • Gateway ... unreachable (missing scope: operator.read)
  • openclaw gateway probe fails to connect to the same loopback target (timeout).

This persists across restarts and token/device cleanup.

Repro

  1. Start gateway:
    openclaw gateway start
  2. Run:
    openclaw gateway status
    openclaw status
    openclaw gateway probe

Observed

  • gateway status:
    • listener active on 127.0.0.1:18789
    • RPC probe: ok
  • status:
    • missing scope: operator.read
  • gateway probe:
    • Reachable: no, connect timeout on ws://127.0.0.1:18789

Log evidence

From %LOCALAPPDATA%\Temp\openclaw\openclaw-2026-03-19.log:

  • Repeated status-path denials:
    • errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
    • methods: status, system-presence, config.get
  • Intermittent handshake failures:
    • cause=handshake-timeout
    • closed before connect with code 1000 or 1006

What I already tried

  • Rotated operator token explicitly including operator.read
  • Normalized local auth state files:
    • ~/.openclaw/identity/device-auth.json
    • ~/.openclaw/devices/paired.json
  • Reduced paired devices to only one CLI device with full operator scopes
  • Cleared browser site data (to remove stale control-ui token mismatch)
  • Repeated gateway stop/start/restart
  • Hard-killed gateway process and restarted

Issue persists.

Why this looks like a bug

There appears to be auth/session-path divergence:

  • Same runtime says RPC probe: ok
  • while probe/status paths fail with scope timeout/denial on same endpoint and same token config.

Could be stale claim resolution or split auth handling between CLI command paths.

Request

Please advise:

  1. Why status/system-presence/config.get are evaluated without operator.read despite local paired/token state including it.
  2. Why gateway probe can timeout while gateway status reports RPC probe OK on same loopback endpoint.
  3. Whether there is a hidden auth/session cache reset command beyond device token rotate + service restart.

Metadata

Metadata

Assignees

No one assigned

    Labels

    clawsweeperTracked by ClawSweeper automation

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions