GitHub - cloudflare/cloudflare-os: Agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company’s context and systems.

Cloudflare OS: An AI productivity environment Cloudflare OS is an "operating system" for AI productivity originally developed for use inside Cloudflare. A large portion of Cloudflare's workforce -- from engineering to sales and everything in between -- uses Cloudflare OS every day to help them do their jobs. This is not a traditional computer operating system. We use the term "operating system" in two senses: An operating system for the company to be productive with AI, in a way that is safe, so that the security team can sleep at night. An operating system for AI workloads, analogous to the sense in which a traditional operating system manages compute workloads. Cloudflare OS provides three things in particular: An agent chat UI where you can ask agents to do tasks, preloaded with knowledge about how your company operates. Sandboxed application development, so that you can ask agents to build "gadgets" (small personal apps) and safely share what you've built with others. A security framework, called Gatekeepers, that applies guardrails to both agents and apps such that non-technical users can safely "go nuts" and nothing bad will happen. We are making Cloudflare OS open source so that others can copy it and customize it for their own company. The idea is not that your company uses Cloudflare OS, but rather that you make it "Your Company OS". Quick Start To quickly run Cloudflare OS locally, install pnpm, then do: pnpm run-local Then visit: http://localhost:8787 This runs the whole stack locally on wrangler and workerd. This is not meant for production use, but is a quick way to see what the product does. Alternatively, you can deploy to your Cloudflare account. (More options at the end of this readme.) What to try Try prompts like: "Make slides for my upcoming meeting with a customer." (This will use the built-in slides blueprint.) "Make a collaborative whiteboard app." (This will create a new app from scratch.) "Make a tic tac toe game." followed by "I'll be X and you be O. I've made my first move. Your turn." "Make an issue dashboard for this GitHub repo." (Attach a repo; requires that the GitHub integration is configured.) "Fix the typos in this Google Doc." (Attach a doc; requires that the Google integration is configured.) WARNING: Early access Cloudflare OS is in a state of heavy development. This repository is actually version 2, a complete rewrite taking what we learned from version 1 and putting it on a new foundation. As of the August 2026 release, Cloudflare OS v2 is very capable, but still has many rough edges. We know, and we're working on it. For now, consider this an "early access" release. Overview: What is Cloudflare OS really? Gadgets: A new way of thinking about software Cloudflare OS is more than just another chatbox with connectors. The system revolves around a new approach to software, where every user runs their own copy of the productivity apps they use. When you create a slide deck in Cloudflare OS, you are not calling out to some SaaS software running in the cloud. The system creates a private instance of the slide deck software just for you. We call this a "gadget". This instance runs in a separate sandbox from everyone else's slide decks. This has two profound effects: It's impossible for the slide deck app to have a security bug that leaks your slides to an attacker. The Cloudflare OS sandbox controls all access to your private instance of the app. If you want, you can freely modify the code. If the slide deck app is missing a feature you need, you can just ask your agent to add it. And because of point 1, it's totally safe to do so. This is a big departure from the last 25 years of cloud architecture and "Software as a Service", but we think AI has changed the equation. When any user is capable of prompting an agent to add the features they need, the centralized model of software stops making sense. Gatekeepers: A capability-based security layer Gatekeepers are like supercharged MCP servers. When you introduce an agent or Gadget to an external resource, a Gatekeeper is created to manage that access. The Gatekeeper is a piece of software specific to each external service which moderates a Gadget's connection to that service. It: Provides a clean Cap'n Web API to the service (wrapping whatever API the service provides natively). Handles authorization (e.g. via OAuth). Enforces narrow access to only the specific resource the user intended. Logs every action the Gadget (or agent) performs, for your review. For any action which has side effects, provides the human user an opportunity to approve or deny the action ("human in the loop"). On the last point, Gatekeepers implement a significant advancement in the state of the art. Traditionally, human-in-the-loop setups require the human to approve actions synchronously. When the agent wants to do something, it has to stop and wait for said approval before it can continue. This is annoying: you give your agent a task, then walk away and get a coffee, only to come back and find the agent got stuck on an approval on the first step and has made no progress. As a result, people often give in and set their agents to "auto-approve", or --dangerously-skip-permissions, which is, obviously, unsafe. Gatekeepers provide a better way: When the agent (or Gadget) performs an action that requires approval, the Gatekeeper will simulate the outcome locally, allowing the agent to proceed and queue up more actions. The Gatekeeper tells the agent that the action completed, and if the agent tries to read back the results, the Gatekeeper gives it simulated results. Once the agent is done, the user may approve or reject the actions in bulk, or one-by-one, but either way, they can do it later, when it is convenient. Logistically, each Gatekeeper is implemented as a separate Worker. In the future, we envision Gatekeeper services being deployed and maintained independently from OS instances, but the details have yet to be worked out. For now, we have provided a few interesting Gatekeepers in this repository which you can deploy together with your own OS instance. Think of an office suite The basic user experience of Cloudflare OS is something like an online office suite, like Google Docs or MS Office. But, imagine that instead of a fixed set of file types (document, spreadsheet, slide deck), each file -- or "Gadget" -- is potentially its own custom application, written by AI to serve exactly your needs. Just like office docs, each gadget is private by default, but can be shared -- securely -- in order to collaborate with your team or your friends. Just like office docs, you can have thousands of them. You can create them on a whim. Just like office docs, you can start from "templates" -- called "Blueprints". But where an office template is just some content, a Blueprint specifies a whole application. Like office docs, you can create new templates (blueprints) from your own docs (Gadgets) and share them with others. But when you do so, you are sharing the code for a whole app. It kind of is an Operating System The OS terminology isn't entirely marketing. Cloudflare OS is actually analogous to an operating system on a technical level. Normal OS Cloudflare OS kernel packages/workshop-backend device drivers packages/gatekeeper-* shell packages/workshop-frontend processes gadgets executables blueprints users users ACLs shared permissions ??? agents Our "kernel" is in the workshop-backend package. The backend legitimately does a lot of things similar to real OS kernels: it connects users to programs and devices (Gadgets and Gatekeepers, as we call them) while implementing security by sandboxing applications and enforcing access control. In this analogy, Gatekeepers -- which connect users and agents to external services -- are like drivers -- which connect users and programs to external devices. There is one thing that traditional OSes don't really manage today, but Cloudflare OS does: AI agents. If you think about it, this is really a missing feature in traditional OSes. We believe that AI agents cannot simply be treated as users. They must be accountable to a human user, while at the same time having their own restricted permissions. Agents do work by writing snippets of code and executing them on the fly. The ideal security model for all of this is capability-based security, not access control lists. See what I mean? Perhaps traditional OSes ought to give AI agents special treatment, too. Built on Workers, by the Workers team Cloudflare OS is built on Cloudflare Workers, making heavy use of Durable Objects, Dynamic Workers, and Facets in particular. Every workspace is its own Durable Object, every Gadget runs in a Dynamic Worker Facet, and Gatekeepers also install facets into each workspace to manage access to remote services. Cloudflare OS is, in fact, built by the very people who built Workers itself. It uses cutting-edge features of the Workers Runtime -- in fact, Dynamic Workers, Facets, and several other features were added to the runtime specifically to support Cloudflare OS, with more to come. Studying the Cloudflare OS source code is a great way to understand how the Workers Runtime team thinks Workers should be used. Being built on Workers does not mean that Cloudflare OS can only run on Cloudflare. In fact, workerd, the Cloudflare Workers Runtime, is itself open source, and Cloudflare OS can run entirely on top of it on your own servers. Features General multi-purpose agent The Cloudflare OS coding agent is actually a fully multi-purpose agent that can perform arbitrary tasks; like other popular coding agents, you don't have to code with it. You can use it to build Gadgets, but you can also skip the Gadget and just have the agent perform tasks directly. The Cloudflare OS agent is a Code Mode agent -- it performs tasks by writing and immediately executing snippets of code. It can be connected to external resources using Gatekeepers (like MCP -- see below).