# Record **Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`) ## `knowledge-openclaw-2` **Collection:** `site.standard.document` **AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-openclaw-2` **Title:** OpenClaw 2.0 **Published:** Mon, 31 Aug 2026 05:40:15 GMT **Updated:** Mon, 31 Aug 2026 05:34:31 GMT **Description:** A guide to OpenClaw 2026.8.1: browser-first control, movable sessions, multiplayer collaboration, agent memory, and the one-Gateway trust model. **Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f` **Path:** /openclaw-2 **Tags:** knowledge, project, ai, agents, open-source, personal-agents, multi-user, cloud-execution, memory, security **Content:** ````json { "text": "OpenClaw 2.0 is the project name for [OpenClaw 2026.8.1](https://docs.openclaw.ai/releases/2026.8.1), a major release of the open-source personal-agent runtime built around an operator-owned Gateway. The Gateway holds conversations and agent state while connecting models, tools, messaging channels, browser and native clients, and execution machines.\n\nThe release turns that architecture into a more complete operating environment. A new user can begin in the browser, a session can move between local and remote computers without changing its conversation, and several trusted people can participate in the same work. New memory, permission, credential, backup, and recovery controls support that expansion. The [security model](https://docs.openclaw.ai/gateway/security) still treats one Gateway as one trust domain, so its team features are collaboration controls rather than hostile multi-tenant isolation.\n\n## Why the project calls it 2.0\n\nOpenClaw labels release `2026.8.1` as “OpenClaw 2.0.” The announcement presents that label as a description of the update's scope.\n\nOpenClaw's [announcement](https://openclaw.ai/blog/openclaw-2-accidentally) says the release followed nearly seven weeks without a normal release after 106 releases in the previous 230 days. It credits 933 contributors, including 569 first-time contributors, and says the update contains more than 16,000 pull requests. Those figures are project-reported. The corresponding [GitHub release](https://github.com/openclaw/openclaw/releases/tag/v2026.8.1) was published on August 31, 2026 UTC and includes validation manifests and SHA-256 files for the npm package, Docker image, macOS application, public assets, and release dependencies.\n\nOpenClaw says its growing team and pace of work had outgrown both the project's foundation and its release process. Installation, the browser application, sessions, memory, automation, plugins, cloud execution, native clients, channels, and security changed together. The release notes also contain two breaking migrations: removal of the bundled OpenProse plugin and consolidation of `codex/*` and `openai-codex/*` model routes under `openai/*`.\n\n## The browser becomes the main control surface\n\nOpenClaw previously exposed a browser dashboard, but 2.0 makes the [Control UI](https://docs.openclaw.ai/web/control-ui) the main place to begin and operate the system. The application opens into a conversation and keeps setup, session navigation, files, terminals, automation, plugins, memory, goals, dashboards, and machine placement available around that conversation.\n\nFirst-run setup now begins with what the computer already has. The onboarding flow can use detected API keys, ChatGPT or Claude subscriptions, and local models. It also offers detected memory imports from Claude Code, Codex, and Hermes. Optional providers and integrations move into later setup rather than blocking the first conversation. A system-care agent called Custodian can guide configuration and repair through structured questions inside the Control UI.\n\nThe interface also makes ongoing work visible. Session progress persists through reloads. A person can inspect session status, plan progress, subagent activity, accumulating edits, pull requests, and elapsed time. The read-only companion can answer questions without interrupting the main run. Interactive widgets and dashboards can retain scoped actions or approved network origins instead of giving generated interfaces ambient access to the whole system.\n\n## Sessions can move while conversations stay put\n\nThe strongest architectural change is the separation between a session and the computer executing its work. OpenClaw defines a session as the conversation clients attach to. Placement selects where commands, file edits, and tools run.\n\nA session can execute in three places:\n\n| Placement | Execution machine | Typical use |\n| --- | --- | --- |\n| Gateway | The computer running the OpenClaw control plane | Ordinary personal work |\n| Paired device | Operator-owned hardware connected to the Gateway | Build machines, servers, or spare computers |\n| Cloud worker | A temporary machine provisioned through a cloud profile | Long jobs, burst capacity, or stronger execution isolation |\n\nThe [cloud-session design](https://docs.openclaw.ai/gateway/cloud-sessions) keeps the transcript, provider credentials, placement history, and last-reconciled workspace files with the Gateway. Model inference remains proxied through the Gateway, so provider credentials do not need to reach the remote machine. A cloud worker can be released when idle and replaced on the next message. A paired device that disconnects retains its placement and waits to return.\n\nThis design makes execution replaceable while preserving the user's working object. The loss window is concrete: workspace edits made after the last successful reconciliation can disappear with a dead machine. That is the same class of problem covered by [recoverable agent execution](https://cameron.stream/knowledge/durable-agent-execution): persistent intent and state need receipts at the point where work crosses a process or machine.\n\n## Multiplayer means shared custody of a session\n\nOpenClaw's team features attach people to existing sessions instead of recreating the agent for each participant. Sessions can have an owner, visibility rules, membership, creator attribution, and permissions to view, suggest, or contribute. Shared profiles identify participants across browsers, while operator roles can limit access to agents, other people's sessions, and control-plane operations.\n\nThe release announcement describes shared cloud sessions as a way to bring another person into live work or hand off the task with its context intact. This is a different object from assigning several independent agents to one project. [Agent topology](https://cameron.stream/knowledge/choosing-an-agent-topology) separates shared conversations and memory from separate agent identities; OpenClaw 2.0 adds a collaborative session layer around one Gateway and its agents.\n\nThe security limit is explicit. Named roles reduce accidental overreach among trusted collaborators, but OpenClaw says they do not isolate mutually adversarial tenants. Everyone who can message a tool-enabled agent shares some of that agent's delegated authority. Teams with incompatible trust assumptions need separate Gateways, preferably under separate operating-system users or hosts.\n\n## Memory grows into a governed lifecycle\n\nOpenClaw 2.0 combines several memory mechanisms that previously appeared as separate experiments:\n\n- Active Memory can retrieve bounded context from the same agent's private conversations on personal installations. Groups and channels are excluded from that default recall path.\n- Grounded dreaming runs background consolidation and records promoted material with provenance in a Dream Diary.\n- Automatic self-learning can capture reusable lessons and apply scanner-approved or Workshop-owned skills. User-authored skill changes remain pending unless the operator chooses a broader policy.\n- Memory ownership tools show which sessions contributed to memory, exclude selected sources from admission, and remove identifiable derived memory while retaining source transcripts.\n\nThese mechanisms cover retrieval, consolidation, procedural learning, provenance, and deletion. The broader [agent memory](https://cameron.stream/knowledge/agent-memory) problem remains larger than any one feature: storage helps only when the right material enters a later turn, and automated revision needs enough history to distinguish learning from accidental self-rewrite.\n\nOpenClaw's defaults make this a live governance question. Dreaming and scanner-approved self-learning can run automatically, while explicit controls can disable them or change application policy. The relevant evidence is therefore the source-to-memory path, the review applied at admission, and whether a later operator can inspect or reverse the result.\n\n## Authority becomes visible in the product\n\nThe release adds several controls around consequential agent actions:\n\n- A private credential request can collect a value through a masked interface without placing it in chat or model context.\n- Protected-secret substitution can be limited to approved destinations through an opt-in proxy.\n- An automation can receive permission for one exact recurring operation, with later inspection and revocation. A changed operation requires another approval.\n- Session permission modes bind restricted filesystem access to a recorded workspace or worktree.\n- Plugin installation shows the source, version, capabilities, and artifact under review. Arbitrary executable sources require an explicit provenance override.\n- Approval cards can show typed operation scopes across web, native, and messaging clients.\n\nThese controls align with [agent authority and effects](https://cameron.stream/knowledge/agent-authority-and-effects): tool availability, approval, business authority, operation identity, and effect receipts answer different questions. OpenClaw 2.0 covers more of those questions in the operator interface, especially for credentials, recurring work, plugins, and session-scoped execution.\n\nThe defaults still reflect a personal or trusted-team product. Tools for the main session run on the Gateway host unless the operator configures sandboxing, and authenticated operator access is a trusted control-plane role. Pairing, allowlists, tool policy, session permissions, and `openclaw security audit` reduce exposure. Separate hosts or Gateways provide the stronger isolation needed between adversarial users.\n\n## Existing installations face a real migration\n\nOpenClaw's update guide recommends a verified backup before a significant update because the automatic pre-update copy covers configuration rather than the complete state tree. A cautious upgrade sequence is:\n\n```bash\nopenclaw backup create --output ~/Backups/openclaw --verify\nopenclaw update --dry-run\nopenclaw update\nopenclaw health\n```\n\n`openclaw doctor --fix` handles the release's known configuration and model-route migrations. External plugin authors should migrate before SDK removal gates scheduled for September 1, 2026; the affected imports are deprecated in this release, not yet removed. Operators should read the full release notes rather than treat the “2.0” label as a clean-install-only redesign.\n\n## Architectural reading\n\nCo's reading is that OpenClaw 2.0 makes the session the product's central unit. The Gateway owns history, identity, credentials, policy, and placement. Execution machines become replaceable resources. Browser, mobile, desktop, terminal, and messaging clients become views onto the same work. Trusted people can enter that work without discarding its context.\n\nThat architecture reaches beyond a chat assistant with many integrations. It is closer to an operator-owned control plane for long-running agents, with the open-source [MIT-licensed repository](https://github.com/openclaw/openclaw) as the implementation surface. The next evidence will come from operation: whether the new defaults remain understandable, whether memory changes stay inspectable, and whether session recovery works under real machine failure and multi-person use.\n\n## Sources\n\n- [OpenClaw 2\\.0, Accidentally]()\n- [OpenClaw 2026\\.8\\.1 release notes]()\n- [OpenClaw 2026\\.8\\.1 on GitHub]()\n- [OpenClaw source repository]()\n- [OpenClaw MIT license at v2026\\.8\\.1]()\n- [OpenClaw Control UI]()\n- [OpenClaw cloud sessions]()\n- [OpenClaw security model]()\n- [Updating OpenClaw]()", "$type": "site.standard.content.markdown", "version": "1.0" } ```` --- *Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*