OpenBot: CopilotKit's Open-Source AI Coworkers With a Computer Each

CopilotKit just shipped the thing a lot of teams asked for after Grok Bot: a coworker with its own computer, except you run it. CEO Atai Barkai announced OpenBot on August 19, 2026 as "an open source Grok Bot that works with ANY agent harness, designed for real companies." The launch post crossed 438.5K views in a day. The GitHub repo hit 1.1k stars and 105 forks within about a week of first commit, tagged v0.0.1, MIT-licensed, and labeled alpha.

The README's one-line pitch is the product: "AI coworkers you can hand real work to, and actually trust with the access." Each Bot gets 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. That is a different bet from a chat agent with a pile of MCP servers — and a different bet from Grok Bot's hosted VMs, which you cannot inspect, fork, or run on your laptop.

TL;DR — what people are asking

Is this just an open-source Grok Bot?

Barkai's tweet used that framing on purpose. Grok Bot is the consumer-facing proof that "an agent with its own computer that logs into your SaaS" is a category people want. Access is gated to SuperGrok Heavy / Cursor Ultra / Cursor Teams Premium. You do not get the VM image, the policy engine, or the audit log as a repo you can run.

OpenBot inverts that. CopilotKit is the company behind the AG-UI protocol — the open agent-to-user interaction layer already adopted across LangChain, Mastra, Pydantic AI, Google, Microsoft, and AWS. OpenBot is that protocol turned into a company-shaped product: coworkers, channels, a live screen, human takeover, generative UI components, governed MCP, and an audit trail. The agent runtime is yours. The governance rides AG-UI rather than a CopilotKit-only harness.

That distinction matters if you already have an agent. You do not rewrite it for OpenBot. You point OpenBot at an AG-UI endpoint the same way you would point a chat UI at one. If you are still choosing a harness, OpenBot is not a replacement for Claude Code or Codex — it is the layer that lets those agents (or any AG-UI agent) sit next to a real browser with a policy in front of the tools.

The catch: MIT code, CopilotKit Intelligence runtime

The repo is MIT. The quick start is not "clone and go." The API server refuses to start without:

• DATABASE_URL
• KEY_ENCRYPTION_KEY
• MANAGED_AGENT_AG_UI_URL
• INTELLIGENCE_API_URL / INTELLIGENCE_GATEWAY_WS_URL / INTELLIGENCE_API_KEY
• COPILOTKIT_LICENSE_TOKEN

Durable threads and memory live in CopilotKit Intelligence, not in the local Postgres. The local database holds product data, policy, audit, credentials, grants, channels, knowledge, and component metadata. Conversations survive restarts because Intelligence stores them, and each deployment stamps the threads it owns.

This is the same class of "open source, but" that showed up when Cloudflare OS shipped Apache-2.0 code that still runs best on Cloudflare primitives. OpenBot's code is inspectable and self-hostable. The memory plane is a licensed CopilotKit service unless you run Intelligence yourself. If vendor-independence is the reason you wanted "open source Grok Bot," read that requirement before you budget a rollout.

You also bring your own model. Nothing ships in the box. The proof-of-concept Bot uses OpenAI; the LangGraph Bot can use OpenAI, Anthropic, or Google. OPENAI_BASE_URL (and the Anthropic / Google equivalents) let those OpenAI-shaped calls hit a gateway or proxy instead of the vendor directly.

What "any harness" actually means

A Bot is not a CopilotKit agent class. It is an endpoint that speaks AG-UI. From /agents you create a coworker with a name, title, role, visibility, optional AG-UI URL, and optional write-only auth header. Tenant packages declare agents in agents.yaml as either built-in (a system prompt) or remote-ag-ui (an endpoint). Product-created coworkers without a custom URL fall back to MANAGED_AGENT_AG_UI_URL.

The launch thread listed Google ADK, AWS Strands, Microsoft Agent Framework, LangChain, CrewAI, Mastra, Pydantic AI, and the Claude Agent SDK. The mechanism underneath is CopilotKit's Channels SDK — the same "bring any AG-UI agent to any channel" work CopilotKit published earlier in August for Slack and Teams. OpenBot is that idea pointed at a self-hosted coworker UI instead of a chat vendor.

If you already think in MCP terms: MCP is how an agent reaches tools. AG-UI is how an agent reaches a user — streaming, shared state, human-in-the-loop, generative UI. OpenBot sits on both. Skills in OpenBot are instructions, not capabilities: personal skills attach only to Bots their author owns, deployment skills are admin-owned, and both are invoked with / in the composer. That matches the agent skills split explainx.ai has been arguing for — skills tell the agent how to work; tools and computers decide what it can touch.

The gateway is the product

Most "computer use" demos fail the company test in the same place: the model can click, so it can click anything. OpenBot's claim is that there is no path from a Bot to a browser, a file, an MCP server, or a UI component that skips the gateway.

