Protected Quick Tunnels: simple accountless authentication for your next dev project
- ID
- 31136
- Status
- summarized
- Published
- 02 Oct 2026, 9:00 PM
- Fetched
- 02 Oct 2026, 10:45 PM
- Provider
- Cloudflare Blog
- Category
- infrastructure
- Original URL
- https://blog.cloudflare.com/protected-quick-tunnels/
- Source URL
- https://blog.cloudflare.com/rss/
Summary
- Score
- 6.5
- Created
- 02 Oct 2026, 10:46 PM
- Tags
- Audience
- developersvibe_codersai_agent_users
What happened
Cloudflare shipped a new --allowed-mail flag in cloudflared 2026.9.3 that restricts a Quick Tunnel to specific email addresses or domains, with visitors proving ownership via a Cloudflare Access one-time PIN and no Cloudflare account required on either side. Quick Tunnels (launched 2021) publish a local port to a random trycloudflare.com URL from one command, and adoption has grown alongside coding agents; a Quick Tunnels link hit the top of Hacker News on September 18, 2026 with 800+ points and 300 comments, including one asking how long until an agent exposes someone's most sensitive work-in-progress app. The post also notes --output json turns every cloudflared log line into a JSON object so an agent can extract the URL without text scraping.
Why it matters
If you let coding agents or MCP servers run `cloudflared tunnel --url http://localhost:5173` to show you a preview, that link was previously open to anyone who saw it. Upgrading to cloudflared 2026.9.3 and adding --allowed-mail alice@example.com (or a whole domain) closes that gap without a signup flow an agent can get stuck on, and --output json means your agent can parse the URL reliably instead of regexing logs. Decide now whether your agent workflow should default to --allowed-mail rather than plain --url, especially for anything touching real data.
Discussion angle
The HN commenter's question is the real thread here: agents now publish local ports to the public internet on their own initiative. Should --allowed-mail be the default in your agent tooling, and how do you stop an agent from exposing a dev server that's pointing at production credentials?