CopilotKit OpenBot v0.0.1 is an MIT-licensed, self-hosted AI agent platform that gives each agent its own containerized computer, browser, files, and tools, and routes every action through a policy gateway that records an audit row before acting. As of the 21 August 2026 snapshot, it is an alpha project: the maintainers say to expect rough edges, the default configuration runs without sign-in, the documented target is a laptop, and open issues raise blockers around secrets exposure, credential rotation, and the built-in Knowledge coworker. Evaluate it if you want governed, human-in-the-loop browser agents on your own infrastructure; do not treat it as a production system yet.

This is a source and documentation review based on the repository snapshot, README, release notes, and open issues collected on 21 August 2026. No local installation or runtime test was performed.

Key facts at a glance

What OpenBot is

Per the README, OpenBot is a set of AI coworkers, each with a computer of its own: a real browser with its own logins, its own files, and only the tools you grant. Every action is decided before it happens and recorded after. The stack is TypeScript: a React/Vite app, a Hono API server, an agent computer that drives Chromium, a supervisor that creates one computer per bot, and PostgreSQL with pgvector for product data, policy, audit, credentials, and channels. Docker Compose brings up the parts, and durable threads and memory come from CopilotKit Intelligence, which the maintainers say can be self-hosted or used on a free plan.

The design is framework-agnostic through AG-UI, the open protocol for agent-to-user interaction. The maintainers say any AG-UI endpoint, whether built with LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK, or by hand, can be registered as a coworker, and that governance rides the protocol rather than the framework. Three example coworkers ship as configuration rather than code: General Assistant, Knowledge, and Risk Analyst.

No model ships in the box. An administrator supplies a model key; the proof-of-concept bot uses OpenAI, and the LangGraph bot can use OpenAI, Anthropic, or Google, according to the README. An open feature request asks whether ChatGPT subscription OAuth could replace the API key requirement; as of the snapshot, that is not supported.

How the governance model is designed

The central claim is that the gateway is the only way in. Browser, file, shell, MCP, and component actions are resolved against a server-held snapshot, evaluated against policy, recorded in an audit row, and only then executed. The README describes CEL policy that fails closed: deny is evaluated before allow, a missing policy permits nothing, and a broken rule refuses rather than opens. The audit screen lists permitted, refused, and failed actions, with the rule that caused each refusal.

Other documented controls: a bot that hits a login wall or 2FA asks for help, and a person can take over its browser, with bot actions refused while a human drives. Secrets never enter the transcript; credentials are stored encrypted, never returned by an API, and redacted from audit events. Computers bind to loopback by default and require a per-container token. Shell commands go through the same gate, so policy can refuse the shell outright or particular commands. MCP tools that are not positively classified as reads are treated as writes, and a curated catalogue ships for Atlassian, Box, Slack, Salesforce, and ServiceNow.

These are the maintainers’ documented design claims. Since this review is based only on repository evidence, treat them as intended behavior and verify them in your own environment.

Where the alpha stage shows

Maintenance signals point the same way as the alpha badge: the repository was created on 17 August 2026 and last pushed on 21 August 2026 at the snapshot, there is a single release, 33 open issues, and the README warns that things will move. The release notes state there is no hosted deployment yet.

The default is not a multi-user system

OPENBOT_DEV_NO_AUTH is the default and admits every request as one administrator, per the README and release notes. Google sign-in can be wired up with four settings, and a partial auth configuration is refused at startup, but the README also warns that TRUSTED_ORIGINS defaults to localhost:3000, which is not where start.sh serves the app. That is an easy misconfiguration in local setup and a real risk if it carries over to a deployment.

Deployment is single machine and single replica for now

Release notes say the project is local only for now. The deployment docs describe one image that can carry the app, API, browser, and optionally PostgreSQL, with minimum sizes and platform notes, and explain why it runs as one replica for now. If you need horizontal scaling, high availability, or managed hosting, this release does not offer it.

Open issue: the one-container deployment can expose secrets to a bot shell

Issue #66, filed by a contributor and open at the snapshot, describes how a bot shell inherits the process environment. In the docker-compose shape, the agent computer receives only COMPUTER_TOKEN, which the reporter calls close to harmless. In the documented one-container image run with –env-file .env, the computer service inherits the container’s environment, so a single env command can return the encryption key, DATABASE_URL, OpenAI and Intelligence keys, and service tokens. The reporter notes the default policy allows all and that a bot can become root inside its container; because the supervisor is not in that image, every bot shares one computer, and EMBEDDED_POSTGRES=on can put the database in the same container. The proposed fix is an environment allow-list rather than a deny-list. Treat this as a blocker for any production-shaped deployment until it is resolved and verified.

