Chats and devices share an operator trust boundary
OpenClaw can put an assistant in your existing chats, but operating that assistant also means deciding what it can reach. The current README describes a Gateway connecting models, tools, messaging services, and optional companion devices. The Control UI, CLI, and TUI connect to that Gateway.
The README now describes both personal use and shared team deployments. The security policy supplies the qualification: a shared Gateway is not a security boundary between adversarial users. Session ownership and visibility help people use the system; they do not establish per-user host authorization. A company-shared agent can fit this model when users share a trust boundary and use dedicated infrastructure and accounts.
Choose separate Gateway and OS-user or host boundaries when operators require isolation. Do not infer that opening separate sessions separates their authority over the machine.
Package onboarding and source development are different paths
The current README says the installer supports macOS, Linux, and Windows and can provision a supported Node.js runtime. Direct package installation currently requires Node.js 24.16+ or 26.1+, with Node 26 recommended. Onboarding verifies model access, creates the workspace, and configures the Gateway, according to the README. Confirming an assistant response and configuring messaging channels remain separate steps.
At the measured commit, the README instead specified Node.js 22.22.3+, 24.15+, or 25.9+. Preserve that distinction when reproducing the historical run. The recorded image was lab-node:22; its label alone does not establish the exact runtime version.
Source development uses a pnpm workspace. The README explicitly says plain root npm install is unsupported. Our source dependency installation is not a measurement of the published-package onboarding experience.
What our recorded run establishes
Our recorded run began at 2026-08-24T22:04:37.352Z and used commit d74555299d84608a6822a3b41e83788ed1b58c5e. The recorded configuration was 3 CPUs, 8 GB of memory, and image lab-node:22. No new execution was performed for this correction.
Dependency installation succeeded in 51 seconds, including dependency downloads and installation scripts. The harness recorded 2,759 MB for the installation. Its dependency-count field was 1, while the raw log shows many dependencies downloaded and added. Treat that count as a harness field, not the number of packages installed. The raw log identifies pnpm v11.22.0 and the local workspace dependency @openclaw/ai 2026.8.1; it does not establish the root package version.
The build succeeded in 545 seconds. The recorded checkout was 431.6 MB with 33,600 files, 87 CI workflow files, a Dockerfile, Compose configuration, and workspaces. These figures describe that checkout and environment, not current installation requirements.
The test command reached the 900-second cap and exited with code 124. The recorded parser summary lists 16,128 passed, 2 failed, and 35 skipped, with a total of 16,165. Complete-log reconciliation was not performed, so these figures do not establish exhaustive unique test coverage or a suite pass rate. Skipped tests are not failures.
The supplied tail includes completed ClawHub lifecycle tests and notices of no output for 30,000 and 60,000 milliseconds. It does not name the two failures or explain why the command remained running. The result is an incomplete test run, not proof that OpenClaw is broken.
The record contains no separate installed-binary check, completed onboarding, live messaging-channel validation, measured assistant workload, or security audit. Test names mentioning live behavior do not establish that we independently performed those activities.
Sandboxing needs an explicit decision
The security policy says sandbox mode defaults to off; non-main and all are available isolation modes. Main-session tools run on the host unless sandboxing is configured. The sandboxing guide says the Gateway stays on the host while enabled tool execution moves into a sandbox backend. It lists Docker, Podman, SSH, OpenShell, and Crabbox paths.
Sandboxing and tool policy work together. A denied tool stays denied, and elevated execution is an explicit route outside the sandbox. Before connecting untrusted messages, decide which sessions need sandboxing, what workspace data they can access, and which tools they may invoke. Enabling a sandbox does not establish that every executable extension is contained.
Installed or enabled plugins receive the trust level of local code on the Gateway host, according to the security policy. Review their source, credentials, and update process with that authority in mind. Our run did not evaluate plugin safety or attempt a security boundary bypass.
Match maintenance advice to a version
The supplied v2026.7.1-2 release page documents an npm plugin-update fix. It does not establish that this remains the latest release.
The supplied Doctor TTS report is a useful example of why version context matters. Its original report described repairs being announced without the expected per-agent settings being saved. On October 9, 2026, the reporter stated that OpenClaw 2026.9.9 fixed it through commit 127a2ba and closed the issue as completed. The reporter advised updating and running openclaw doctor --fix once. That is upstream repair guidance, not a fix we independently tested, and the issue should not be presented as an established current failure.
Two alternatives for different priorities
Open WebUI documents a self-hosted interface for Ollama and OpenAI-compatible APIs, plus roles, groups, and permissions. Evaluate it when a web model interface and those administration features are your main requirements. This review does not establish its security or performance relative to OpenClaw.
Letta emphasizes stateful agents with memory. Its README directs active development to letta-ai/letta-code and lists an interactive terminal UI, App Server, messaging channels, and a TypeScript Agent SDK. Evaluate it when that memory and application interface fit your project. The older Letta V1 API server is archived; it is not the current development path.
How to read the scores
These are editorial judgments about the evidence available here, not measured product benchmarks. The five-point rubric is: 1 means substantial documented obstacles with little supporting validation; 2 means substantial operator work or limited validation; 3 means a usable documented path with material unknowns; 4 means detailed supporting evidence with bounded gaps; 5 requires broad corroboration and validation beyond this record. Unknown adoption, compatibility, or reliability cannot earn a high score.
Setup earns 2 because onboarding is documented but credentials, channels, and policy remain operator work, and our run covered source dependencies and build only. Docs earns 4 for explicit setup, architecture, trust, and sandbox guidance, with deployment paths untested here. Community earns 3 for documented contribution and support routes; response quality and adoption were not measured. Maturity earns 3 for a successful historical build and a documented upstream repair, tempered by an incomplete test run and no operational reliability measurement.
For a first evaluation, use a dedicated runtime and accounts, restrict tools, configure sandboxing deliberately, and verify one assistant response before adding channels or plugins. Record the installed version separately from any source commit used for development.