Skip to content

Teams: local multi-user Workspaces sharing with exact tab RBAC #105322

Description

@100yenadmin

Goal

Add an opt-in, gateway-local OpenClaw for Teams v1 so an owner can invite local human accounts to exact Workspaces tabs with one of three closed access presets:

  • Read
  • Read + Request Changes
  • Read + Write

The owner remains the canonical approver for requested changes. Agents operate through server-attested delegations and never receive workspace-admin or sharing-admin authority in v1.

This builds on the stable Workspaces foundation merged in #104139.

Why

Today the Control UI is operator-oriented and typically exposed through a proxy as one trusted dashboard. Teams need a smaller surface that can be shared without granting global gateway access, session access, channel credentials, or broad operator scopes.

Non-goals for v1

  • SaaS identity, email delivery, SSO, SCIM, or billing
  • Cross-gateway federation
  • Member access to the normal Control UI, settings, channels, terminals, or global gateway events
  • Workspace-admin or sharing-admin authority for invited users or delegated agents
  • Replacing existing operator authentication

Architecture and ordered work

  1. Core identity and isolation
    • Local human accounts with scrypt password verifiers
    • Opaque, revocable, expiring HttpOnly sessions
    • First-owner bootstrap CLI using password stdin
    • Private server-owned client domain/session bindings
  2. Core authorization
    • member gateway role with no operator scopes
    • Exact resource policies and grants
    • Host-bound plugin Teams primitives for registration, retirement, ownership, child listing, and current authorization decisions
    • Server-attested agent delegation and agent-session bindings
  3. Workspaces integration
    • Stable workspace/tab resource IDs partitioned by isolation domain
    • Exact tab read/write tools and gateway methods
    • Append-only change requests with requester/delegation provenance, idempotency, and optimistic revision approval
    • Safe shared projection for widgets and change-request responses
    • Resource retirement and tab-ID tombstones for deleted/undone tabs
  4. Owner sharing
    • One-time invite links with closed read/request/write presets
    • Invite list/revoke and exact tab parent validation
    • Owner-only sharing sync and change-request review
  5. Restricted portal
    • Public /teams and /teams/invite shell
    • Exact-tab-only RPC surface
    • Fragment-only invite code handling
    • No normal dashboard navigation, settings, global snapshots, or broadcasts

Acceptance criteria

  • A bootstrapped owner can create a one-time invite for one exact tab.
  • Redeeming the invite creates a local human account, domain membership, exact grants, and an expiring session atomically.
  • A member can access only explicitly member-enabled plugin methods and the exact granted tab.
  • Read users cannot mutate; request users create an owner-reviewed request; write users use optimistic revision checks.
  • The canonical owner can inspect the exact raw proposal before approval; requester/member responses remain safely projected.
  • Logout, revocation, expiry, membership removal, and grant removal invalidate existing member access.
  • Member sockets receive no gateway-global presence, health, defaults, or broadcasts.
  • Remote plaintext Teams authentication is rejected; only TLS, trusted-proxy HTTPS, or explicit loopback HTTP development is accepted.
  • Invite codes and session tokens are never returned in ordinary JSON/list responses or stored in browser persistence.
  • Deleted tab resources are retired; undo restores content under a fresh resource ID.
  • Existing operator and local-agent Workspaces flows remain compatible.

Validation gates

  • Focused Vitest coverage across gateway, CLI, plugin API, Workspaces, and UI
  • Production and test TypeScript project checks
  • Scoped formatter/linter checks
  • End-to-end bootstrap -> invite -> exact member read -> cross-tab denial -> session revocation test
  • Current-head security, Workspaces semantics, and portal privacy reviews before readiness

Related work

Current status

Implementation is complete on a clean feature branch with focused tests, type checks, formatter/linter checks, and three independent adversarial reviews passing. Next action: publish the draft PR linked to this issue and let upstream CI/review run on the exact head.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low-priority cleanup, docs, polish, ergonomics, or speculative work.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.issue-rating: 🌊 off-meta tidepoolIssue quality rating does not apply to this item.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions