OpenClaw Main Aligns Control UI Session Actions With Operator Scopes

OpenClaw has merged a broad Control UI correction for session creation, organization, sharing, deletion and chat actions. The UI now consults the connected Gateway’s advertised methods, operator scopes, request parameters and connection identity through a shared access decision, then rechecks that decision at the final mutation boundary.

This is on main and merged after 2026.7.2-beta.7.

A newer follow-up, PR #119785, clarifies the privileged bootstrap path: a Control UI link explicitly issued by the host through openclaw dashboard or graphical onboarding now creates a durable owner credential with administrator and approval scopes. Ordinary browser pairing remains on the narrower profile.

Host-issued links are an owner handoff

Before #119785, host-issued dashboard and onboarding links reused the limited control-ui bootstrap profile. Operators reached the UI but could not use administrator-only settings or RPCs, and opening a fresh host-authorized link could not recover from an existing limited browser credential.

The landed change introduces a dedicated owner bootstrap selected by the host-issued URL-fragment hint. The handoff grants the full owner scope set, including operator.admin and approvals, and replaces a limited browser credential when the host has explicitly authorized that transition.

This is a deliberate privilege boundary, not a general relaxation:

• possession of an ordinary paired browser session does not make it owner;
• the host-issued fragment carries bootstrap authority and should be handled as a secret;
• URL fragments are not sent as HTTP request paths, but they can still leak through screenshots, clipboard history, browser extensions or human forwarding; and
• a shared workstation receiving the handoff gains durable administrative capability in that browser profile.

Operator action: generate owner links only on the trusted Gateway host, open them in the intended browser profile, confirm the resulting scope set, then remove the fragment from notes or support artifacts. Do not paste the link into chat or ticket systems.

What the mismatch did

The Gateway already had parameter-aware rules. Some session changes require ordinary write scope, while runtime-sensitive parameters can elevate the requirement. The Control UI still used broader predicates in affected paths.

That mismatch created two classes of bad behavior:

• controls could appear available even though the eventual Gateway request could not succeed; and
• valid lower-scope operations could be hidden, including the upstream example of deleting already archived sessions with write scope.

The merged change gives the visible control and the final request one policy owner.

What this does not establish

The primary source describes an authorization-consistency gap between the UI and Gateway. It does not establish that a reduced-scope operator could bypass the Gateway’s server-side authorization merely because a button was visible.

That distinction matters. A misleading control is still an operational and security-boundary defect, but it is not evidence of unauthorized mutation unless server enforcement also failed.

Interpretation: client-side gating is defense, guidance and error prevention; the Gateway remains the authoritative enforcement point.

Why request parameters matter

A method name alone is often too coarse. “Create session” can represent a normal session or a runtime-sensitive request with explicit working directory, execution node or incognito behavior. “Delete session” can differ depending on whether the target is already archived.

The UI therefore needs the same method-plus-parameters decision as the Gateway. Replacing that with one global canWrite or isAdmin flag either grants too much visual authority or blocks legitimate work.

Operator action

Prioritize a containing build if you use delegated operator roles or expose the Control UI to accounts with different scope sets.

Then test an authorization matrix in staging:

Use synthetic sessions without sensitive transcripts. Do not weaken a production role simply to make the UI match expectations.

Compatibility risk

The upstream review flags this as a broad security-boundary and compatibility change. It touches many Control UI paths and must remain compatible with what the connected Gateway advertises, including older Gateways with a different method surface.

Acceptance should therefore include mixed-version behavior:

• current UI against the intended Gateway revision;
• the supported older Gateway baseline, if your rollout can produce that pairing; and
• reconnect while an access-dependent page is open.

A stale UI decision must not survive a replacement connection with different scopes or methods.

Monitoring and incident review

Retain the operator identity, advertised scope set, method, security-relevant parameters and authoritative Gateway response for rejected mutations. Avoid logging transcript content or credentials.

If an older UI exposed a control that failed, treat the Gateway rejection as the authoritative outcome. Investigate any claimed successful mutation separately; button visibility alone proves neither execution nor bypass.

Evidence and limits

The official merged PRs and owner-handoff documentation establish the UI/Gateway policy mismatch, parameter-aware scope examples and privileged host-issued bootstrap. OpenClaw Academy did not run the browser harness, inspect a real credential store or audit the full authorization patch set. Operators should preserve exact-head and mixed-version caution in rollout.

Bottom line

The Control UI should show only actions the connected operator may perform, but the Gateway must still enforce every mutation. Treat a host-issued dashboard link as an owner credential handoff, then stage a containing build with read, write and admin identities and prove ordinary pairing never inherits that privilege.