← View index

Browser/X primary-source path — preflight

過去レポートのView/ソース規律バックフィルで生成したView。

Generated: 2026-05-10T14:40:00+09:00

This was a safe read-only preflight. No browser login, config change, Gateway restart, or scope approval was performed.

Result

Browser automation is installed and the openclaw browser CLI exists, but current browser control is blocked by OpenClaw device scope approval.

The blocker is not X/Twitter login yet. The blocker happens earlier: the CLI/device session is asking the Gateway for broader operator scopes than currently approved.

Evidence

Commands checked:

Observed error:

gateway connect failed: GatewayClientRequestError: scope upgrade pending approval
GatewayTransportError: gateway closed (1008): pairing required: device is asking for more scopes than currently approved

Latest pending request observed:

requestId: ed086757-db4a-4670-a8f2-9e89605a5431
status: scope upgrade, repair
requested role: operator
requested scopes: operator.admin, operator.approvals, operator.pairing, operator.read, operator.talk.secrets, operator.write
currently approved scopes: operator.read, operator.write

Interpretation

The browser capability is present in principle, but the current CLI/operator token cannot use the browser path until the pending device scope upgrade is explicitly approved.

This is a security boundary, not a bug to bypass. The requested scopes include broad/admin-ish capabilities, so approval should be intentional.

Next action

If 健人くん wants browser/X primary-source checking enabled, approve the pending device scope upgrade after reviewing the requested scopes.

Likely command, if the same request is still pending:

openclaw devices approve ed086757-db4a-4670-a8f2-9e89605a5431

If the request id changes, run:

openclaw devices list

Then approve the current pending request only if the requested scopes look acceptable.

Operating rule after approval

For future research claims that depend on X/browser-only primary sources:

質問したい箇所を選択
この箇所について質問
✓ 質問を送信しました