Hands-on: Cloudflare OS one month later — what's left of the Gatekeepers

By Ivo Donker — compiled with AI assistance · Last updated: August 8, 2026

This article is the second installment of the review genre on radar, pillar 2 of the canon: own infrastructure, homelab, and edge. The hands-on review of Cloudflare OS was published on August 6, one day after Cloudflare open sourced its internal AI work environment. That piece ended with three open points: the rejection cascades of the Gatekeepers differ per implementation without a uniform contract, the architecture for independently deployable Gatekeepers hadn't been worked out yet, and the strict observer mechanism still had to prove itself in practice. This second installment looks at what's happened since. The interim update is short: on August 7, four commits landed in the repository, and they touch two of the three points — but not the sharpest one.

The state of the code

The review described commit 5ea3bcd from August 5. The main branch is now at 1cb5e3d9 (August 7, 21:07 UTC). Between those two are four new commits, all from August 7:

Those aren't cosmetic changes, but they're not a rewrite of the security layer either. The code references from the review still hold — that's worked out per point below. Anyone who read the July edition on Cloudflare Workers for AI builders recognizes the context: this platform is one of the fastest-moving parts of the Workers stack, and the first week after open-sourcing is no exception.

The gap that still stands: the cascade contract

The sharpest finding from the review was that there's no uniform, enforceable contract for what happens when you reject a simulated action. The GitHub Gatekeeper cascades actively: rejecting a tentative action removes the dependent pending actions and returns restart: true , so the agent starts over instead of muddling through on a fiction. The Supabase Gatekeeper doesn't cascade: a rejected action simply disappears from the queue, because there's no simulation state to roll back. Both choices are defensible for their own domain, but the lack of a shared framework means that anyone writing their own Gatekeeper has to build their own dependency reasoning — or forget to.

That picture is unchanged. In the current main branch, #rejectReplyDependencyChain() is still in packages/gatekeeper-github/src/github.ts (line 1979; in the review that was line 1984 — line numbers have shifted, the code hasn't), and the restart: true that forces a restart is still there (line 3489). The cap of fifty pending actions is also still there: MAX_PENDING_ACTIONS = 50 in packages/mcp-shared/src/action-store.ts (line 11), with the rejection message for when it's full. None of the four new commits touch this contract.

Anyone who works with agent runtimes themselves knows why this matters: the cascade is where a security layer proves its predictability. The security of agent runtimes addresses exactly this question — what's an agent allowed to do, who checks afterward, and what happens on rejection — and Cloudflare OS is a concrete implementation of that. The conclusion remains: this is a design gap, not a bug fix, and a week isn't a timeframe in which design gaps close.

New: a preinstall route for ambient Gatekeepers

What is new is that the release side of the Gatekeeper architecture is becoming concrete. The review noted that Cloudflare writes that it envisions Gatekeepers deploying independently, "but the details have yet to be worked out". Commit 8a198d0a takes the first step toward that, in scripts/release/manifest-lib.mjs.

The deploy service gets a list of "ambient Gatekeepers" that it installs server-side on every fresh core deploy, without user interaction: gatekeeper-context and gatekeeper-scheduler. The requirements are hard and enforced in the code: members of that list may not ask for any input, and they may be installed at most once per instance — a second installation would give every user a duplicate ambient capsule. The manifest also shows which Gatekeepers can work without an external OAuth app (context, homeassistant, scheduler, mcp, and mcp-portal), which ones aren't installable (gatekeeper-email) and which binding is cut from customer manifests because it's still in closed beta (gatekeeper-context and its Artifacts binding; the Gatekeeper then degrades gracefully instead of failing).

For the builder with their own stack, what's especially relevant is that gatekeeper-homeassistant is in the group without third-party OAuth: anyone who fills in their own Home Assistant URL and token doesn't need a Cloudflare app. That fits with the signal from the July edition on homelab and self-hosted AI — with this component, Cloudflare explicitly targets people who connect their own services rather than integrating a ready-made SaaS stack.

The first fix to the observer mechanism

