It'd be great if the Wrangler CLI could display the required API token permissions upfront during local dev, so you know exactly what to provision before deploying. Even better if there were something like a `cf permissions check` command that tells you what's missing or unneeded perms with an API key.

Currently you can only enforce zone-based permissions (domain based) BUT plenty of resources, such as workers, don’t belong to zones so essentially their code can be replaced or deleted with the lowest level permission. And there’s no way to block it…

Alternatively if you could please allow us to create multiple accounts that share a single super account (for SSO and such), similar to GitHub Enterprise which has Enterprises and Organisations. Then we could have ACME Corp. and ACME Corp (Prod) and segregate the two and resource groups wouldn’t be strictly required.

The cf permissions check idea from the top comment is great. One thing I've found is that agents are surprisingly good at using CLIs but terrible at diagnosing why a command failed. Clear error messages with the exact fix ("missing scope X, run cf token add --scope X") matter way more for agent usability than the happy path.

A couple of obvious questions - Is it open source (npmjs side doesn't point to repo)? And in general will it be available as a single binary instead of requiring nodejs tooling to install/use? If so, using recently-acquired Bun or another product/approach?

No long lived tokens, or at least a very straightforward configuration to avoid them.

One option: an easy tool to make narrowly scoped, very short lived tokens, in a file, and maybe even a way to live-update the file (so you can bind mount it).

Another option: a proxy mode that can narrow the scope. So I set it up on a host, then if I want to give a container access to one domain or one bucket or whatever, I ask the host CLI to become a proxy that gives the relevant subset of its permissions to the proxied client, and I connect the container to it.

No, the customers never mattered but the mythical "LLM agent" is vitally important to cater too.

I'm confused though, why isn't that tool/framework being shown here. What is it and how does it work? It is similar to the TypeSpec tool someone else posted?

Initial impression:

-h and --help should follow the short / long standard of providing more / less info. The approach currently used is -h and --help show command lists and point at a --help-full flag. The --help-full output seems to give what I'd expect on -h. This needs to be much better - it should give enough information that a user / coding agen doesn't have to read websites / docs to understand how the feature works.

Completions are broken by default compared to the actual list of commands - i.e. dns didn't show up in the list.

When I ran cf start -h it prompted to install completions (this was odd because completions were already installed / detected). But either way, -h should never do anything interactive

Some parts of the cli seem very different to the others (e.g. cf domains -h is very different to cf dns -h). Color / lack of color, options, etc.

I wish we would stop building CLIs and instead use something like this:

https://executor.sh/

https://github.com/RhysSullivan/executor

https://github.com/danielgtaylor/huma https://github.com/go-fuego/fuego

The restish tool by the author of Huma is functionally correct, but I'm finding the models are not doing a great job at inferring the syntax. Admittedly I am having a hard time following the syntax too.

https://github.com/rest-sh/restish

I need to do proper evals, but it makes me wonder if `curl` or a CLI with more standard args / opts parsing will work better.

Thanks to Cloudflare for sharing their notes, anyone else figure this out?

Please call it flare.

A very welcome development - much better for machines to the APIs - but it always would have been welcome without AI.

I have few domains on Cloudflare and when making some changes, I wish there were a way to apply the same changes to multiple domains for consistency.

CLI preview for UI action will make it possible.

I'd like the ability to create scoped, short-lived tokens from the CLI itself. There's an open GitHub issue (13042) for this.

But, there needs to be a twist: Tokens should be sociable not just by resource type, but by specific resource ID and action.

One thing I'm curious about: Cloudflare uses TypeScript for Workers and now this CLI, but Rust for the actual edge runtime. Is there a rough heuristic the team uses internally for when TS wins vs when you reach for something else?

Node, Python etc. allow arbitrary footgun tech to lose all local data. You have to use better tech.

This is only partly about the CLI and mostly about the API itself, but a straightforward and consistent way to manage environments would be nice.

I have a project using CF workers and Astro, with an ugly but working wrangler.toml defining multiple environments. When Cloudflare acquired Astro, I assumed that would be a good thing, but the latest version of the Cloudflare plugin (mandatory if you want to use the latest Astro) seems to manage environments in its own special incompatible way.

Previous-co could never get argo billing to match argo analytics, and with no support from CF over months we backed away from CF completely in fear that scale-up would present new surprise unknown/untraceable costs

Previous-previous-co is probably the largest user of web worker

it was magical

Tools should be tested and quality assured. Something that was utterly missing for cloudflare's unusable v5 terraform provider. Quality over quantity with a ux that has humans in mind!

Cloudflare is quietly rebuilding their entire developer surface with agents as the primary consumer, not humans?

If you like Rust so much, I think you should just completely refactor it.

Nobody else here ever spent years begging in pull requests for some basic functionality or bug to be fixed, and it never could be, because someone in the company decided they didn't have the time, or didn't think your feature was needed, or decided it wasn't a bug?

How about, has anyone ever had to pin multiple versions of a tool and run the different versions to get around something broken, get back something obsoleted, or fix a backwards-incompatibility?

> you can install it globally by running npm install -g cf

...I'm gonna vibe-code my own version as independent CLI tools in Go, I hope ya'll realize. Besides the security issues, besides the complexity, besides the slowness, I just don't want to be smothered by the weight of a monolith that isn't controlled by a community of users. Please keep a stable/backward-compatible HTTP API so this less difficult? And if Terraform providers have taught us anything, it's that we need copious technical and service documentation to cover the trillion little edge cases that break things. If you can expose this documentation over your API, that will solve a ton of issues.

Clearly everything is retro

Seems odd to me. I guess we all live in our bubbles.

If there is some fancy tool out there, "does it have binding for language X"? X seems to be much more commonly Python than Typescript.

Why didn't they vibe code support for more? With this on the heels of EmDash, and this being a technical preview, it feels inconsistent.

am I the only one put off with such language? they talk as if they invented compilers or assembly or Newton's law of gravity.

This scares me more than Im able to admit, typescript sucks and in my opinion its way worse than the more commonly used lingua franca of computing, which I would attribute to C. At least C can be used to create shared objects i guess?