OpenClaw 2.0 puts a whole team inside one Gateway's trust boundary

Start with what a shared session actually hands over. The Gateway runs on the operator's machine and owns sessions, credentials and tool access ^[17]. When a second person joins active work, the session's accumulated context comes with them ^[12], and the execution may not be on that machine at all: a session can run on the Gateway host, a paired device or a temporary cloud worker ^[13]. The canonical transcript, the model credentials and the workspace state stay with the Gateway, so provider credentials do not need to be copied to the remote execution machine ^[14]. That separation is good engineering, and it is the specific reason a team with a rule against pasting API keys into a hosted service can evaluate this at all.

The limit is documented rather than buried. OpenClaw's security documentation defines one trust boundary per Gateway, and for participants who do not trust each other it recommends separate Gateways, separate credentials and preferably separate operating-system users or hosts ^[15]. Shared access is scoped to an individual, a family or a team whose members already trust one another, and multiplayer does not make one install a multi-tenant service ^[16]. So the unit of isolation is the install. There is no narrower role described inside a session, which means an invitee inherits an agent that can hold credentials, read messages and execute commands ^[11].

The cadence figures are worth converting. Averaged out, 106 releases across 230 days is one roughly every 2.2 days ^[20]. The pause before 2.0 was near seven weeks ^[8], which is about 22 of those intervals ^[21]. If more than 16,000 pull requests in this cycle are roughly half of everything ever merged ^[4][8], the project's lifetime merged total sits near 32,000 ^[22]. All self-reported, though the repository's public activity is consistent with that scale ^[5].

Treat the five-minute onboarding path the way you would treat any vendor benchmark: it measures the run the documentation chose, installation to a working browser conversation ^[6]. For it to transfer, model access has to be sitting on the box already, whether that is a ChatGPT or Claude subscription, an API key or a local model ^[1], and you have to leave out model authentication, channel pairing and optional plugins, which the docs concede can extend the process ^[6]. On a team, pairing is the step that repeats per person and per channel across WhatsApp, Telegram, Slack, Discord, Signal and iMessage ^[18]. Optional configuration now gets finished in conversation instead of in the setup flow ^[2], which is sensible product design and also means the record of what you configured is a transcript.

One more adoption cost, from the release's own scope. Installation, messaging, memory, skills, model support, automations, native apps, plugins and security all changed in a single cycle that began as an onboarding and browser project ^[9]. My read: if you have a running 1.x install with paired channels, plan this as a rebuild rather than an upgrade, and expect the security surface to be the part you re-check.

What would have to be true for the team story to hold is that your trust graph is one blob per credential set. If a contractor needs a narrow session, the documented answer is another Gateway under another OS user, and that provisioning is yours ^[15]. The flagship example in the announcement, meanwhile, is still monitoring a parent's inbox for school notices and forwarding selected ones through Telegram ^[19], which tells you where the polish went.