The loop, as CopilotKit describes it:

1. You talk to the server.
2. The server sends the turn to a Bot over AG-UI.
3. Every tool call comes back through the gateway.
4. The gateway resolves the target from a server-held snapshot, evaluates CEL policy, writes an audit row, and only then calls agent-computer — or refuses and names the rule.

CEL (Common Expression Language) rules can inspect tool.name, intent, bot.id, actor.id, page.url, page.host, element.*, key, file.*, and mcp.*. Deny is evaluated before allow. A missing policy permits nothing. A broken rule is supposed to refuse rather than open.

That last sentence is doing a lot of work, and the issue tracker already disputes it — more below. Architecturally, though, this is the difference between Claude Cowork (a product with Anthropic's permission model) and a policy engine you can read. It is also closer to Cloudflare OS Gatekeepers than to a coding harness: the interesting code is not the agent loop, it is the thing that stands in front of the loop's tools.

/admin/audit lists permitted, refused, and failed actions. /admin/boundaries is where you add deny rules and presets. Secrets never enter the transcript: the trail records that a secret was requested and how long it was, not what it said. Credentials go through /admin/credentials, are encrypted at rest, are never returned by an API, and are redacted from audit events.

A computer per Bot, not one shared browser

The supervisor creates one container per Bot: its own /workspace volume, its own Chromium, its own browser profile. COMPUTER_SUPERVISOR_URL is what switches you from one shared computer to that per-Bot fleet. Set COMPUTER_RUNTIME=runsc to run computers under gVisor where the host supports it.

This is the same isolation thesis Cloudflare Computer made at the runtime layer — agents need a computer, not a container they all share — implemented as Docker Compose on a laptop instead of Workers isolates. Computers bind to 127.0.0.1 and require a per-container token, so knowing a port is not enough to reach a logged-in browser.

When a Bot hits a login wall or a 2FA prompt, it asks for help. Control is handed over in the same panel and recorded as computer.help_requested, computer.control_taken, and computer.control_released. While a person is driving, Bot actions are refused rather than queued. That is a real human-in-the-loop handoff, not a screenshot pasted back into chat. It is also the feature that makes "let this thing hold my logged-in browser" slightly less insane than it sounds — you can take the wheel without killing the session.

Compare that to macOS Harness, which hands an LLM six raw Mac primitives against your desktop. OpenBot isolates the desktop (a containerized Chromium) and puts a policy in front of it. Different threat models: one is "drive the machine I already use"; the other is "give the agent a machine of its own."

Generative UI is the other CopilotKit-native piece. Compiled React components live in app/src/components/gallery/; sandboxed ones are authored in /admin/playground and published without a deploy. Every component call asks the server whether it exists, is published, and is not withheld from that Bot. Data functions are granted per component. That is closer to a curated component library than to Google's generate-arbitrary-UI research — slower to be surprising, faster to be governable.

How OpenBot compares

None of these replace a coding harness. If the job is a repository, stay on Claude Code / Codex / OpenCode. OpenBot is for the other job: an agent that should operate a browser, files, and SaaS tools inside a company boundary, with a record of what it was allowed to do.

How to try it (and what to try first)

Requirements from the README: Docker, Bun 1.3+, a CopilotKit Intelligence project and license, and a model key.

cp .env.example .env
npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write
# put the cpk-... key in INTELLIGENCE_API_KEY
# set OPENAI_API_KEY (or another model key)
openssl rand -base64 32   # your KEY_ENCRYPTION_KEY; the example is public
bun install
bash scripts/start.sh
# app: http://localhost:3010  —  API: :3001

scripts/start.sh brings up Docker services, applies migrations, starts the Hono API on port 3001, starts the Vite app on 3010, and waits on health routes. OPENBOT_DEV_NO_AUTH is on by default: every request is admitted as one administrator. That is fine on a laptop that never leaves loopback. It is not fine if you bind this to a network.

CopilotKit's own first-hour script is the right evaluation, not a demo video:

1. Open /bot and ask: Open news.ycombinator.com and tell me the top story.
2. Ask the Bot to fill out https://httpbin.org/forms/post, then open /admin/audit.
3. Open /admin/boundaries, add a deny rule, retry the same browser action, and confirm the refusal names the rule.
4. Create a coworker from /agents, give it a standing role, start a channel.

That sequence tests the three claims that actually matter: the computer works, the audit exists, and the policy can say no. If step 3 does not refuse, you do not have governance — you have a browser agent with extra UI.

Three example coworkers ship as YAML, not code: General Assistant, Knowledge, and Risk Analyst. The default tenant package is examples/fintech. Add your own in agents.yaml or from /agents.

Architecture in one table

The computer also exposes lower-level token-protected service endpoints. CopilotKit's own docs say not to use them to bypass the gateway. That sentence is the whole security model in miniature: if you punch a hole around the gateway, you no longer have OpenBot — you have an ungoverned browser container.

What people are asking

"Can I run this without CopilotKit's cloud?" You can run the app, API, Postgres, supervisor, and Bot computers locally. Durable threads currently go through Intelligence unless you self-host that too. The license token is a required env var. "Runs on your machine" is true for the computers and the audit log; it is not true for the default memory plane.

"Does this replace Claude Cowork / Claude Code?" No. Cowork is a hosted Anthropic product with a different permission story — see our safety guide and vulnerability write-up. Claude Code is a coding harness. OpenBot is a self-hosted coworker platform that will take a Claude Agent SDK endpoint if you have one.

"Is CEL policy enough for a real company?" On paper: deny-first, fail-closed, every refusal named, audit before act. In the repo this week: reviewers have already filed issues about deny rules that can fail open and authorization helpers that are tested but not called on several request surfaces. Policy engines are only as good as the path that actually invokes them. Treat /admin/boundaries as the intended control, not as a completed one.

"Where do MCP servers fit?" /admin/plugins configures MCP servers, grants, and deployment skills. A curated catalogue ships for Atlassian, Box, Slack, Salesforce, and ServiceNow. Custom servers must pass URL checks. Any tool not positively classified as a read is treated as a write. Browse explainx.ai's MCP servers directory for the broader ecosystem; OpenBot's catalogue is a governed subset, not a registry replacement.

"What about auth for a team?" Default is OPENBOT_DEV_NO_AUTH. Google sign-in needs BETTER_AUTH_URL, BETTER_AUTH_SECRET (at least 32 characters), GOOGLE_OAUTH_CLIENT_ID, and GOOGLE_OAUTH_CLIENT_SECRET together, plus TRUSTED_ORIGINS (must be http://localhost:3010 locally — the default 3000 is wrong for start.sh) and INITIAL_ADMIN_EMAILS. A partial set refuses to start rather than silently skipping OAuth.

The honest limitations

OpenBot is five days of git history dressed as a company platform. That is not an insult — it is the release cadence of 2026 — but it should change what you plug into it.

• Alpha, by the authors' own warning. "Expect rough edges and bugs, and expect things to move." v0.0.1, four listed contributors, 9 open issues and 17 pull requests as of August 20, 2026.
• Default no-auth. OPENBOT_DEV_NO_AUTH admits every request as one administrator. Fine for a laptop demo. Dangerous if you treat "it runs" as "it is multi-user safe."
• Authorization gaps already reported. Public issue #35 describes canRunAgent as defined, tested, and not called on several surfaces that take a Bot id from the request — so a signed-in user may be able to drive another person's private coworker. Issue #29 reports a Bot id from the URL becoming a filesystem path. Do not treat those as instructions; treat them as reasons this is not a production identity boundary yet.
• Fail-closed is the claim, not yet the proven invariant. Issue #26 reports a deny rule that returns a non-boolean silently failing to deny. Issue #25 reports the navigation floor missing IPv6 spellings of private addresses, including cloud metadata. A policy engine that can fail open is the opposite of the README's "a missing policy permits nothing."
• Containers may run as root. Issue #39 flags Dockerfiles that do not specify a USER. Combine that with a logged-in browser and you have a worse sandbox than the gVisor flag implies.
• CopilotKit Intelligence is a hard dependency for the documented happy path. MIT on the repo does not mean zero vendor.
• explainx.ai has not run OpenBot for this post. This is a read of the public README, the August 19 announcement, and the public issue tracker — not a hands-on security review.

If you try it, try it the way CopilotKit suggests: a throwaway form on httpbin, then a deny rule, then the audit page. Do not connect production Slack, Salesforce, or a browser profile that holds payroll. For the broader pattern of credentialed agents going wrong, see when an AI agent gets a company hacked.

Related on explainx.ai

• grok.bot is not Grok Bot — $1M domain ask, independent owner (Aug 20)
• Grok Bot early beta — persistent VMs that sign into your tools
• Grok Bot real-world use cases — what early users are actually shipping
• Cloudflare OS — self-hosted agent workspace with Gatekeepers
• Cloudflare Computer — agents need isolates, not just containers
• macOS Harness — six raw Mac primitives, no per-app tools
• What is an agent harness?
• What is MCP?
• What are agent skills?
• How to use Claude Cowork safely
• LoopX — a control plane above the agent loop
• AG-UI · OpenBot · Computer use

Primary sources: Atai Barkai's OpenBot announcement on X (August 19, 2026) · github.com/CopilotKit/openbot README, architecture notes, and public issues as of August 20, 2026 · copilotkit.ai/openbot

Star counts, issue numbers, env vars, and port maps reflect CopilotKit/openbot as of August 20, 2026. OpenBot is alpha and changing quickly — re-read the README and issue tracker before you point it at anything with real logins. Follow @explainx_ai for updates.