openclaw - ✅(Solved) Fix [Bug]: scope upgrade pending approval blocks all browser CLI commands [1 pull requests, 3 comments, 3 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#81555Fetched 2026-05-14 03:30:54
View on GitHub
Comments
3
Participants
3
Timeline
10
Reactions
2
Timeline (top)
commented ×3labeled ×2mentioned ×2subscribed ×2

All browser CLI commands (browser start, browser status, browser doctor --deep) fail with "scope upgrade pending approval" error. Gateway and Telegram channels work fine. No approval UI visible on Hostinger-hosted instance.

Error Message

All browser CLI commands (browser start, browser status, browser doctor --deep) fail with "scope upgrade pending approval" error. Gateway and Telegram channels work fine. No approval UI visible on Hostinger-hosted instance.

Root Cause

All browser CLI commands (browser start, browser status, browser doctor --deep) fail with "scope upgrade pending approval" error. Gateway and Telegram channels work fine. No approval UI visible on Hostinger-hosted instance.

Fix Action

Fixed

PR fix notes

PR #81563: [codex] fix browser CLI admin scope

Description (problem / solution / changelog)

Summary

Fixes #81555.

Browser CLI commands call the gateway browser.request method, which the browser plugin registers with operator.admin. The shared browser CLI wrapper was not passing explicit gateway scopes, so standalone CLI calls could rely on local method-scope inference that is unavailable when plugin registry activation is non-active. That can trigger a scope-upgrade approval loop for paired CLI devices.

This change makes callBrowserRequest() request operator.admin explicitly for every browser CLI RPC while preserving the existing progress and timeout behavior.

Real behavior proof

  • Behavior or issue addressed: Browser CLI RPCs must request gateway scope operator.admin for browser.request, so paired CLI devices do not get stuck in a scope-upgrade approval loop.
  • Real environment tested: Local OpenClaw source checkout on Windows 11/PowerShell, branch fix/browser-cli-admin-scope-81555, commit 93ce05c101, Node v24.14.0, pnpm 11.1.0. A loopback OpenClaw gateway-protocol endpoint captured the actual gateway frames emitted by extensions/browser/src/cli/browser-cli-shared.ts.
  • Exact steps or command run after this patch: Ran node --import tsx --input-type=module with a local WebSocket gateway listener, then invoked callBrowserRequest(...) from the browser CLI wrapper against ws://127.0.0.1:<local-port>.
  • Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Copied terminal output from the local proof command:
{
  "proof": "browser CLI wrapper live gateway handshake",
  "gatewayUrl": "ws://127.0.0.1:<local-port>",
  "connectMethod": "connect",
  "connectRole": "operator",
  "connectScopes": [
    "operator.admin"
  ],
  "client": {
    "id": "cli",
    "mode": "cli"
  },
  "rpcMethod": "browser.request",
  "requestPath": "/",
  "requestQuery": {
    "profile": "openclaw"
  },
  "observedStatus": {
    "enabled": true,
    "running": false,
    "profile": "openclaw",
    "transport": "local"
  }
}
  • Observed result after fix: The CLI client connected with connectScopes: ["operator.admin"], identified as { "id": "cli", "mode": "cli" }, then sent the browser.request RPC for / with profile=openclaw and received the status payload.
  • What was not tested: A remote hosted browser gateway with the original paired device was unavailable in this local checkout. This proof covers the actual local gateway-protocol request emitted by the browser CLI wrapper.

Tests

  • pnpm test extensions/browser/src/cli/browser-cli-shared.test.ts extensions/browser/src/cli/browser-cli.test.ts extensions/browser/src/cli/browser-cli-manage.test.ts extensions/browser/src/cli/browser-cli-inspect.test.ts extensions/browser/index.test.ts src/gateway/method-scopes.test.ts
  • pnpm check:changed
  • git diff --check

Changed files

  • extensions/browser/src/cli/browser-cli-shared.test.ts (added, +34/-0)
  • extensions/browser/src/cli/browser-cli-shared.ts (modified, +3/-1)

Code Example

Hostinger support confirmed this is not a VPS/Docker/Traefik issue. No local bypass available. Gateway and Telegram work fine. Chromium installed and works manually (chromium-browser --headless --dump-dom succeeds).
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

All browser CLI commands (browser start, browser status, browser doctor --deep) fail with "scope upgrade pending approval" error. Gateway and Telegram channels work fine. No approval UI visible on Hostinger-hosted instance.

Steps to reproduce

  1. Install OpenClaw v2026.5.3-1 on Hostinger VPS (Ubuntu, Node v22.22.2)
  2. Configure browser: headless:true, noSandbox:true, executablePath:/usr/bin/chromium-browser
  3. Run: openclaw browser --browser-profile openclaw doctor --deep
  4. Observe: "scope upgrade pending approval (requestId: d0ec96f4-7beb-45a6-825d-10ca6c1edbcb)"

Expected behavior

Browser doctor should run and report browser status. Browser tool should be usable by agents.

Actual behavior

GatewayClientRequestError: scope upgrade pending approval (requestId: d0ec96f4-7beb-45a6-825d-10ca6c1edbcb). GatewayTransportError: gateway closed (1008): pairing required: device is asking for more scopes than currently approved.

OpenClaw version

2026.5.3-1

Operating system

Ubuntu 24.04 (Hostinger VPS)

Install method

Hostinger 1-click OpenClaw

Model

openrouter/google/gemini-2.5-flash

Provider / routing chain

openclaw -> openrouter -> google/gemini-2.5-flash

Additional provider/model setup details

Affected: All browser CLI commands and agent browser tool usage Severity: High (blocks entire browser automation workflow) Frequency: 100% - every browser command fails Consequence: Cannot use browser tool for any web automation tasks

Logs, screenshots, and evidence

Hostinger support confirmed this is not a VPS/Docker/Traefik issue. No local bypass available. Gateway and Telegram work fine. Chromium installed and works manually (chromium-browser --headless --dump-dom succeeds).

Impact and severity

No response

Additional information

No response

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?
Loading…

FAQ

Expected behavior

Browser doctor should run and report browser status. Browser tool should be usable by agents.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: scope upgrade pending approval blocks all browser CLI commands [1 pull requests, 3 comments, 3 participants]