On 22 August 2026 Cloudflare switched on fine-grained OAuth consent for Wrangler and for its API MCP server. Authorizing the tool used to mean accepting every requested permission at once; it is now possible to grant only a subset, bringing command-line tooling closer to the principle of least privilege.
What optional consent changes
The classic OAuth model was all-or-nothing: the consent screen listed the scopes a client asked for, with no choice beyond approve everything or deny everything. The update splits scopes into required ones, pre-selected and non-dismissible, and optional ones, which a user can decline before confirming. The issued token then carries only the permissions actually granted.
In practice, the authorization dialog now shows an “Edit permissions” button that opens the list of optional scopes. Unchecking a scope shrinks the token’s reach by that much. If a command later needs a declined permission, reauthorizing the client adds it.
| Requested scope | Classification | What it allows |
|---|---|---|
user-details.read | Required | Read the account profile |
zone.read | Required | Read zone configuration |
workers-scripts.write | Optional | Deploy Workers |
workers-kv-storage.write | Optional | Write to KV namespaces |
Watch out: applications consuming these tokens must handle partial grants. After the exchange, check the scopes actually present in the token instead of assuming that everything requested was granted.
How a scope becomes optional
The classification happens on the OAuth client developer’s side, in the Cloudflare dashboard: each configured scope can be marked required or optional. By default all remain required, preserving existing behaviour. The required/optional split is evaluated only against the scopes actually requested in a given authorization flow, not the full configured set; if no optional scope is requested, the consent screen is unchanged. The feature is available from Wrangler 4.116.
# Ré-autoriser Wrangler en n'accordant qu'un sous-ensemble de scopes
npx wrangler logout
npx wrangler login
# → l'écran de consentement propose « Edit permissions »
# décochez les scopes optionnels dont le workflow n'a pas besoin
# Si une commande échoue faute de permission, ré-autoriser pour ajouter le scope
npx wrangler login # cochez cette fois le scope manquantWhy this matters for agents and MCP
The point reaches beyond a developer running wrangler deploy. Cloudflare explicitly names MCP servers, which expose tools to agents. Such a server tends to request a broad permission set, since in theory an agent could use all of them; in practice, few users want an agent to hold that much access. Optional scopes let you grant an agent the bare minimum, without the server’s author having to build a custom permission-selection interface.
A token that can only write to Workers can neither purge a cache nor read a DNS zone.
The logic fits a wider shift in how access is delegated to agents: shrink the blast radius of a compromised token, and make legible, at consent time, what an automated tool will be able to do. It extends questions already raised by the rise of the MCP protocol.
What to take away
The change is quiet but structural: it moves Wrangler and MCP-server authorization from a binary model to an adjustable grant. For teams, it is a chance to review the tokens handed to integrations and agents, and to grant only what a workflow genuinely needs. Adoption cost is nil on the user side; the effort falls on client authors, who must classify their scopes and handle partial grants cleanly.
The right default for an agent token is the smallest set of permissions that still lets the task finish, with reauthorization when the need changes. I see too many automation tokens cut “just in case,” carrying write rights nobody uses that only widen the target if they leak. Making scope refusal trivial at consent time is exactly the kind of detail that turns a best practice from talk into actual use — Simon Janvier
