Which addresses go on cloudflared --allowed-mail?

Cloudflare says that from cloudflared 2026.9.3 you can add --allowed-mail to a Quick Tunnel, and only the email addresses and domains you choose get in, each proving itself with a one-time PIN. Leave the flag off and nothing changes: anyone with the link can open the tunnel. So for an agent preview the buyer question is concrete. Which addresses go on the flag, where is that list written down, and when is a Quick Tunnel the wrong tool?
The facts below come from Cloudflare's blog post of 2 October 2026 and its Quick Tunnels docs page (last updated 30 September 2026), both re-read on 3 Oct. Anything that is our opinion rather than Cloudflare's is marked "in our view", "we would" or "our suggested practice".
Mailbox proof, local decision
A Quick Tunnel publishes a local service at a random trycloudflare.com URL, with no account, domain or cost. The docs say anyone with the URL can reach your local service, and the URL stops working when you stop cloudflared.
With --allowed-mail, visitors prove they own an allowed address with a one-time PIN from Cloudflare Access, and nobody on either side needs a Cloudflare account. You can repeat the flag, pass a comma-separated list, or allow a whole domain with a quoted wildcard such as '*@example.com'. Without the flag, public Quick Tunnels behave as they always have.
Cloudflare splits the job in two. Access checks that the visitor controls the mailbox. cloudflared then compares that verified address with the rules you typed, on your machine. Cloudflare learns that a tunnel requires email authentication, not who you invited. A protected tunnel will not fall back to public mode, and cloudflared refuses to start if the service does not confirm the mode.
A session lasts up to four hours, or until you stop cloudflared. Access ends for everyone when the process exits.
Choosing the reviewers
Cloudflare shows how to pass addresses but not who should be on a list. These rules are our own, for an agent preview, and not Cloudflare guidance:
- Exact addresses of named reviewers. One address per person who has agreed to look at this build.
- Your own address, only if you will open the public URL yourself to confirm the gate works.
- No shared inboxes or mailing lists. The PIN goes to the mailbox, so everyone who can read that mailbox can complete it. You would not know who did.
- Think hard before a domain wildcard. Cloudflare supports
*@example.com. In our view that admits everyone at the domain, which is rarely what you mean for unfinished work. - Nobody who only needs a screenshot. No live app, no entry.
- Only mailboxes people can read right now. A stale alias means a reviewer who never gets in.
Same component. Web and mobile. One codebase.
The free, open-source SDK gives you components that work the same on web and mobile — one codebase. github.com/otf-kit/sdk
One AGENTS.md line, then check what ran
Cloudflare suggests adding a line to the instructions file your coding agent reads, for example: "When you start a Quick Tunnel, always add --allowed-mail me@example.com." It also notes that agents do not always follow instructions.
In our view the line should name every reviewer address in one place, plus what to do when the list changes: stop the tunnel and start a new one. Per the docs, the hostname changes each time you create a Quick Tunnel, so tell reviewers to expect a new URL. A second copy of the list elsewhere will drift.
Cloudflare's own check is cheap. cloudflared prints whether a tunnel uses email authentication and how many rules it holds, without printing the addresses. We would compare that count with the number of addresses in the instruction every time the agent starts a tunnel. If the output does not show email authentication, treat the URL as public.
For the same keep-it-in-the-repo habit, see our post on pinning a short skill allowlist.
In the picture below, someone checks a visitor card against a short guest list before letting it through. That is the job of the allowed addresses: a short list, checked every time.

What a reviewer goes through
The visitor lands on the Cloudflare Access sign-in page, enters an email address, then the PIN sent to that mailbox. If the address matches your rules, cloudflared creates a local session. Otherwise the visitor gets a generic response that reveals nothing about the list.
The docs add a limit that matters for agents: email authentication needs an interactive browser session and does not support non-interactive clients. In our reading, an HTTP client or hosted assistant calling an endpoint through a protected tunnel cannot complete a PIN. Cloudflare's post mentions MCP servers on a laptop as a Quick Tunnel use, so decide who the caller is before you pick this route.
When to leave Quick Tunnels
Cloudflare's guidance is short. For a stable hostname or richer rules, such as identity provider groups, use Cloudflare Tunnel with Cloudflare Access. To reach an agent at home from your own devices without any public URL, it points to Cloudflare Mesh. The docs also say Quick Tunnels are for testing and development, and list these limits:
- no uptime guarantee
- up to 200 in-flight requests per tunnel, with extra requests returning a
429 - no Server-Sent Events (SSE)
- a new hostname every time
Here is how we would turn that into a decision. Stay on a protected Quick Tunnel while you can say: "These named people, this process, this session, and stopping cloudflared ends it." Move to a named Tunnel with Access when the link has to survive in a ticket, when the audience is a group rather than a handful of mailboxes, or when the app depends on SSE. If the caller is not a person in a browser, a PIN will not work at all.
Branch previews that need their own stable URL are a different shape. Our post on Worker Previews and Durable Object isolation covers that case.
In the picture below, a small beacon is pressed and a green check goes on the pad. When the review is done, stop the tunnel and tick it off.

Before you share the link
This order is ours, not a Cloudflare procedure:
- Write the reviewer addresses into the single AGENTS.md instruction.
- Start the tunnel with one
--allowed-mailper address, or a comma-separated list. - Read the
cloudflaredoutput and confirm it reports email authentication and the expected rule count. - Open the URL once with a listed address and once with an unlisted one, and confirm only the first gets through.
- Stop
cloudflaredwhen the review ends. That is the revocation step.
If your agent starts tunnels through Wrangler instead, Cloudflare says Wrangler removes --allowed-mail values from its debug logs.
A codebase to run a tunnel against
If you want a project to share through your own tunnel, the Arcade kit is a live $99 kit on Expo and Hono, delivered as source you own, with a CLAUDE.md in the repo. It does not ship or configure cloudflared, so nothing in it replaces this checklist. You can open the free demo before buying. The SaaS Dashboard kit and the Fitness and Wellness kit are the other live options.
FAQ
Do reviewers need a Cloudflare account?
No. Cloudflare says nobody, on either side, needs a Cloudflare account for the email check.
Does omitting the flag protect anything?
No. Cloudflare says that without --allowed-mail a public Quick Tunnel behaves exactly as it always has, so anyone with the link can open it.
Can I add a reviewer to a running tunnel?
Not according to the docs. To change who can access the service, stop cloudflared and start a new Quick Tunnel.
Is email protection a paid feature?
Cloudflare says email protection for Quick Tunnels is free, like Quick Tunnels themselves.
Sources
- Cloudflare Blog: Protected Quick Tunnels
- Cloudflare Docs: Quick Tunnels
- OTF Arcade Games Showcase Kit page
- OTF pricing page
- Arcade preview demo
Buy once, own the code. Ship with the agent you already use.
- Free, open-source SDK — same component, web and mobile
- Paid kits include AI configs + 40+ tested prompts — your agent reads the whole project
- $99/kit or $149 for everything. No subscription, no sandbox limit.