OpenClaw 2.0 is out, and the release notes single out three changes: setup that detects what is already on the machine instead of interrogating the user, a rebuilt browser app with a live session view, and cloud sessions that more than one person can join. Taken together they move the project's center of gravity away from a single developer's terminal and toward a gateway that brokers work between teammates, paired hardware and rented cloud machines. That is a meaningfully different product from the one version 1 shipped.
Setup came first for a reason. Previously users had to walk through a long sequence of configuration steps by hand. OpenClaw now discovers the resources already available on the computer and uses them on first run, leaving the remaining parameters to be changed later in conversation with the assistant itself. Configuration-as-chat is a design decision with real consequences — settings become discoverable only by asking — but as an onboarding fix it is the right trade. Manual setup is where self-hosted agent tools lose most of the people who try them, and a project that depends on its own community for skills and extensions cannot afford a first hour that filters out everyone but the patient.
In the chat interface there is now a compact status indicator called Session Feed, showing how an active session is progressing: evaluations, plan progress and requests to add changes. Beside it runs a built-in side thread for asking questions about the current session without interrupting the agent. The documentation describes what happens underneath: the gateway loads a limited snapshot of session state and sends it to a separate auxiliary model. That detail is the most interesting engineering choice in the release. Asking "what are you doing right now" becomes a cheap, isolated inference rather than an interruption of the main loop — but it also means the thing answering questions about the session is not the thing running it, and it sees only what the snapshot contained. The interface presents one conversation; there are two models in it with different information.
The third change, Shared Cloud Sessions, lets several users work on the same tasks. Teammates can be pulled into work already in progress, or assigned tasks together with the context they need. OpenClaw says its own team already uses this while building OpenClaw, which is the only evidence offered that it holds up under real use.
Sessions can run in three places. The default is the local gateway. A user can attach their own hardware with `openclaw connect` in Paired Devices mode, or spin up a session on a disposable rented machine through the Crabbox provisioning tool, which supports platforms including AWS and Hetzner. Provider credentials, the documentation specifies, always stay on the gateway and are never passed to the remote machine.
Beyond those three headline items, the changelog lists work on messages, memory, skills, model support, automation, native apps, extensions and security, with the full log published in the release notes and the source on GitHub.
Here is what stands out to me about the shape of this release. Every change points the same direction — more machines, more people, more provider credentials converging on one process — and security appears as one entry in a list of eight, with no detail attached. The gateway is now the machine that holds cloud provider credentials, the pairing relationships to personal hardware, and the live state of sessions belonging to multiple people. It has quietly become the highest-value target in any OpenClaw deployment, and the announcement treats it as plumbing.
The question the release notes do not answer is what shared means when two people are driving one agent. Nothing in the announcement covers whose permissions apply when a teammate joins a running session, what they can see of what happened before they arrived, or which account is on the hook for an action the agent takes while both are watching. Single-user agent tools get to treat authorization as identity: the person at the keyboard is the person who approved. Multiplayer sessions break that equation, and the fix is not a feature you add after the collaboration ships.
That is the tension in 2.0. The setup work lowers the cost of getting started, and the session work raises the cost of getting it wrong — the same release that makes OpenClaw easy enough for a team to adopt in an afternoon also gives that team one process holding everyone's credentials and everyone's running work.