Sign in Subscribe
news

2026-10-25 Cloudflare Quick Tunnels can now be restricted by email

Sebastien Dubois

Sebastien Dubois

— 5 min read

Canonical version: 2026-10-25 Cloudflare Quick Tunnels can now be restricted by email.

Cloudflare Quick Tunnels no longer have to be open to anyone who gets the link. Since cloudflared 2026.9.3, you can add --allowed-mail to the command, and only the email addresses or domains you list can get in. You still don't need an account or a domain, and it's still free.

Cloudflare announced it on 2 October 2026, during its Birthday Week. Two interns built it: Hugo Vicente on product and Alessandro Frigerio on engineering. I care about this one because of AI agents. Coding agents now open public tunnels on their own to show you what they built, and until now, those links were open to the whole Internet.

What changed

Quick Tunnels have been around since 2021. You run cloudflared tunnel --url http://localhost:8080 and you get a random trycloudflare.com URL that points to your local service. No Cloudflare account, no domain, no DNS record. The problem was always the same: anyone with the URL could open it.

Now you can pass a guest list:

cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail [email protected] \
  --allowed-mail '*@example.com'

You can repeat the flag, pass a comma-separated list, or allow a whole domain with *@example.com (put it in quotes so your shell doesn't expand the wildcard). Leave the flag out and Quick Tunnels behave exactly as they always have.

When Alice opens the URL, she enters her email address, receives a one-time PIN, types it in, and reaches your app. Nobody needs a Cloudflare account, on either side.

The same works from Wrangler, which also strips the addresses from its debug logs:

npx wrangler tunnel quick-start http://localhost:8080 --allowed-mail [email protected]

The list is fixed when the tunnel starts. To change it, stop cloudflared and start a new tunnel (with a new URL, since the hostname changes every time). When the process exits, access ends for everyone.

How it works

Cloudflare split the problem in two. Cloudflare Access handles authentication: it checks that the visitor controls the email address. Authorization, deciding whether that person is on your list, happens in cloudflared, on your machine.

Here's what happens on a first visit:

  1. cloudflared sees a request without a session and redirects the browser to login.trycloudflare.com, with a single-use state that expires after 10 minutes
  2. Access emails a one-time PIN to the visitor and verifies it
  3. A small, stateless broker running on Cloudflare Workers turns that verified identity into a short-lived signed assertion, bound to the tunnel hostname. The browser delivers it in a form POST, so it never ends up in a URL, the browser history or logs
  4. cloudflared verifies the assertion and checks the email against your list. If the address isn't on it, the visitor gets a generic response that reveals nothing about who is allowed
  5. On a match, the visitor gets a local session for up to four hours (less if their Access sign-in expires sooner), or until you stop cloudflared

After sign-in, there's no central policy lookup on each request. cloudflared also removes the authentication credentials before forwarding requests, so your local app never sees them and doesn't need any login code.

It fails closed. If Cloudflare doesn't confirm the email mode when the tunnel starts, cloudflared refuses to start instead of handing you a public URL by mistake. A protected tunnel never falls back to public mode.

Cloudflare also explains the two designs it rejected. Putting an Access application in front of every Quick Tunnel didn't fit: hundreds of thousands of them can run at once, many for a few minutes, and there's no account to own the applications. Building the whole email login in-house meant redoing email delivery, abuse prevention and sign-in pages that Access already handles. So it kept Access for the email check and kept the list on the developer's machine.

Limits

The Quick Tunnels documentation lists these:

  • Email authentication requires an interactive browser session. Non-interactive clients can't sign in
  • Each Quick Tunnel handles up to 200 in-flight requests; extra requests get a 429
  • No Server-Sent Events (SSE) support
  • No uptime guarantee, and a new hostname every time

If you need a stable hostname or rules based on identity provider groups, use a named Cloudflare Tunnel with Access. And if you want to reach an agent running at home from your own devices without any public URL, Cloudflare points to Cloudflare Mesh.

Why I care

The Cloudflare post opens with a scene anyone using Claude Code or another coding agent will recognize. The agent finishes a feature, starts the dev server, and offers to let you try it on your phone. It runs one command and hands you a link. That link is a Quick Tunnel.

Agents like Quick Tunnels for the same reason people do: one command, no signup form to get stuck on. Cloudflare says adoption has "grown exponentially" since agents took off. A Hacker News thread about Quick Tunnels on 18 September 2026 gathered more than 800 points, and one commenter asked how long it would take before someone's agent sets up a tunnel exposing their most private information, or an insecure work-in-progress app, to the world.

An agent that can open a tunnel can put whatever runs on that port on the public Internet, and you might not even notice. What makes --allowed-mail useful for agents is that the protected version is the same command plus one flag. So I'd add a line like this to the AGENTS.md file your agent reads:

When you start a Quick Tunnel, always add --allowed-mail [email protected].

Agents don't always follow instructions (Cloudflare says so too), so check what yours actually ran. cloudflared logs whether a tunnel uses email authentication and how many rules it holds, without printing the addresses.

With Cloudflare's other products, access rules live in your Cloudflare account. Quick Tunnels have no account, so the list stays in memory, on your machine. Cloudflare learns that a tunnel requires email authentication; it doesn't learn who you invited. I strongly believe this is the right split for a free service that anyone can use without signing up: Cloudflare verifies the email, and the decision (and the list of people) stays with you.

Keep the browser requirement in mind, though. The post mentions MCP servers on a laptop that need a public endpoint before a hosted assistant can call them, and the changelog lists webhook receivers as a use case. But the docs say email authentication only works with an interactive browser session, so a hosted assistant or a webhook sender can't get through the PIN step. For those, you'll need something else, like a named tunnel with Access.

That's it for today! ✨

References

About Sébastien

Ready to get to the next level?

Found this valuable? Share it with someone who needs it.

Join 6,000+ readers. Get practical systems for knowledge & AI. Free.

Subscribe ✨

Free: Knowledge System Checklist

A clear roadmap to building your own knowledge system. Subscribe and get it straight to your inbox.

6,000+ readers. No spam. Unsubscribe anytime.

Subscribe