Cloudflare announced a technical preview of cf, a new unified CLI, and Local Explorer, a local inspection tool for simulated runtime resources. Both are available now via npx cf, with plans to eventually fold the work into the existing Wrangler CLI.
The core idea: a single TypeScript-based schema model that standardizes access to roughly 3,000 Cloudflare API operations for human developers and AI agents alike.
What Cloudflare Shipped
The release has two connected pieces.
cf is a unified CLI built on a new TypeScript-based schema. Rather than hand-modeling each API endpoint separately, the CLI is generated from a structured source of truth. That keeps commands and their outputs consistent across Cloudflare's broad API surface.
Local Explorer is an introspection tool for local development. It lets developers inspect simulated resources, specifically KV and D1 databases, while running code locally. Cloudflare's local-development ecosystem relies on emulating cloud resources during iteration, and Local Explorer gives users a direct way to see what those emulated environments actually contain.
Both features are in technical preview. Cloudflare has said the tools are expected to integrate into Wrangler over time, which suggests cf is an experimental layer that could shape the future of the more established CLI rather than replace it outright.
Why the Schema Matters
The TypeScript-based schema is the architectural signal worth watching. If the CLI is driven by a single structured definition, both interactive commands and automated tooling can consume the same contract. For developers, that means more predictable inputs and outputs. For AI agents, it means a machine-readable surface that is easier to discover and validate.
Cloudflare has been moving in this direction across other product surfaces. A February 2026 changelog entry described how wrangler types now generates schema-specific TypeScript types for Pipeline bindings, replacing older generic types. That update caught missing required fields and incorrect types at compile time rather than letting schema mismatches surface later as dropped events.
The same philosophy is visible in cf: define the structure once, then let tools, editors, CLIs, and agents consume it consistently.
A separate detail from Cloudflare's workers-sdk repository points to ongoing work exposing a Local Explorer OpenAPI spec at /cdn-cgi/explorer/api. That is a signal. OpenAPI exposure makes a tool easier to automate, document, and ingest by other tooling, including agent workflows. It suggests Local Explorer is being wired as a formal API surface, not just a convenience layer.
Why Local Explorer Matters
Developers building on Workers, KV, and D1 often hit a visibility gap during local runs. Code executes against simulated resources, but checking what the emulated environment actually contains can mean relying on manual log inspection or guesswork.
Local Explorer reduces that gap. If a worker writes to KV locally, Local Explorer can make that state visible directly. For D1, developers can check database state in local runs without deploying first.
For automated tooling, the benefit is significant. Agents need structured context more than intuition. A queryable local environment gives an agent a way to understand what the runtime contains before proposing changes.
What Comes Next
Several practical questions remain open. Cloudflare has not detailed which of the 3,000 API operations are exposed first, how authentication will evolve beyond the preview, or which additional resources Local Explorer will support at general availability. The timeline for Wrangler integration is also unspecified.
What is clear is the direction. Cloudflare is converging on a pattern: model APIs in a structured schema, expose those structures to local tooling, generate type-safe interfaces for developers, and make the same surface accessible to automation. The typed Pipeline bindings, the OpenAPI work in workers-sdk, and now cf all point the same way.
The question for developers building on Cloudflare is how much of the platform's tooling becomes schema-first and agent-readable from here, and how quickly that work lands in Wrangler.