The second open point from the review was the observer mechanism, and this is the point where the first real fix has arrived. In docs/observers.md is the principle: if Bob opens a gadget shared by Alice, Bob must provide his own connected account for each Gatekeeper, and each Gatekeeper checks whether that account has sufficient permissions to read everything the gadget has ever read via that Gatekeeper. If the gadget then performs a new read action that at least one registered viewer doesn't have permission for, that action is blocked; access is rechecked on every opening. The underlying invariant is that sharing can never leak information the recipient wasn't already allowed to see.

Commit c6d8999f (August 7) fixes a situation that this strict principle produces in practice: someone receives a shared gadget whose verification needs OAuth scopes their connected account doesn't yet have. The fix expands the scopes when needed, instead of bluntly denying access. The change is in packages/workshop-frontend/src/ObserverConfigModal.tsx and has an accompanying test expansion (+114/−10 lines in the test file).

That's a reassuring direction: the mechanism isn't being weakened but made workable. It remains stricter than what most enterprise software does, and the fix is about the ergonomics of sharing, not about the security boundary itself.

The GitHub Gatekeeper is in motion, but not on the cascade

Commit 16a626df touches the file where the review found the active cascade: packages/gatekeeper-github/src/github.ts (+26/−17). The change, however, is about something else: the repository scope of GitHub issue searches. A new file is added github-search.ts and a test file (github-api.test.ts, +103 lines) covering the search handling. The storage schema is also updated with one line.

That's good news for code quality — the GitHub Gatekeeper is the only one with a serious test setup — but it also confirms the opposite of what you'd hope: the cascade logic itself hasn't been touched. Anyone wanting to see the rejection contract generalized will have to wait a bit longer.

Observability around Durable Object resets

The fourth commit, 1cb5e3d9, is about the backbone of the system. Cloudflare OS runs on Workers and Durable Objects, and this commit is an example of how much that platform is in flux. The change restores the visibility of API session aborts: since an earlier commit, ctx.abort() was replaced by a WebSocket close, causing aborts to no longer be logged as such. In addition, a tracing module is added and the overseer — the component that watches over pending actions — is made more robust on resets (+36/−15 in overseer.ts), with accompanying changes to the server configuration.

For the question from the review — what happens to a chain of ten actions if you reject step three? — this isn't an answer, but it is relevant: the system keeps better track of what gets lost in a reset and why. That's the foundation on which a future cascade contract should rest. Anyone who has ever had to debug an agentic loop knows that this kind of visibility makes the difference between a reproducible problem and a mystery.

What this means for the self-hoster

The practical route hasn't changed. The README still says that pnpm run-local is "not meant for production use", and the section "Deploy to your own server using workerd" still says COMING SOON — verified on the main branch of August 8 (HEAD 1cb5e3d9). Anyone who wants to run it seriously today deploys to their own Cloudflare account. That was the answer in the review and that remains the answer.

The repository still contains 16 Gatekeepers, of which mcp, mcp-portal, context, scheduler and email have no direct external connection; the number of real external services is around ten. The billing model remains fairly unchanged: no limit and no bill by default for self-hosted installations, and when billing is enabled, traffic runs through your own Cloudflare AI Gateway credit. For anyone who hosts an LLM gateway themselves that's still relevant: the self-hosting route isn't made artificially unattractive, and in this market that's a notable choice that holds up.

The verdict, one week later

The balance is surprisingly stable. The promise from the review — "I'll update this as soon as I know more" — has been fulfilled with this second installment. The sharpest point, the missing cascade contract, still stands exactly as it was. That's the honest conclusion: this is a design gap, and the first week after an open-sourcing isn't a timeframe in which design gaps close.

What did change is the foundation. The preinstall infrastructure makes the Gatekeeper architecture concrete, the observer mechanism got its first practical fix without weakening, and the GitHub Gatekeeper got a real test setup. Anyone who MCP-based tooling layer builds or runs agent runtimes under their own management recognizes the pattern: the value of this system isn't in one commit but in the direction the commits point to together.

What I'd like to see next is concrete: a cascade contract that generalizes the GitHub behavior (actively rejecting, forcing a restart), a test that covers rejection chains across multiple Gatekeepers, and documentation for anyone writing their own Gatekeeper. Until those three exist, the review's conclusion stands: this is a serious attempt at a third way between "being constantly interrupted" and "allowing everything", but the care still depends on whoever writes the Gatekeeper.