Team Setup: OpenClaw Gateway

This guide configures a single OpenClaw gateway for an entire team: a bot inside your existing workspace chat, shared sessions that anyone can open and drive from the Control UI, and roles that limit what each member is permitted to do. It is the same product as the personal assistant setup; running it for a team is a matter of configuration, not a different product edition.

Before you begin

A host for the Gateway that remains online: a small VPS, an office Mac, or any supported install target.
OpenClaw installed and onboarded on that host, as described in Getting started.
A chat workspace the team already uses (Discord, Google Chat, Mattermost, Microsoft Teams, Slack, Telegram, and others), per Channels.
A capable, recent model. A shared gateway handles more varied input than a solo deployment, and current models are considerably more resilient to prompt injection, as covered in Security.
Optionally, GitHub accounts for teammates, if you want verified identities and commit attribution.

One trust boundary

A gateway forms a single trust boundary. Anyone who can message an agent with tools enabled inherits that agent's delegated tool permissions, and anyone with operator access shares one control plane. That fits a team whose members already trust one another: session ownership, presence, and roles act as collaboration guardrails inside the boundary, not as isolation between adversaries.

To serve people or organizations that do not trust each other, run a separate gateway per tenant instead, as explained in Multi-tenant hosting.

Step 1: Give the team access to the Gateway

By default, the Gateway binds to loopback. Expose it to teammates through authenticated ingress rather than a public bind:

Tailnet (recommended): place the host on your tailnet and turn on Tailscale Serve. With gateway.auth.allowTailscale, Control UI sign-in can rely on each person's Tailscale identity, so there is no shared secret to hand out.
Trusted proxy: put an identity-aware proxy such as Cloudflare Access in front of the Gateway, per Trusted proxy auth.
Shared secret: token or password authentication works for small teams but omits per-person identity, as noted in Authentication.

The identity-backed options are worth the extra effort: they are what changes "someone did something" into "who did what" in the session UI and in the commit credit described below.

Step 2: Connect the team chat

Connect the channel your team actually uses. For instance, a Slack bot restricted to one team channel that responds when mentioned:

{
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: { source: "env", provider: "default", id: "SLACK_APP_TOKEN" },
      botToken: { source: "env", provider: "default", id: "SLACK_BOT_TOKEN" },
      groupPolicy: "allowlist",
      channels: {
        C0123456789: { requireMention: true },
      },
    },
  },
}

Group chats are a fully supported deployment mode. The defaults already suit a team: group access is allowlisted per room, replies require a mention, and DMs stay on the pairing default, meaning the first time a teammate DMs the bot they receive a pairing code that you approve with openclaw pairing approve slack <code>. The bot therefore speaks when addressed and stays silent otherwise. In a private room whose members you trust, that is all the gating you need; for broad or public rooms, add sender allowlists and contextVisibility, as described in Groups.

When the same set of people should be allowed in multiple channels, define that list once as an access group and point each channel's allowlist at it.

Step 3: Sign the team in to the Control UI

Each teammate opens the Control UI through the ingress from step 1 and receives a persistent Gateway profile: display name, avatar, and personal appearance preferences. With Cloudflare Access or Tailscale Serve, GitHub-backed sign-in verifies the account behind the profile, per User model.

Step 4: Work in shared sessions

A conversation that begins in the team channel can carry on as a session that the whole team can open, steer, and take over. Multi-user mode gives every session three layers of attribution: an immutable creator, an assignable owner (assign sessions like GitHub issues from the session context menu), and the record of who actually sent prompts, plus live presence showing who is viewing and who is typing, with drafts that never reach the model or the transcript.

For coding work, verified GitHub identity pays off at commit time. With Git co-author credit enabled, commits from a shared session include Co-authored-by trailers for the people who steered it, and generated pull requests link back to the session so reviewers can read the conversation that produced the diff.

Step 5: Bound what each person can do

Named operator roles bind authenticated profiles to a policy: which sessions they may touch, which agents they may use, a maximum set of operator scopes, and whether their new sessions must be sandboxed:

{
  gateway: {
    roles: {
      default: "guest",
      definitions: {
        maintainer: {
          sessions: { others: "write" },
          agents: ["roboclaw"],
          scopes: ["operator.read", "operator.write", "operator.approvals"],
        },
        guest: {
          sessions: { others: "view" },
          agents: ["roboclaw"],
          scopes: ["operator.read", "operator.write"],
          sandbox: "required",
        },
      },
    },
  },
}

Assign roles with the users.setRole Gateway method; see Named operator roles for the full policy surface and Permission modes for per-session tool posture.

Verify

Mention the bot in the allowed team channel and confirm it replies there.
Open the Control UI as two different people: both should see the session, its owner avatar, and each other's presence.
Run openclaw security audit on the host and resolve anything it flags about inbound access or exposure.

When to split things up

Separate workspaces or personas (projects that must not share memory or files): use multiple agents on one gateway, as covered in Multi-agent routing.
Mutually untrusted users, customers, or organizations: separate gateways, ideally separate OS users or hosts, per Multi-tenant hosting and Security.

Why OpenClaw: working together - the team collaboration surfaces in one place
Multi-user mode - ownership, participants, and owner filtering in depth
Operator scopes - connection roles, scopes, and role assignment
Groups - group behavior, mention gating, and context visibility
Security - the trust model behind the one-boundary rule