openclaw - ✅(Solved) Fix [Bug]: clearUnboundScopes strips operator scopes unconditionally for non-local token-auth clients [1 pull requests, 6 comments, 5 participants]

marccampbell · 2026-03-21T03:04:54Z

[openclaw] In 2026.3.13, clearUnboundScopes unconditionally strips all operator scopes for non-local clients without device identity, even when token auth succ… In 2026.3.13, clearUnboundScopes() unconditionally strips all operator scopes for non-local clients without device identity, even when token auth succeeds. This breaks chat.send (and any operator.write-scoped method) for backend clients connecting over a network with valid --token auth. # PR #51413: fix(gateway): retain operator scopes for non-local token-auth clients - Repository: openclaw/openclaw - Author: xydt-610 - State: open | merged: False - Link: https://github.com/openclaw/openclaw/pull/51413 ## Description (problem / solution / changelog) ## Summary Describe the problem and fix in 2-5 bullets: - Problem: `clearUnboundScopes()` unconditionally strips operator scopes for non-local clients without device identity, even when token auth succeeds. This breaks `chat.send` and other operator.write-scoped methods for backend clients connecting over network with valid `--token` auth. - Why it matters: Backend clients authenticating with a valid token over a remote connection get their requested scopes stripped, while localhost works fine. This prevents valid token-authenticated operators from using write methods. - What changed: In `evaluateMissingDeviceIdentity`, treat `authOk` + `authMethod` token/password as sufficient for operator device-skip (alongside `sharedAuthOk`), so non-local token-auth clients retain their self-declared scopes. - What did NOT change (scope boundary): No change to Control UI, device pairing, or trusted-proxy auth. Only fixes the operator + token/password path when `sharedAuthOk` might disagree with primary auth. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #51396 - Related # ## User-visible / Behavior Changes Non-local backend clients connecting with valid token auth now retain their requested scopes (e.g. `operator.admin`), so `chat.send` and other operator.write methods work as they do for localhost. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: N/A ## Repro + Verification ### Environment - OS: Debian 12 (per issue); Windows 10 (local verification) - Runtime/container: Node / npm global - Model/provider: anthropic/opus-4.6 - Integration/channel (if any): openclaw gateway with `--bind tailnet --token` - Relevant config (redacted): Gateway token auth ### Steps 1. Start gateway with `openclaw gateway --bind tailnet --token ` 2. Connect from a remote host (non-loopback) via WebSocket with valid token in `auth.token` and `scopes: ["operator.admin"]` 3. Call `chat.send` ### Expected - Connection succeeds; `chat.send` succeeds (operator.admin implies operator.write). ### Actual - Before fix: `missing scope "operator.write"`. After fix: scopes retained, `chat.send` works. ## Evidence Attach at least one: - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) `connect-policy.test.ts` includes a regression test: operator + sharedAuthOk=false but authOk=true + authMethod=token + isLocalClient=false now returns `allow`. All tests pass. ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: Ran `pnpm exec vitest run src/gateway/server/ws-connection/connect-policy.test.ts` 鈥?all tests pass. - Edge cases checked: Existing tests for operator+sharedAuthOk, Control UI, trusted-proxy, node role remain correct. - What you did **not** verify: End-to-end remote WebSocket connect with real gateway (no local repro of exact issue setup). ## Review Conversations - [ ] I replied to or resolved every bot review conversation I addressed in this PR. - [ ] I left unresolved only the conversations that still need reviewer or maintainer judgment. If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the commit; no feature flags. - Files/config to restore: `src/gateway/server/ws-connection/connect-policy.ts`, `connect-policy.test.ts`, `message-handler.ts` - Known bad symptoms reviewers should watch for: None anticipated. ## Ri

openclaw2026-03-21 03:04:54

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#51396•Fetched 2026-04-08 01:11:43

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×6cross-referenced ×3labeled ×2referenced ×1

In 2026.3.13, clearUnboundScopes() unconditionally strips all operator scopes for non-local clients without device identity, even when token auth succeeds. This breaks chat.send (and any operator.write-scoped method) for backend clients connecting over a network with valid --token auth.

Root Cause

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Steps to reproduce

Start gateway with openclaw gateway --bind tailnet --token <secret>
Connect from a remote host (non-loopback) via WebSocket with valid token in auth.token and scopes: ["operator.admin"]
Connection succeeds (hello-ok)
Call chat.send → rejected with missing scope: operator.write

Connecting from localhost with the same token works fine.

Expected behavior

Non-local clients authenticating with a valid token should retain their requested scopes (same as localhost behavior).

Actual behavior

missing scope "operator.write" message received

OpenClaw version

2026.3.13

Operating system

Debian 12

Install method

npm global

Model

anthropic/opus-4.6

Provider / routing chain

openclaw -> anthropic

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To resolve the issue, we need to modify the clearUnboundScopes function to conditionally strip operator scopes based on the client's authentication status and device identity.

Step-by-Step Solution

Identify the clearUnboundScopes function: Locate the clearUnboundScopes function in the OpenClaw gateway codebase.
Modify the function: Update the function to check if the client has a valid token authentication before stripping operator scopes.

function clearUnboundScopes(scopes, client) {
  if (client.tokenAuth && client.tokenAuth.success) {
    // Do not strip operator scopes for clients with valid token auth
    return scopes;
  } else {
    // Strip operator scopes for non-local clients without device identity
    return scopes.filter(scope => !scope.startsWith('operator.'));
  }
}

Update the gateway configuration: Ensure that the gateway is configured to use the updated clearUnboundScopes function.

Verification

To verify the fix, repeat the steps to reproduce the issue:

Start the gateway with the updated configuration.
Connect from a remote host via WebSocket with a valid token in auth.token and scopes: ["operator.admin"].
Call chat.send and verify that the operation succeeds without a "missing scope" error.

Extra Tips

Ensure that the tokenAuth property is properly set and updated for clients with valid token authentication.
Review the gateway's authentication and authorization logic to prevent similar issues in the future.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

Non-local clients authenticating with a valid token should retain their requested scopes (same as localhost behavior).

#api #ssr #installation #tensor shape #autograd error #model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: clearUnboundScopes strips operator scopes unconditionally for non-local token-auth clients [1 pull requests, 6 comments, 5 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fixed

PR fix notes

PR #51413: fix(gateway): retain operator scopes for non-local token-auth clients

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

Step-by-Step Solution

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING