How to run one OpenClaw gateway for a whole team

Copy a personal OpenClaw install onto Slack or Discord and you have not built a team setup. You have given every teammate the same agent’s tool authority, with no real attribution. OpenClaw’s team guide is the fix: one gateway the whole group uses, with authenticated ingress, a mention-gated workspace bot, Control UI identities, shared sessions, and named operator roles.

It is the same product as the personal assistant. Team operation is configuration, not a separate edition. You get a bot in the chat workspace you already have, sessions everyone can open and steer in the Control UI, and roles that bound what each person can do.

One trust boundary, not a tenancy wall

Read this before you bind anything. A gateway is one trust domain. Everyone who can message a tool-enabled agent shares that agent’s delegated tool authority. Everyone with operator access shares one control plane.

That is the right model for people who already trust each other. Session ownership, presence, and roles are collaboration guardrails inside the boundary. They are not isolation between adversaries.

If you need to serve mutually untrusted people or organizations, do not stretch this design. Run one gateway per tenant instead. Roles are collaboration guardrails inside one trust domain, not isolation.

Before you begin

You need a host that stays on: a small VPS, an office Mac, or any supported install target. OpenClaw should already be installed and onboarded on that host.

You also need a chat workspace the team already lives in. The docs list Discord, Google Chat, Mattermost, Microsoft Teams, Slack, and Telegram among the options.

Use a strong latest-generation model. Shared gateways see more varied input than a solo setup, and modern models are substantially more resistant to prompt injection.

Optional but useful: teammates’ GitHub accounts, if you want verified identity and commit credit.

Step 1: Authenticated ingress, not a public bind

The Gateway binds to loopback by default. Give teammates access through authenticated ingress instead of opening it to the world.

Three patterns, in the order the docs prefer:

• Tailnet (recommended). Put the host on your tailnet and enable Tailscale Serve. With gateway.auth.allowTailscale, Control UI sign-in can use each person’s Tailscale identity. No shared secret to distribute.
• Trusted proxy. Front the Gateway with an identity-aware proxy such as Cloudflare Access.
• Shared secret. Token or password auth works for small teams, but it skips per-person identity.

Identity-backed options are worth the extra setup. They are what turns “someone did something” into “who did what” in the session UI and in commit credit later.

Step 2: A mention-gated bot in the team channel

Connect the channel your team already uses. Group chats are a first-class deployment. The defaults are already team-shaped: group access is allowlisted per room, replies require a mention, and DMs stay on the pairing default.

The first time a teammate DMs the bot they get a pairing code. Approve it with:

openclaw pairing approve slack <code>

The bot then participates when addressed and stays quiet 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.

If the same people should be allowed across several channels, define the list once as an access group and reference it from each channel’s allowlist.

Here is the Slack example from the official guide: a bot allowed in one team channel, that replies 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 },
 },
 },
 },
}

Replace the channel id with yours. Keep requireMention: true unless you have a reason to let the bot talk unprompted in a room.

Step 3: Sign the team in to the Control UI

Each teammate opens the Control UI through the ingress from step 1 and gets a durable Gateway profile: display name, avatar, and per-person appearance preferences.

With Cloudflare Access or Tailscale Serve, GitHub-backed sign-in verifies the account behind the profile. That identity is what later shows up as session attribution and, if you enable it, Git co-author credit.

Step 4: Shared sessions with real attribution

A conversation that starts in the team channel can continue as a session 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)
• the history of people who actually prompted

Plus live presence: 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 the commit. With Git co-author credit enabled, commits from a shared session carry Co-authored-by trailers for the people who steered it. Generated pull requests link back to the session so reviewers can read the conversation that produced the diff.

That trail is why step 1’s identity-backed ingress matters. A shared secret cannot tell you who steered the session.

Step 5: Named roles that bound write and operator scopes

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

The official example sets a default of guest, then defines a maintainer who can write other people’s sessions and a guest who can only view them and must sandbox new sessions:

{
 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. The full policy surface is in the named-operator-roles docs. Roles still sit inside the one trust boundary. They do not make two tenants safe on one gateway.

Verify before you call it done

Three checks from the guide:

• 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, and when not to

Stay on one gateway when the team already trusts each other and you want one bot, one Control UI, and shared sessions.

Split agents on that same gateway when you need separate workspaces or personas — projects that must not share memory or files.

Split gateways when users, customers, or organizations are mutually untrusted. Ideally use separate OS users or hosts. Roles and mention gates will not save you there.

The failure mode this whole sequence prevents is simple: a solo OpenClaw binary, a public-ish chat bot, and no pairing, no identities, and no roles. Everyone shares one agent’s tools, and the session log cannot say who did what.

Next step: walk the official team guide on a host that already has OpenClaw onboarded, start with Tailscale Serve or a trusted proxy, then verify with a mention, two Control UI users, and openclaw security audit.

Sources

• OpenClaw: Get started — teams