#21651: fix(gateway): token fallback + operator.admin scope superset in pairing check

## Summary Two related fixes for the `gateway closed (1008): pairing required` error when agent tools call the gateway from the sandbox. ### 1. Token fallback in `resolveGatewayOptions()` (`src/agents/tools/gateway.ts`) - **Problem:** `resolveGatewayOptions()` only read the explicit `gatewayToken` tool parameter, never falling back to env vars or config. - **Fix:** Now mirrors the fallback chain from `callGateway()`: explicit param → `OPENCLAW_GATEWAY_TOKEN` env → `CLAWDBOT_GATEWAY_TOKEN` env → `gateway.auth.token` config. ### 2. `operator.admin` scope superset in pairing check (`src/shared/operator-scope-compat.ts`) - **Problem:** `operatorScopeSatisfied()` only treated `operator.admin` as a superset of `operator.read`, but not `operator.write`, `operator.approvals`, or `operator.pairing`. When a tool connected requesting `operator.write`, a device paired with `operator.admin` would fail the scope check and trigger a non-silent scope-upgrade pairing request. - **Inconsistency:** `authorizeOperatorScopesForMethod()` in `method-scopes.ts` correctly treats `operator.admin` as god-mode, but the pairing gate in `roleScopesAllow()` did not. - **Fix:** `operator.admin` now satisfies all operator scopes in the pairing check, consistent with method authorization. ## Change Type - [x] Bug fix ## Scope - [x] Gateway / orchestration - [x] Skills / tool execution ## Linked Issue/PR - Fixes #21478 ## User-visible / Behavior Changes - `message`, `sessions_list`, and other gateway-dependent tools now work from the sandbox without requiring explicit `gatewayToken` param. - Devices paired with `operator.admin` no longer get spurious "pairing required" errors when tools request `operator.write` or other sub-scopes. ## Security Impact - New permissions/capabilities? No. `operator.admin` was already treated as god-mode in method authorization. This makes the pairing gate consistent. - Secrets/tokens handling changed? No new tokens. Existing token resolution extended to cover a missing code path. - New/changed network calls? No - Command/tool execution surface changed? No - Data access scope changed? No ## Repro + Verification 1. Configure `gateway.auth.token` in `openclaw.json` 2. Start gateway, confirm WhatsApp connected 3. Have agent call `message(action=send, target="+1...", message="test")` 4. Before fix: `pairing required`. After fix: message sends. ## Compatibility / Migration - Backward compatible: Yes - Config/env changes: No - Migration needed: No <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes two related issues preventing gateway-dependent tools from working in the sandbox. The main fix adds a token fallback chain to `resolveGatewayOptions()` that mirrors the existing behavior in `callGateway()`, allowing tools like `message` and `sessions_list` to authenticate using env vars or config when no explicit token is provided. A companion fix ensures `operator.admin` scope is treated as a superset of all operator scopes (not just `operator.read`), preventing "pairing required" errors for already-authenticated admin users. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - Both changes are defensive bug fixes with clear test coverage. The token fallback logic correctly mirrors the existing `callGateway` implementation, and the scope compatibility fix resolves a logical inconsistency. No new security risks introduced, and all changes are backward-compatible. - No files require special attention _{Last reviewed commit: 69af209} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->