Cloudflare has added optional email authentication to Quick Tunnels, letting developers share a local application without letting everyone who obtains the link open it. Neither the developer nor their visitors need a Cloudflare account. For agent-built prototypes and development previews, that is a useful change: sharing a working demo need not mean sharing it with the entire internet’s extended family.
Cloudflare Watch analysis
What happened
In its 2 October announcement, Cloudflare introduced Protected Quick Tunnels through a new –allowed-mail option, available from cloudflared version 2026.9.3. Developers can specify permitted email addresses or domains, and visitors authenticate using a one-time PIN sent through Cloudflare Access.
Quick Tunnels publish a service running on a developer’s machine at a random trycloudflare.com address. They require no account, domain or payment. The existing unprotected arrangement allows anyone with the link to open the service; the new restriction must be explicitly added.
For a local application running on port 5173, add the allowed-mail option when starting the tunnel and specify the intended visitor’s email address. With the email restriction enabled, possession of the link alone is no longer enough.
Why it matters
Coding agents can now build an application, start its development server and produce a shareable URL with very little intervention. That convenience creates an equally straightforward access question: who should be allowed to use the thing the agent has just exposed?
An email gate gives developers a practical answer without requiring them to build a login system into every temporary preview. It is particularly useful when checking an agent’s work from a phone or inviting a colleague to try a feature before deployment.
Cloudflare’s Protected Quick Tunnels announcement describes those agent workflows as a growing use case. The useful development here is the access control, not the popularity claim.
Our read
This is a worthwhile improvement because it preserves the low-friction sharing workflow while adding a concrete restriction on visitors. A prototype can remain easy to reach without treating its link as the only door key.
If an agent routinely creates preview tunnels, put the permitted visitor into that workflow rather than remembering to add protection afterwards. The flag is optional: updating the software alone does not change an unrestricted sharing command into a protected one.
Keep the boundary clear. Email authentication controls entry to the preview; it does not establish that the application behind it is suitable for sensitive data or production use. A better front door is welcome, but it is still worth checking what you have left in the hallway.
What to watch
- Whether coding-agent workflows routinely include an explicit visitor restriction when creating previews.
- How reliably PIN sign-in works for colleagues and external reviewers.
- Whether teams choose individual addresses or broader domain rules for development sharing.
Discussion spark: Should coding agents protect every development preview by default, or should unrestricted links remain the default for deliberately public demos?
Sources and evidence
- Source update (2 October 2026, 13:00 UTC)
not affiliated with or endorsed by Cloudflare