企业级 AI 工作台：每个应用都是可让 AI 改代码的私有沙箱

Cloudflare OS is an AI agent workspace built on Cloudflare Workers, originally developed for internal use at Cloudflare and now open sourced under Apache-2.0. It is not a traditional operating system; it is an "operating system" for both the company and for AI workloads. The project ships an agent chat UI, sandboxed app development for "gadgets", and a security layer called Gatekeepers, so employees from engineering to sales can safely let AI do real work.

The project challenges two assumptions of the last 25 years of cloud software. First, centralized SaaS: if every user runs the same hosted instance, a bug can leak everyone's data, and users cannot change the software to fit their needs. Second, human-in-the-loop approvals: traditional synchronous approval forces an agent to stop and wait, which leads users to bypass safety with auto-approve. Cloudflare OS instead gives each user a private, sandboxed copy of an app, and Gatekeepers turn approval into a simulated, asynchronous review flow.

In Cloudflare OS, the basic unit is the "gadget". When you ask for a slide deck, the system does not call a cloud SaaS; it spins up a private instance of a slide-deck app just for you, running in a separate sandbox. This has two consequences: a security bug in the app cannot leak your data to others, and you are free to ask an agent to modify the code to add missing features. Gadgets are private by default and can be shared like office documents. A "Blueprint" is a template that contains the code for a whole application, so others can spin up their own copy. The experience is meant to feel like an online office suite, except each file type is potentially a custom app written by AI for your exact need.

Gatekeepers are service-specific workers that sit between a gadget or agent and an external resource. They expose a clean Cap'n Web API, handle authorization such as OAuth, enforce narrow access to exactly the resource the user intended, and log every action. For side-effectful actions, they implement a notable twist on human-in-the-loop: instead of forcing the agent to stop and wait, the gatekeeper simulates the outcome locally, lets the agent continue queueing actions, and shows the user a batch of pending approvals later. This avoids the "auto-approve everything" trap. Every gatekeeper is implemented as a separate Worker, and each package in this repo (gatekeeper-github, gatekeeper-google, etc.) contains its own setup instructions.

Cloudflare OS is built by the team behind Cloudflare Workers, and leans heavily on Durable Objects, Dynamic Workers, and Facets. Every workspace is a Durable Object, every gadget runs in a Dynamic Worker Facet, and Gatekeepers install facets into workspaces to manage remote services. The codebase maps nicely to OS concepts: packages/workshop-backend is the kernel, packages/gatekeeper-* are device drivers, packages/workshop-frontend is the shell, gadgets are processes, and blueprints are executables. Because the whole stack runs on workerd, the open source Workers runtime, it can also run on your own servers rather than only on Cloudflare's network.

To try the whole stack locally, install pnpm and run:

pnpm run-local

Then open http://localhost:8787. This runs on wrangler/workerd and is for evaluation, not production. For your own Cloudflare account, use the deploy flow at https://os.cloudflare.app/deploy. During development you can run the frontend and backend separately:

pnpm dev-server
pnpm dev-client

and visit http://localhost:3000. Once running, try prompts such as "Make a collaborative whiteboard app" or "Fix the typos in this Google Doc" (the latter requires the Google Gatekeeper to be configured).

Cloudflare OS v2 is a complete rewrite and currently an early-access release (as of August 2026). It is capable but has rough edges. The intended model is that you copy and customize it into "Your Company OS", not that you run an off-the-shelf SaaS. Running locally with pnpm run-local is not the right way to serve production; for self-hosting on workerd, documentation and tooling are still "coming soon". Many gatekeepers require obtaining OAuth credentials from each service, which providers deliberately make awkward. Also, the maintainers are not currently seeking outside code contributions: small trivially-verified fixes may be accepted, but larger PRs will likely be closed.