On dependency-guard: inherited from the unmerged Wave 1 base (#101098) — no new dependency. Private-tab visibility is enforced server-side (filterWorkspaceForOperator on every doc-serializing response, fail-closed for unidentified operators — verified a private tab is absent from a non-owner's payload + tab order); presence is id+tab only. Verified by the submitting orchestrator's own gate + security review: extensions/dashboard 92 tests, UI dashboard+plugin 119 tests, ui:build + full type-aware oxlint clean.

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

Dependency graph guard cleared

This PR no longer has blocked dependency graph changes. A future dependency graph change requires a fresh /allow-dependencies-change comment after the guard blocks that new head SHA.

• Current SHA: 73700913b9ffc76ff4e2acdd45fb4e1ce1f0a238

Codex review: needs real behavior proof before merge. Reviewed July 13, 2026, 9:32 AM ET / 13:32 UTC.

Summary
The branch adds gateway-local Teams identities and sessions, exact-resource authorization, delegated plugin tools, domain-partitioned Workspaces sharing, change requests and presence, a restricted member portal, persistent authorization schemas, and public plugin API additions.

Reproducibility: not applicable. as a bug reproduction: this PR introduces a new multi-user capability. The relevant verification is a real two-principal deployment exercising authorization and session lifecycle behavior.

Review metrics: 3 noteworthy metrics.

• Workspace document schema: 1 changed: v1 to v2. Existing Workspaces state gains immutable resource IDs and revisions, so upgrade preservation must be proven before merge.
• Plugin SDK exports: 5 public exports added. The SDK surface budget rises from 10,645 to 10,650, establishing new compatibility-sensitive Teams contracts.
• Gateway protocol identity: 1 optional hello auth field added. Server-issued principals become visible to clients and therefore require protocol and client compatibility review.

Stored data model
Persistent data-model change detected: database schema: extensions/workspaces/src/default-workspace.ts, database schema: extensions/workspaces/src/schema.test.ts, database schema: extensions/workspaces/src/schema.ts, database schema: extensions/workspaces/src/ui-gateway-integration.test.ts, database schema: src/state/openclaw-state-schema.generated.ts, database schema: src/state/openclaw-state-schema.sql, and 12 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #105322
Summary: The canonical Teams issue describes this branch's exact local-account, resource-RBAC, Workspaces, and restricted-portal implementation; the history PR is related by a specific private-tab projection integration hazard.

Members:

• canonical: Teams: local multi-user Workspaces sharing with exact tab RBAC #105322 - It defines the complete Teams v1 architecture and acceptance criteria implemented by this PR.
• partial_overlap: Workspaces: add version history and exact restore #101900 - Its historical snapshot endpoint must apply this PR's exact-tab visibility projection to avoid a compositional privacy leak.
• superseded: Modular Dashboard — Wave 2+ roadmap (tracking) #101136 - The older dashboard roadmap describes the original control-hub direction, while the newer Teams issue now owns the concrete remaining product and security work.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Obtain explicit maintainer approval for the Gateway trust model and public api.teams contract.
• [P1] Add redacted current-head two-principal runtime proof covering grants, denials, session invalidation, and privacy boundaries.
• Resolve the dirty merge state and rerun review against the actual prospective merge result.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR reports 100 focused tests and static checks but no inspectable current-head live run showing bootstrap, invite redemption, all three access modes, exact cross-tab denial, presence, logout, expiry, grant revocation, and history denial across two principals; add a redacted recording, terminal transcript, logs, or linked artifact, then update the PR body to trigger review or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• [P1] Merging would establish a new multi-human Gateway trust model, authentication system, member role, and authorization kernel before maintainers have confirmed that core product and security direction.
• [P1] The public plugin API and gateway-method access contract become compatibility-sensitive once external plugins can depend on api.teams and resource policies.
• [P1] The shared state database receives a large durable authorization model, while the Workspaces document also moves from schema v1 to v2; fresh-install and upgrade behavior need explicit runtime proof.
• [P1] If the open history PR is later merged without applying the exact-tab projection, members could retrieve private tabs from historical snapshots even though live reads are filtered.
• [P1] The dirty merge state means the reviewed head is not the actual prospective merge result and conflict repair could alter security-sensitive paths.
• [P1] Tests and static checks do not demonstrate cookie transport, proxy/TLS handling, two-browser isolation, revocation, expiry, or denial behavior in a real deployment.

Maintainer options:

1. Approve, split, and prove before merge (recommended)
   Confirm the trust model, separate the security-sensitive layers into bounded landing units, repair conflicts, cover the history projection, and attach redacted two-principal runtime evidence.
2. Reject the new core trust boundary
   Close or redesign the branch if core should remain a single-owner Gateway without local member identities or a public Teams authorization API.

Next step before merge

• [P1] A maintainer must decide the core Gateway security model and permanent plugin API direction before conflict repair, upgrade validation, or contributor proof can establish merge readiness.

Maintainer decision needed

• Question: Should OpenClaw core adopt this gateway-local multi-human Teams trust model and expose its host-bound resource authorization primitives as a permanent public plugin API?
• Rationale: The patch changes who may authenticate to the Gateway, how devices are approved, which persistent identities and grants core owns, and what external plugins may rely on; tests cannot decide whether that is the intended long-term security and product boundary.
• Likely owner: 100yenadmin — This person owns the current implementation and the surrounding merged Workspaces history, making them the best available technical owner to prepare the decision packet, though final approval requires repository maintainers.
• Options:
  • Approve and stage the model (recommended): Sponsor the core direction, settle the public API contract, and split landing into bounded authorization, plugin, Workspaces, and portal stages with upgrade and live security proof.
  • Keep the single-owner boundary: Do not add local multi-human authentication to core and redesign sharing behind an external service or a narrower existing-owner-mediated plugin boundary.
  • Pause for a focused RFC: Keep the implementation open but stop merge work until maintainers document identity ownership, threat model, migration policy, and API stability expectations.

Security
Needs attention: The design contains extensive defensive checks, but it intentionally expands the Gateway's authentication and authorization boundary and therefore requires explicit security ownership plus live adversarial proof.

Review findings

• [P1] Keep Teams within an approved Gateway trust model — src/gateway/teams-http.ts:38

Security (cross-PR, surfaced by the downstream Boardstate extraction's audit — SPEC invariant I6): private-tab leak via workspace history, emergent when this PR and #101913 both land.

• This PR (Workspaces: add version history and exact restore #101900) adds dashboard.workspace.history.get, which returns a full historical snapshot of the workspace document, but does not run it through any operator-visibility filter.
• Workspaces: add scoped Teams control hub #101913 (control-hub) introduces private / per-operator tabs and a filterWorkspaceForOperator that respondDoc applies to every live read so a response never leaks another operator's private tab.

Neither branch has the hole in isolation (this one has no private tabs yet; that one has no history endpoint). But once both are on main, history.get returns snapshots unfiltered, so a non-owner can read another operator's private tab out of any older version — bypassing the live-read filter.

Fix at integration: route the history.get snapshot through the same filterWorkspaceForOperator(doc, operatorId) that respondDoc uses for live reads (the version field stays the real/unfiltered value so client change-dedup is unaffected). Reference: the extracted Boardstate applies exactly this in its dashboard.workspace.history.get handler.

Flagging on both PRs so it isn't lost at merge. (The other two audit findings — approval-elevation via workspace.replace, and CSP on widget-route 404s — were single-branch and are fixed directly in #101094 and #101098.)