Cloudflare cf CLI: 3,000 API operations built for agents

The Cloudflare cf CLI shipped in open beta on 28 September 2026 with over 3,000 API operations, generated from Cloudflare's OpenAPI schemas, against roughly 280 command paths in Wrangler. Install it with npm i -g cf. The number is not the interesting part. The interesting part is that the command surface is no longer a boundary, and the token's scope now is.

Below: how cf was built, the authentication model the launch post does not cover, and the review discipline we apply before an agent is allowed to run infrastructure commands against a client account.

What the Cloudflare cf CLI is, and where 3,000 operations came from

Wrangler was hand-built, product team by product team. Cloudflare is blunt about the result: enforcing patterns across teams was virtually impossible across its ~280 command paths, leaving inconsistent terminology such as d1 info, hyperdrive get and workflows describe for the same shape of operation.

cf is generated instead. Forge, Cloudflare's unified API generation pipeline, builds the CLI from the same OpenAPI schema that powers the API documentation and SDK generation, with a little extra annotation. That is how the tool covers what Cloudflare calls the entirety of the Cloudflare API surface of over 3,000 operations rather than the subset somebody wrote a command for.

Four design choices follow from being generated for agents rather than written for people:

• JSON by default — pretty printed for humans, condensed for agents. Wrangler required --json per command, and many commands returned Unicode tables instead.
• TypeScript configuration — cloudflare.config.ts replaces TOML, which had no accessible schema, and JSONC, whose linked schema agents rarely used. Helpers such as bindings and triggers are discoverable through the editor's language server.
• Natural-language discovery — cf cli search lets an agent describe what it needs and get back matching commands, and cf advertises the command automatically the first time an agent runs --help.
• Vite by default — the Cloudflare Vite plugin replaces the esbuild pipeline Wrangler grew up on.

Cloudflare reports that some internal Wrangler configuration files, previously over 5,000 lines with a custom environment block per developer, condensed by 40% once environments were defined programmatically from one base.

Agents were already 48% of Wrangler use

This is not a bet on a future workflow. Cloudflare reports that agents were responsible for a quarter of Wrangler use in March 2026, up from single-digit percentages the year before, and that agent usage reached 48% in the week before launch. Agents also use almost twice as many distinct commands per day as humans, and are almost four times as likely to use six or more commands.

Put those together and the design brief writes itself: the tool's primary user already reads JSON, already chains commands, and already needs to discover operations it has never seen.

The auth model the launch post skips

The announcement says nothing about authentication, which is the part that matters most once an agent is the one typing. The source of the CLI answers it. cf auth login starts an OAuth flow, with device authorisation as the default and --no-device selecting the localhost callback flow instead. --scopes requests a specific set of OAuth scopes, and the CLI rejects scope names it does not recognise. After login it prints the granted scopes and the token's expiry; cf auth whoami prints the auth source, whether the token still validates, the accounts it can reach and the full scope list.

Two details are worth pinning down before you roll this out. First, the CLOUDFLARE_API_TOKEN environment variable takes precedence over the stored OAuth token, and cf does not support the legacy global API key at all — scoped tokens only. If the variable is set, cf auth login refuses to start and tells you to unset it, and profile management is blocked outright.

Second, cf has named auth profiles: cf auth create <name> authenticates one, and cf auth activate <name> binds it to a directory. A profile attached to a working directory is the most useful primitive in the whole tool for anyone running agents, and almost nobody will notice it exists.

One known rough edge, as of September 2026: an open issue reports the device flow failing from datacentre IPs, because requests to dash.cloudflare.com return a managed challenge. Headless agents on a server therefore fall back to CLOUDFLARE_API_TOKEN — which, given the precedence rule above, is a decision about identity rather than a workaround.

Why 3,000 operations changes the review problem, not just the tooling

With Wrangler, the command surface was an accidental control. If no command existed for an operation, an agent either stopped or wrote a raw API call — and a raw API call in a diff is conspicuous. cf removes that accident. Every operation Cloudflare exposes is now one search away from an agent that has never used the tool.

The strongest counter-argument is that this was never a real control. An agent holding a token could always curl the API directly, less legibly and without a log line naming the operation. That is correct, and cf genuinely improves on it: named commands, consistent JSON, telemetry classification per command. The conclusion is not that cf is riskier than Wrangler. It is that the control has to sit somewhere else, because it was never sitting in the CLI — and agents route around controls that depend on a capability simply being absent.

The permission discipline we apply to agent-run infrastructure

This part is ours, not Cloudflare's. Across the DevOps and cloud engineering work we do, these are the rules we put in place before an agent gets a Cloudflare credential:

1. The agent gets its own profile, never a human's session. Create a named profile, activate it in the checkout the agent works from, and let a production operation fail on scope rather than on the agent's judgment.
2. Read-only by default. Most agent work is diagnosis. A token scoped to reads covers it, and an agent that needs write access should have to ask for a different profile.
3. Prefer a config change to a live mutation. cloudflare.config.ts is TypeScript in your repository, so a change to it is a reviewable diff before anything deploys. An operation issued straight at the API leaves no diff — only an audit entry someone has to go looking for. Where both routes exist, take the one that produces a pull request.
4. Name the irreversible operations explicitly. Deleting a zone, buying a domain, rotating a credential, editing a WAF or Access policy. Put them in the harness allowlist as exceptions requiring a human, rather than trusting the model to be cautious about them.
5. Keep the JSON. Output is structured by default, so store it with the change record. It is the cheapest audit trail you will ever get.
6. Never export an account-wide write token in a shell profile. Because the environment variable outranks OAuth, it silently becomes the identity for every cf invocation on that machine, including the ones you did not intend to run as an administrator.

None of this is Cloudflare-specific. It is the same discipline any generated, full-surface CLI will demand, and cf is unlikely to be the last one.

Does cf replace Wrangler?

Not yet, and not automatically. Cloudflare's own guidance is to keep using Wrangler in projects that already have a wrangler.toml, wrangler.json or wrangler.jsonc unless you deliberately migrate with cf migrate. Workers that already build with Vite convert to cloudflare.config.ts; Workers that depend on esbuild, and Rust and Python Workers, still have their builds and deploys delegated to Wrangler.

When the open beta ends, Cloudflare says it will ship a final major Wrangler version that points you and your agent at cf, and maintain Wrangler for 18 months after that. That is a reasonable window, and it is also the reversibility question in miniature: the cost of moving is low now and rises with every configuration file you leave behind.

Our advice for the next fortnight is narrow. Migrate one low-risk Worker, not the estate — the same way you would approach any change to a deployment path, where the failures worth learning early show up in the second week rather than the first. Then, before anyone installs cf org-wide, decide who holds which token, and run cf auth whoami to see the scopes you actually granted rather than the ones you assume you did.