OpenClaw Main Aligns Control UI Session Actions With Operator Scopes
A merged authorization-boundary change makes Control UI session controls consult Gateway methods, request parameters and operator scopes before final mutation.
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.
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:
| Identity | Test | Expected result |
|---|---|---|
| Read-only | Navigate and inspect sessions | Read surfaces remain usable; mutation controls are unavailable |
| Write-scoped | Apply an allowed organizational change | Control is available and request succeeds |
| Write-scoped | Delete an already archived session where supported | Allowed consistently in UI and Gateway |
| Write-scoped | Request an admin-sensitive runtime parameter | Blocked before mutation and rejected server-side if called directly |
| Admin-scoped | Perform the same authorized runtime action | Available and accepted |
| Any scope after reconnect | Repeat the decision against newly advertised methods | No stale control survives the connection replacement |
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 PR establishes the UI/Gateway policy mismatch, shared access decision and parameter-aware scope examples. OpenClaw Academy did not run the browser harness or audit the final 85-file patch. Upstream review called for exact-head authorization and legacy-compatibility checks before merge; operators should preserve that 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. Stage a containing build with read, write and admin identities, test parameter-sensitive actions and prove the same decision survives reconnect and mixed-version use.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF