Cloudflare Quick Tunnels Can Now Require Email Sign-In Before Anyone Reaches Your Machine
Cloudflare now lets you restrict a Quick Tunnel to specific email addresses with the --allowed-mail flag in cloudflared 2026.9.3. Visitors verify with a one-time PIN, neither side needs a Cloudflare account, and the guest list stays on your machine.

What changed on October 2
Since 2 October 2026, a Cloudflare Quick Tunnel can be limited to the email addresses or domains you specify. Add --allowed-mail with an address or a domain, and a visitor has to prove they control that address with a one-time PIN before a single request reaches your machine. The flag ships in cloudflared 2026.9.3 and in the latest Wrangler. Without --allowed-mail, a Quick Tunnel remains public as before: one command publishes a local port at a random trycloudflare.com URL with no account, DNS record or fee.
The new part is where the decision is made. A protected tunnel checks its guest list on your own machine instead of in a Cloudflare account, so the rest of the Quick Tunnel behaviour, including its limits, stays the same.
How coding agents use Quick Tunnels
Cloudflare says agent workflows drove the change. A coding agent that finishes a feature can start a dev server and publish a URL by itself, and --output json turns the log lines into JSON objects so the agent can read the address without scraping text. The same pattern covers a model context protocol server on a laptop that a hosted assistant has to call, or a machine at home that should be reachable from a phone. Cloudflare says adoption of Tunnel and Quick Tunnels has grown exponentially since agents took off, and it points to the discussion that followed its Quick Tunnels page reaching the top of Hacker News on 18 September 2026, where one commenter asked how long it would be before an agent exposed something private. Cloudflare said the submission had more than 800 points and 300 comments when it published the announcement. Cloudflare also says two interns shipped the feature, from product requirements to the authentication broker and the cloudflared release.
Where the guest list lives
Authentication and authorization happen in different places. Cloudflare Access verifies that a visitor controls the email address: the browser is redirected to login.trycloudflare.com with a single-use state that expires after ten minutes, Access sends the PIN, and a stateless broker on Workers returns a short-lived signed assertion bound to the tunnel hostname and to that state. The browser posts the assertion in a form, so it never lands in a URL, browser history or logs. cloudflared then checks the address against the rules you typed and creates a local session.
Cloudflare never stores the guest list. The connector sends only the authentication mode, and if the service does not confirm that mode, cloudflared refuses to start rather than hand out a public URL by mistake. Sessions last up to four hours, or less if the visitor's Access sign-in expires first, and they end the moment you stop the process. The session cookie holds a random value and an expiry time, and nothing about who the visitor is. Before forwarding a request, cloudflared strips the email-authentication credentials, so the app does not handle the PIN flow itself. This email gate does not replace any application-specific authentication or authorization the service still needs. A protected tunnel never falls back to public mode.

One flag in a terminal or in Wrangler
Pass one address, repeat the flag, use a comma-separated list, or allow a whole domain with a wildcard such as *@example.com, quoted so the shell does not expand it. Wrangler supports the same options for Workers projects and removes --allowed-mail values from its debug logs. Cloudflare also suggests putting the flag in the instructions file an agent reads, such as AGENTS.md, so that previews open only for you. Instructions do not guarantee behaviour, so the post advises checking what the agent actually ran: cloudflared prints whether a tunnel uses email authentication and how many rules it holds, without printing the addresses.
What a protected tunnel still cannot do
The documentation lists the limits. Quick Tunnels carry no uptime guarantee, each one supports up to 200 in-flight requests and returns a 429 response beyond that, and Server-Sent Events are not supported. Email authentication needs an interactive browser session, so it does not work for non-interactive clients: a webhook sender or a command line tool cannot complete the PIN step. The hostname changes every time a tunnel starts, and there is no way to edit the guest list on a running tunnel. You stop the process and start a new one, which also ends everyone's session. An endpoint that needs stable access for customers or ongoing team work should use a more durable setup rather than a temporary Quick Tunnel.
When a named tunnel or Mesh fits better
Cloudflare points to two products for anything beyond a temporary demo. A named Cloudflare Tunnel with Access gives a stable hostname and richer rules, such as identity provider groups, at the cost of an account and a domain. Cloudflare Mesh connects your own devices without exposing a public URL at all, which fits the case of reaching an agent at home from a phone. Quick Tunnels remain the account-free option with the fewest knobs, which is also why their limits are tighter.
Questions the announcement leaves out
Some details are not in the announcement. Cloudflare does not say how many email addresses one tunnel can hold, whether rate limits apply to PIN delivery, or what happens to an active session when Access expires mid-request. The post does not publish a retention period for the addresses Access processes during sign-in, beyond saying the broker stores no visitor sessions and no identity records. It also does not say whether Wrangler's tunnel support works on every Workers plan.
What to check before sharing a preview
Update cloudflared to 2026.9.3 or later before trying the flag; Cloudflare says support begins with that release. Add --allowed-mail to a development server or agent preview intended for interactive browser visitors. A webhook sender cannot complete the email PIN flow, so use a separate access method suited to non-interactive clients for that case. A Quick Tunnel without the flag remains public. Read the connector's output to confirm what actually ran, and move to a named tunnel once a URL has to survive a restart.
Sources & further reading
- Protected Quick Tunnels: simple accountless authentication for your next dev projectCloudflare, Inc. · accessed Oct 12, 2026
- Changelog (Cloudflare Tunnel)Cloudflare, Inc. · accessed Oct 12, 2026
- Quick TunnelsCloudflare, Inc. · accessed Oct 12, 2026
- Cloudflare Quick TunnelsCloudflare, Inc. · accessed Oct 12, 2026
- Hacker News story search snapshot (30-day window)Hacker News (Algolia API) · accessed Oct 12, 2026