OpenBot

OpenBot is a self-hosted agent platform in which each agent — a Bot — gets a computer of its own: a container with its own Chromium browser and logins, its own /workspace volume, and only the tools it has been granted. It is distributed as a template to clone and adapt rather than a hosted product, is marked alpha, and runs from Docker Compose on a laptop with data in your own PostgreSQL. No model ships with it; an administrator supplies the credential, which is encrypted at rest and never logged.

A Bot is any endpoint speaking AG-UI, the open agent-to-user protocol, so agents built on a framework or written by hand register the same way and the governance rides the protocol rather than the framework. Agent endpoints pass the same target checks used for browser navigation, at registration and again on every redirect, and a private address is refused unless it is listed in AGENTENDPOINTALLOWED_HOSTS with exact host and optional port matching.

Every browser, file, MCP, and component action goes through one gateway. It resolves the target from a server-held snapshot, evaluates a CEL policy, writes an audit row, and only then calls the computer — there is no path that acts before the record exists. Deny rules are evaluated before allow, a missing policy permits nothing, and a broken rule refuses rather than opens. Rules can inspect tool.name, intent, bot.id, actor.id, page.url, page.host, element., key, file., and mcp.*, and /admin/audit lists what was permitted, refused, and failed, with the rule behind each refusal.

A person can watch a Bot's screen beside the conversation and see what it ran, read, and saved. When a Bot reaches a login wall or two-factor prompt it asks for help; control is handed over in the same panel and recorded as computer.helprequested, computer.controltaken, and computer.control_released, and Bot actions are refused while a person is driving. Secrets are recorded as having been requested and how long they were, never their contents, and a saved file shows its path and size rather than its contents.

Answers can come back as compiled React components from a gallery or sandboxed components authored in /admin/playground and published without a deployment, with each call checked against whether the component exists, is published, and is not withheld from that Bot. MCP connectors are reached as the person asking, with a curated catalogue plus custom servers that must pass URL checks; unknown and custom-server tools are treated as writes. Sign-in supports Google, Microsoft, or Okta from the environment, plus SAML or OpenID Connect providers registered at runtime and routed by email domain, and a single-user switch admits one administrator so a fresh clone runs without registering an OAuth client.

Features

• A computer per Bot: a supervisor gives each Bot its own container, workspace volume, and browser profile, optionally under gVisor
• Shell access: a Bot can run commands in its workspace through the same gate, with the command recorded whether it is allowed or refused
• Single gateway: target resolution, policy evaluation, and the audit row happen before any action reaches the computer
• CEL policy, fail closed: deny before allow, nothing permitted without a policy, and a broken rule refuses
• Live screen and activity: watch what a Bot is looking at and what it ran, read, and saved
• Take the wheel: hand control to a person mid-task and back, with each transition recorded
• Bring your own agent: any AG-UI endpoint registers as a Bot, validated with the same checks as browser navigation
• Components instead of prose: gallery and sandboxed React components, granted per Bot with per-component data functions
• Governed MCP: catalogue connectors reached as the person asking, with URL checks and write classification for custom servers
• Skills: personal skills attach to their author's Bots, deployment skills are admin-owned, and both are invoked with /