What this is and is not. A first look, written one day after the release, based on the repository and a local install at commit 5ea3bcd. It is not a long-term verdict — that takes months in production. Where I could not test something, I say so.
The short version
Gatekeepers solve the human-in-the-loop problem in a genuinely new way: instead of blocking the agent while it waits for your approval, the Gatekeeper simulates the outcome so the agent keeps working, and you approve in bulk later. That is a real answer to why so many people end up running --dangerously-skip-permissions.
The obvious follow-up question: if an agent builds ten steps on simulated outcomes and you reject step three, what happens to steps four through ten?
The documentation does not answer that centrally. The source does — per Gatekeeper, and they do it differently. That is the finding.
What Cloudflare OS is
It is the workspace Cloudflare uses internally — according to their own documentation, across a large part of the workforce, from engineering to sales. "Operating system" here means two things: a system for a company to be productive with AI safely, and a system that manages AI workloads the way a traditional OS manages processes.
Three parts: an agent chat environment preloaded with knowledge of how your company works, a sandbox in which agents build small applications, and a security layer called Gatekeepers. Apache 2.0, and the code is genuinely there.
pnpm run-local.Gadgets: everyone runs their own copy
Create a slide deck and you are not calling a SaaS service. The system spins up a private instance of the slide deck software, for you alone, in its own sandbox. Cloudflare calls these "gadgets".
Two consequences they point out themselves. The slide app cannot leak your slides to an attacker, because the sandbox controls all access. And you may freely modify the code of your copy — if a feature is missing, you ask your agent to add it. That is safe precisely because it is your own instance.
Gatekeepers and asynchronous approval
A Gatekeeper sits between an agent and an external service — GitHub, Google, Slack, Notion, Linear. It handles OAuth, exposes a cleaned-up API, narrows access to exactly the resource you intended, and logs every action. Cloudflare describes them as "supercharged MCP servers", which is fair.
The interesting part is approvals. Classic human-in-the-loop is synchronous: the agent wants to act, stops, and waits for you. You hand over a task, walk away, come back and find it stalled on step one. That is exactly why people give in and enable auto-approve.
Cloudflare's answer: the Gatekeeper simulates the outcome locally. The agent is told the action succeeded, receives simulated results if it reads back, and continues. The real actions queue up. You approve or reject afterwards, in bulk or one by one, whenever it suits you.
That is a real advance, and it is the kind of idea you only get after running into the problem yourself.
Where it gets interesting
Simulation means the agent is building on an outcome that does not exist yet. One action is manageable. Ten is a different matter — and the answer lives in the code, not the docs.
The GitHub Gatekeeper cascades. packages/gatekeeper-github/storage-schema.md (line 158) states it plainly: rejecting a provisional create deletes dependent pending actions and returns restart: true. The implementation is #rejectReplyDependencyChain() in src/github.ts (line 1984) and it is a real breadth-first graph walk — a queue of comment ids, a seen set against cycles, and for each rejected reply the replies to that get pushed back onto the queue. It is called when rejecting a review with diff comments (line 3484) and a standalone reply (line 3486).
That restart: true is the honest part. The system admits the agent was building on fiction and forces a restart rather than muddling through.
The Supabase Gatekeeper does not cascade, and says so. packages/gatekeeper-supabase/src/supabase.ts (line 1105), in a comment: rejected means discard the queued statement, there is no simulation state to roll back.
Both choices are defensible for their own domain. The point is that there is no uniform, enforceable contract for rejection cascades across Gatekeepers. And writing your own Gatekeeper is exactly what Cloudflare encourages. Whoever does that builds their own dependency reasoning — or skips it, and nothing stops them. For a security layer whose value rests on predictability, that is the sharpest note I have.
One thing that tempers the doomsday scenario: there is a ceiling. packages/mcp-shared/src/action-store.ts sets MAX_PENDING_ACTIONS = 50, and above that the store refuses new actions with a message that fifty calls are already awaiting approval. The fiction cannot grow indefinitely. But fifty deep is plenty to make the problem real, and that ceiling protects the store more than the user.
The observer mechanism
Share a gadget and the system checks whether that person already had access to everything the gadget has ever read through a Gatekeeper. If not, no access. It keeps applying: any new read the gadget makes that a registered observer lacks privileges for is blocked, and access is re-checked every time they open it.
The invariant is that sharing can never leak information the recipient was not already entitled to see. That is stricter than most enterprise software, where sharing means the recipient sees what is in the document, full stop.
The business model, and why it stands out
Documented in docs/ai-gateway-billing.md, and largely absent from the coverage.
Billing is off by default. Leave ENABLE_CLOUDFLARE_LIMITS unset and usage is unlimited — as intended for self-hosted deployments. Turn it on and each user gets a free daily allowance of LLM calls (default 100 per UTC day); beyond that, usage bills to that user's own Cloudflare AI Gateway credits. A connected account with at least $2 balance routes through their own account immediately, leaving their free allowance untouched. Top-ups happen in your own Cloudflare dashboard. From their docs, verbatim: the platform never holds money.
No markup, no intermediary account, no subscription layer owed to the party supplying the software. Cloudflare earns because the traffic runs on their infrastructure — not by taking a margin on your model usage.
Running it yourself
Install pnpm, then pnpm run-local, then visit localhost:8787. That worked without detours. Cloudflare states explicitly that this is not meant for production.
Running it as a LaunchAgent makes "rough edges" concrete: the error log fills with Flagship binding missing; using default values from the feature-flag layer. Nothing breaks, but it is a visible reminder that you are running a piece of internal Cloudflare infrastructure of which some parts simply do not exist at your house.
The repository contains 16 Gatekeepers: cloudflare, confluence, context, email, github, google, homeassistant, linear, mcp, mcp-portal, notion, scheduler, slack, spotify, supabase, zoominfo. Note the nuance: mcp and mcp-portal are generic pass-throughs, and context, scheduler and email are internal services — so connectors to genuinely external services number closer to ten. Two stand out: Home Assistant and Spotify.
Before you get excited
| Point | What it means |
|---|---|
| Early access, their words | Cloudflare calls the August release "very capable, but still has many rough edges". This is v2, a full rewrite of v1. |
| Local ≠ production | The run-local route is explicitly not production-grade. |
| Gravity points at Cloudflare | Apache 2.0 and the code is yours, but "deploy to your own server using workerd" is still marked COMING SOON in the README — documentation and tooling are not there yet. Today, running it seriously means deploying to a Cloudflare account. |
| Docs partly AI-written | docs/observers.md states outright that most of it is AI-written and may go stale. Honestly flagged, but do not lean on it. |
| Gatekeeper architecture unfinished | Each Gatekeeper is a separate Worker. Cloudflare envisions deploying them independently, "but the details have yet to be worked out". |
| No uniform cascade contract | Rejection cascades are per-Gatekeeper and differ. Write your own and you build that reasoning yourself — or forget it. |
Verdict, provisionally
Their own framing is the strongest line in the project: the idea is not that your company uses Cloudflare OS, but that you make it Your Company OS. The licence, the code and the billing model all back that up.
Asynchronous approval by simulation is the idea that sticks. Anyone running agents with real permissions knows the dilemma between constant interruption and allowing everything. This is the first serious third way I have seen.
Whether it holds depends on something currently solved per Gatekeeper. The GitHub implementation shows how it should be done, including the honesty of forcing a restart when the assumption did not pan out. What is missing is a framework that enforces that care on everyone writing their own. That is not a design flaw but a gap still to be closed, and for an early-access release it is an entirely reasonable place to stand.
Updated as I learn more. Written 6 August 2026, one day after open-sourcing, against commit 5ea3bcd. Code references hold for that commit; line numbers may shift in later versions.
Frequently asked questions
Can you self-host Cloudflare OS?
Not fully yet, and this is the answer most coverage misses. Running it locally works with pnpm run-local, but Cloudflare says that is not meant for production. The route for deploying it on your own server using workerd is still marked COMING SOON in the README — documentation and tooling are not there. Running it seriously today means deploying to your own Cloudflare account.
What is Cloudflare OS?
The AI workspace Cloudflare uses internally, open-sourced on 5 August 2026 under Apache 2.0. It combines an agent chat environment, a sandbox in which agents build small applications called gadgets, and a security layer called Gatekeepers.
Is Cloudflare OS free?
Yes. The code is Apache 2.0 and billing is off by default, so a self-hosted install has no limit and no bill. Enable billing and each user gets a free daily allowance of LLM calls (default 100 per UTC day), after which usage bills to that user's own Cloudflare AI Gateway credits. From the documentation, verbatim: the platform never holds money.
What are Gatekeepers in Cloudflare OS?
A secured wrapper between an agent and an external service such as GitHub, Google or Slack. It handles OAuth, narrows access to exactly the intended resource, logs every action, and offers asynchronous approval: the Gatekeeper simulates the outcome so the agent keeps working, and you approve in bulk afterwards. The repository contains 16.
How do you install Cloudflare OS locally?
Install pnpm, run pnpm run-local in the repository, and open http://localhost:8787. The whole stack runs locally on wrangler and workerd, with data in a .wrangler subdirectory.
