A CLI built for the whole platform
Cloudflare’s API surface is enormous—over 100 products and nearly 3,000 HTTP operations—and agents are increasingly the primary consumers of that surface. Developers bring coding agents to build applications, deploy Workers, configure accounts, and pull analytics. To serve those agents everywhere they operate, Cloudflare wants every product available through every interface: the MCP server, SDKs, Terraform, config files, and the Wrangler CLI. That last one is the gap.
Wrangler today has commands for only a subset of Cloudflare products. Many have no CLI presence at all. Cloudflare is rebuilding Wrangler into a CLI for the entire platform, and today is sharing a technical preview of what that future looks like. You can try it with npx cf or install it globally with npm install -g cf.
The preview covers just a small subset of products for now. A version supporting the entire Cloudflare API is already being tested, with commands reviewed product-by-product for ergonomics aimed at both agents and humans. Over the coming months, this work will merge with the existing Wrangler commands developers already rely on.
From OpenAPI to a TypeScript schema
Cloudflare already generates its API SDKs, Terraform provider, and Code Mode MCP server from the OpenAPI schema. But the CLI, Workers Bindings, wrangler.jsonc configuration, Agent Skills, dashboard, and docs were still updated manually—error-prone and too slow to scale across the full API.
OpenAPI describes REST APIs well, but falls short for interactive CLI workflows, local development commands, RPC-style bindings, and the documentation tying them together. Cloudflare’s answer is a new TypeScript schema format: a set of conventions, linting, and guardrails that can express the full scope of APIs, CLI arguments, and context. Being TypeScript-native, it can be adapted to any interface, while still generating OpenAPI when needed.
The work so far has focused on this foundation—the generation machine itself—so that building the CLI and other interfaces on top becomes tractable. That enables a broader goal: standardizing context for agents.
Consistency as a schema-level guarantee
Agents expect CLIs to behave predictably. If one command uses <command> info and another uses <command> get, an agent will try the wrong one. Manual review can’t enforce consistency across hundreds of engineers and dozens of products, and enforcing it only at the CLI layer creates mismatches with the REST API and SDKs.
The new schema layer enforces conventions directly. It’s always get, never info. Always --force, never --skip-confirmations. Always --json, never --format—and that flag is always supported.
Wrangler also occupies an unusual position: its commands and config can operate on both simulated local resources and remote ones, like D1 databases, R2 buckets, and KV namespaces. Consistent defaults matter even more when an agent might think it’s writing to a remote database but is actually hitting a local one. Output must clearly signal whether a command targets remote or local state, so agents never operate on the wrong copy of the data.
Local Explorer: a local mirror of the Cloudflare API
Alongside the CLI preview, Cloudflare is releasing Local Explorer in open beta for both Wrangler and the Cloudflare Vite plugin. It lets developers inspect the simulated resources a Worker uses during local development—KV, R2, D1, Durable Objects, and Workflows—and manipulate them exactly as they would via the Cloudflare API or dashboard, but entirely offline.
Local development has long been a bet for Cloudflare. Miniflare gives Workers the same runtime APIs locally as in production, backed by a local SQLite database. Until now, however, inspecting what was actually stored locally meant digging into the .wrangler/state directory or installing third-party tools. Local Explorer closes that gap.
Running an app with Wrangler or the Vite plugin now prompts you to open the explorer with the e keyboard shortcut. It shows which bindings your Worker has attached and what data is stored against them. For agent-driven development, it’s a way to see what the agent is doing with data: verify a schema, seed test records, or reset state with a DROP TABLE.
Underneath, Local Explorer exposes a mirror of the Cloudflare API that only touches local data. Since the API shape matches the remote one, CLI commands with a --local flag work identically—they just hit this local endpoint instead. The API is available at /cdn-cgi/explorer/api on any Wrangler- or Vite-powered app; pointing an agent at that address gives it an OpenAPI spec for managing local resources.
What comes next
With the generation machinery in place, the work now is combining the best of today’s Wrangler with the new capabilities. The technical preview is the starting point for that conversation.
Cloudflare is asking for input on what’s missing: which dashboard workflows should be one-line CLI commands, what should be configurable in wrangler.jsonc (DNS records, Cache Rules), and where agents get stuck for lack of a CLI command. Feedback lands in the Cloudflare Developers Discord.