Open issue: the Knowledge coworker may not retrieve anything

Issue #59, also open at the snapshot, reports that the shipped Knowledge coworker is configured as built-in with only a system prompt, on the same path as General Assistant, and that path has no retrieval step. According to the issue, retrieval-and-cite code exists but has no callers outside tests, the repository is in memory only, no connector adapters are implemented, and the worker has no scheduler. The reporter’s conclusion: a deployment running the shipped example has a bot that answers as if it has authorized company knowledge behind it and never actually searches anything. If company-knowledge answers with citations matter to you, verify this path before relying on it.

Open issue: credential rotation is not atomic

Issue #53 reports that credential rotation writes the new credential before revoking the previous one, with no rollback. A failed revoke can leave an orphan that the runtime resolves as the active credential, no audit event marks the failure, and retries can multiply live copies. That is acceptable for a test bench and a problem for automated key rotation in production.

What to check before production

• Auth: replace OPENBOT_DEV_NO_AUTH with Google sign-in, set all four auth variables together, and confirm TRUSTED_ORIGINS matches the URL you actually serve.
• Secrets: review what bot shells can read in your chosen topology; do not run the single-image path with –env-file .env until issue #66 is addressed or the image is hardened.
• Isolation: prefer the compose topology with a supervisor and per-bot computers, and verify gVisor (COMPUTER_RUNTIME=runsc) and Chromium sandbox (COMPUTER_SANDBOX=on) support on your host before trusting isolation claims.
• Policy: define explicit deny rules and test that unknown actions are refused; malformed JSON in AGENT_COMPUTER_POLICY is documented to stop server startup.
• Knowledge: confirm retrieval actually runs for the Knowledge coworker, or replace it with your own retrieval agent.
• Credentials: test rotation end to end and reconcile orphaned credentials, given issue #53.
• Dependencies: license or self-host CopilotKit Intelligence, and confirm where threads and memory are stored.
• Backup and scale: plan PostgreSQL and pgvector backups, and accept the documented one-replica constraint.
• Network: keep computers on loopback, and leave AGENT_COMPUTER_ALLOW_PRIVATE_HOSTS unset unless bots should reach your own services.

Who should consider OpenBot

This release is most useful to teams that already work with AG-UI agents or CopilotKit and want to evaluate a governance layer: per-agent isolation, a policy gateway, audit, and human takeover. It is also a reasonable proof-of-concept target for a founder or operator who wants to see what an agent with a computer looks like before committing to a product.

It is not yet for teams that need multi-user auth out of the box, hosted or highly available deployment, production-grade company-knowledge retrieval, or hardened secret isolation, unless they budget for custom development and maintenance. The project is honest about its stage, but the open issues above are exactly the kind of thing that should be resolved before real credentials or customer data are involved.

Evaluation questions

• Does your workload actually need browser automation with human takeover, or would a simpler tool integration do?
• Can your team operate Bun, Docker, PostgreSQL with pgvector, and a Chromium-based service, and keep them patched?
• Can you accept the CopilotKit Intelligence dependency, or do you have capacity to self-host it?
• Do you need retrieval-backed answers today? If so, v0.0.1 is not there yet per issue #59.
• Are you prepared for breaking changes while the project is under active development?
• Compare against building a smaller policy and audit gateway around your own AG-UI agents if you only need governance for a few tools.

The verdict

OpenBot v0.0.1 is a well-documented architecture for governed AI agents, and the MIT license makes it viable to evaluate and fork. As a release, it is alpha software aimed at a laptop, with a default no-auth mode, an external Intelligence dependency, and three open issues that are material to production use. The sensible move: prototype on an isolated machine, review the security issues in your chosen topology, and plan production only with a hardened deployment and custom work for the gaps that matter to you.

Sources

• CopilotKit/OpenBot repository
• OpenBot v0.0.1 release notes
• Issue #66: a bot’s shell is handed the deployment’s environment
• Issue #59: Knowledge coworker’s search-and-cite path is never called
• Issue #53: credential rotation leaves an orphan credential
• OpenBot deployment documentation
• OpenBot configuration documentation

If these alpha gaps are in your way, I can help in two concrete ways: set up the auth, policy, and deployment topology correctly for your infrastructure, and build what is missing for your use case, such as a working retrieval path for company knowledge, connector adapters to your internal systems, or a hardened deployment that keeps bot shells away from your secrets. That is the AI agent and integration work I do; I will also tell you plainly when this project is not ready for your production load.