Skip to content

CLOUDFLARE 2026-04-13

Read original ↗

Building a CLI for all of Cloudflare

Summary

Cloudflare announced a Technical Preview of the next-generation Wrangler CLI — installable today as npx cf / npm install -g cf — that aims to expose every one of Cloudflare's 100+ products and ~3,000 HTTP API operations through a single, consistent command-line tool. Simultaneously, the post reveals the machine behind the machine: a new TypeScript-based internal schema format that supersedes OpenAPI as Cloudflare's source of truth for generating CLI commands, Workers Bindings, wrangler.jsonc configuration, Terraform provider, Agent Skills, dashboard, SDK clients, and the Code Mode MCP server from a single specification. Alongside the CLI, Cloudflare released Local Explorer — a local mirror of the Cloudflare API (at /cdn-cgi/explorer/api) that lets developers introspect and manipulate the simulated KV / R2 / D1 / Durable Objects / Workflows resources that Miniflare creates during local dev, using the exact same API shapes used remotely. The bet: agents, which are increasingly the primary customer of Cloudflare's APIs, demand consistency above all — in naming (get not info), in flags (--force, --json), and in the local / remote boundary (same API shape, --local flag only difference).

Key takeaways

  1. Agents are now the primary customer of Cloudflare's APIs. The post opens with this framing explicitly: "Increasingly, agents are the primary customer of our APIs." The entire CLI overhaul is designed around agent-ergonomic output — for both CLI commands, SDKs, Workers Bindings, and Agent Skills — not just around human developers. The Code Mode MCP server fits ~3,000 operations into less than 1,000 tokens of context using code-mode compression, so the CLI must be equally context-aware. (Source: article intro.)

  2. OpenAPI schemas are not enough for a unified interface surface. Cloudflare already generates the SDKs, the Terraform provider, and the Code Mode MCP server from OpenAPI. But OpenAPI describes REST APIs only, and cannot express: interactive CLI commands that combine local development steps with API requests; Workers bindings as RPC APIs; Agent Skills; cross-interface documentation. (Source: article §"Rethinking schemas and our code generation pipeline".)

  3. TypeScript is Cloudflare's new unified interface schema. "We write a lot of TypeScript at Cloudflare. It's the lingua franca of software engineering. And we keep finding that it just works better to express APIs in TypeScript." The new internal schema format is "just" a set of TypeScript types with conventions, linting, and guardrails — but because it is owned in-house, it can be extended to any interface surface (today or future) while still generating an OpenAPI schema as an output, not an input. This is the same conceptual move Cloudflare made in Cap'n Web and Code Mode: prefer TypeScript's native type system to alternative schema DSLs. (Source: article §"Rethinking schemas".)

  4. Enforce consistency at the schema layer, not at review time. Manual code review cannot catch convention drift across a large engineering org with hundreds of people and 100+ products — it is "Swiss cheese". The new schema bakes in hard rules: always get, never info; always --force, never --skip-confirmations; always --json, never --format; and --json must be available everywhere. Agents that learn one command pattern can call the same pattern on any other resource and it will exist. This is the core of concepts/cli-convention-enforcement and is captured in patterns/schema-driven-interface-generation. (Source: article §"Agents and CLIs — consistency".)

  5. Local / remote parity is enforced at the API layer, not the CLI layer. Wrangler is unusual in that the same commands can target simulated local resources or remote resources. If local and remote have divergent shapes, agents get confused ("agent thinks it's modifying a remote database, but is actually adding records to local"). The fix: Local Explorer exposes a local mirror of the Cloudflare API at /cdn-cgi/explorer/api on any Wrangler or Vite-plugin-powered app. Same endpoints, same shapes, same OpenAPI schema — only difference is the --local flag and that requests go to a local HTTP server instead of Cloudflare's edge. Agents can be pointed at the local endpoint and manage local resources "just by talking to your agent". Named in concepts/local-remote-parity and patterns/local-mirror-of-remote-api. (Source: article §"Local Explorer".)

  6. Local Explorer is a new introspection UI for Miniflare state. For years Miniflare (Cloudflare's local-dev emulator, same Workers runtime as production, local SQLite for D1, local on-disk state for KV / R2 / DO / Workflows) has made offline local dev possible, but the state was opaque: developers had to reverse-engineer .wrangler/state or install third-party tools. Now wrangler dev (and the Cloudflare Vite plugin) prompt the developer to open Local Explorer with keyboard shortcut e — a GUI showing bindings and stored data, with schema-verification / seed / drop-table workflows. Particularly pitched at agent-development workflows ("understand what the agent is doing with data"). (Source: article §"Local Explorer".)

  7. Technical preview, not production. Cloudflare is explicit: cf today covers only a small subset of products; a version covering the full API surface is in internal testing. The post is an early-feedback vehicle — Cloudflare asks developers in the Developers Discord to name commands they want, config fields (DNS records, Cache Rules) they want in wrangler.jsonc, and workflows where agents got stuck. Over the coming months, this will merge with the existing Wrangler CLI. (Source: article §"Tell us your hopes and dreams".)

  8. The Local Explorer API is already shipped as open-beta today — available on any existing Wrangler or Vite-plugin project at /cdn-cgi/explorer/api, including an OpenAPI spec at that URL that agents can discover and consume directly. This is the first production-grade piece of the new machine to ship publicly. (Source: article §"Local Explorer".)

Systems / concepts / patterns extracted

Operational numbers

  • ~100+ Cloudflare products.
  • ~3,000 HTTP API operations, all in the Code Mode MCP server.
  • <1,000 tokens — Code Mode MCP server total context footprint (see blog.cloudflare.com/code-mode-mcp).
  • 1 OpenAPI schema was previously the code-gen source → 1 unified TypeScript schema is the new source → many interfaces generated (CLI + SDK + Terraform + Workers Bindings + MCP + Agent Skills + docs + dashboard).
  • Keyboard shortcut e opens Local Explorer during wrangler dev.

Caveats

  • Technical preview, not GA. Only a small subset of products has CLI commands today. Do not plan production adoption on current cf output.
  • Product-marketing adjacent. The post is partly a dogfooding / feedback call for Cloudflare's developer platform; treat CLI-consistency claims as aspirational until the schema-layer guardrails are observable in OSS form.
  • No public details of the TypeScript schema format itself — only the fact that it exists and what it covers. Expect future posts with the schema DSL details.
  • Open-beta Local Explorer is a developer-facing mirror only — it runs against local SQLite / on-disk state, not any real customer data, and is bounded by Miniflare's local-simulation fidelity.

Source

Last updated · 200 distilled / 1,178 read