Workspaces organize agents; they do not establish confinement
OpenBot is a desktop workspace for persistent agents. Its README describes separate conversations and workspaces alongside queues, file transfers, an embedded browser and agent messaging. Those features organize work, but they do not establish restrictions on what an agent can reach on the host.
The current README says agents run with danger-full-access and approvalPolicy: never. It warns that agents can read and modify files, run commands, use the network, and control the embedded browser without per-action confirmations after first-launch consent. A description of OpenBot as checking policy before each action is therefore unsupported by this documentation. First-launch consent should not be described as continuing approval of individual actions.
This makes OpenBot a candidate for technical users who accept those permissions for trusted tasks. Users requiring confirmation before every action should avoid it on the evidence supplied. Evaluate it on a machine whose reachable files you are prepared to let an agent change.
What happened when we ran it
Our OpenBot run passed 922 tests. The sandbox installed commit c76373a in 39 seconds on 2026-10-25, recording 1,475 dependencies and 3,675 MB on disk. The build succeeded in 63 seconds. Vitest passed 922 of 922 tests in 41 seconds, with 0 failures.
The checkout contained 5,994 files, approximately 873,212 lines of source and occupied 89.3 MB. The scan recorded monorepo workspaces and 14 CI workflow files. It detected neither a Dockerfile nor a tests directory. The passing Vitest result demonstrates why the absence of a directory named tests does not establish the absence of executable checks.
The sandbox configuration recorded 3 CPUs, 8 GB RAM and image lab-node:22. That label does not establish the actual runtime or operating-system version. Our method was to install the checkout, build it and run its repository tests. The recorded results do not cover desktop startup, provider authentication, an interactive agent task or recovery. No vulnerability-audit result was supplied.
What the workspace provides
OpenBot's README describes FIFO message queues with pause, resume, cancellation, and crash-safe persistence. It also describes managed file transfers and shared channel chats with one task owner and explicit delegation. These are relevant features for developers tracking agent work, but their interactive behavior was not validated in the sandbox run.
The README lists Codex App Server and Claude Code support, plus additional runtimes through ACP. It says OpenBot can download supported provider runtimes and that installed releases do not require Bun or Node.js. Development requires Bun 1.4.2 and Node.js 24. These are documentation statements, not evidence of the toolchain used for our measured commands or of interoperability between providers.
Local operation still uses external services
The README describes OpenBot as local-first, not offline-only. Providers, visited pages and installed plugins can use external services. Before choosing accounts and providers, consider which task information they will receive. Local working files alone do not establish where prompts or browser traffic go.
The README warns against starting OpenBot with --no-sandbox because it removes the boundary between a renderer and the rest of the computer. That warning concerns the Electron renderer boundary. It does not establish confinement for agents with the broad permissions described separately in the same README.
Linux setup needs a separate evaluation
The README specifies fuse3 for AppImages and an AppArmor profile on Ubuntu 23.10 or newer and Debian 13. Remote desktop requires Linux x64 in an X11 session; it does not work under Wayland and is absent from the arm64 AppImage. We did not reproduce those platform procedures.
The current README also documents a Docker server deployment, while the measured checkout scan detected no Dockerfile. We did not run the container path. The current documentation and measured checkout are different evidence snapshots, so the scan cannot establish whether the documented container deployment works.
The release and measured checkout differ
OpenBot v0.50.0 was published on October 25, 2026. Its release notes include: Show when an agent waits for its provider. The release identifies commit 4b39c9a, while our measurements identify c76373a. The passing tests therefore do not establish that we tested the v0.50.0 release build.
Keep three scopes separate: the measured checkout, the pinned release notes and the current README. Release notes document stated changes; current documentation describes current procedures. Neither substitutes for an interactive test of the measured checkout. The supplied extracts do not include the license terms needed for a commercial-use determination.
Choosing an alternative
OpenHands Agent Canvas supports local, remote and cloud agent backends. Consider it when coding automation and execution location drive the decision. Its README warns that installation without a sandbox gives the agent full filesystem access. Choosing a backend requires examining that backend's permissions; this review does not establish that OpenHands is safer.
Browser Use documents running its Python agent locally with a chosen model. Consider it when browser automation belongs inside your own application. We did not run either alternative or compare resource use, reliability or model quality.
How to read the ratings
The documentation rubric has five anchors: 1 means product identification, 2 means partial setup instructions, and 3 means an actionable setup outline. A 4 requires reproduced setup and a representative task. A 5 also requires verified troubleshooting or recovery guidance. OpenBot receives 3 for its documented installation steps, provider setup and platform restrictions. Repository command success does not verify those desktop procedures.
Setup ease, community and maturity remain unassessed. For an initial evaluation, use disposable files and avoid valuable browser logins. Confirm desktop startup and provider authentication, give the agent a task whose changes you can inspect, and test recovery of conversations, queued work and files before relying on persistent tasks.