Protected Quick Tunnels Add Email Authentication
Cloudflare has introduced email authentication support for Quick Tunnels, enabling developers to secure local development servers with an optional command-line flag.

Securing Local Development Environments
Cloudflare has updated its lightweight connector to support email authentication, offering developers a way to restrict access to their local applications. Originally launched to provide an easy way to share services running in local development environments, Quick Tunnels publish local services at a random trycloudflare.com URL without demanding an account, domain, or cost. However, because these endpoints were previously public, anyone with the link could access them.
Starting with version 2026.9.3 of the client connector, developers can add a specific command-line parameter to restrict tunnel access to chosen email addresses or domains. Visitors verify their identity by proving they own an approved address using a one-time PIN provided by Cloudflare Access. Neither party requires a Cloudflare account to use this feature.

Growing Adoption Among Coding Agents
The demand for secure, accountless endpoints has grown alongside the rise of coding agents. These automated systems frequently need to expose local servers—such as a dev server running on a local port or a Model Context Protocol server—so that users can review features on external devices or allow hosted assistants to call them. Because Quick Tunnels operate via a single command, agents can run them autonomously without getting stuck on signup forms.
The ecosystem surrounding these tunnels has experienced significant expansion. Recent community discussions on platforms like Hacker News highlighted numerous automated workflows where AI agents independently utilized Quick Tunnels to publish newly built websites, prompting discussions around secure access control for works-in-progress.
How the Authentication Architecture Works
The mechanism separates visitor authentication from authorization. When a user opens a protected URL, they encounter the Cloudflare Access sign-in page where they enter their email address and a one-time PIN. This step confirms that the visitor controls the email address, but the final authorization decision occurs locally on the developer's machine.
Rather than storing temporary guest lists centrally or creating temporary Cloudflare Access applications for hundreds of thousands of ephemeral tunnels, the system uses a stateless authentication broker running on Cloudflare Workers. The broker converts the verified identity into a short-lived, signed handoff. The local connector then evaluates this handoff in memory against the developer's rules, ensuring the guest list never leaves the local machine.

Implementation and Usage Options
Developers can implement the restriction by appending the appropriate flag to their command execution or by integrating it into instructions for coding agents. If the flag is omitted, public tunnels behave exactly as they have previously. Access to the tunnel ends immediately once the underlying process exits.
For builders utilizing Wrangler, similar capabilities are supported from the command line, allowing repeated flags, comma-separated values, and wildcard domains while scrubbing sensitive details from debug logs. For more permanent hostnames or advanced team management structures involving identity provider groups, standard tunnels and access policies remain available.
Sources
- Cloudflare BlogProtected Quick Tunnels: simple accountless authentication for your next dev project
Continue chronologically




