Temporary Cloudflare Accounts for AI Agents: Hands-On Guide

The most interesting detail about Cloudflare’s new temporary accounts for AI agents isn’t the 60-minute timer or the magic CLI flag. It’s that before your agent can spin one up, Cloudflare quietly runs a proof-of-work challenge in the background. A signup flow built for humans got replaced with a signup flow built for CPUs – and almost nobody is talking about that part.

The feature dropped on June 19, 2026 and the HN thread lit up within hours. Simon Willison tested it the same week and confirmed it worked as advertised. Here’s a practical walkthrough – plus the parts the announcement glosses over.

The problem this actually solves

An AI coding agent can write a Cloudflare Worker in seconds. Deploying it used to be the slow part. A browser-based OAuth flow, a dashboard to click through, an API token to copy-paste, a multi-factor authentication prompt to satisfy – for an interactive copilot sitting next to a developer, that’s annoying. For a background agent, it’s a hard stop.

Existing workarounds were ugly. You’d pre-create an account, mint an API token, paste it into the agent’s environment, and pray nothing leaked. Fine for one agent. Painful for ten. Impossible for a SaaS where every user’s agent needs its own deployment target.

How the –temporary flag works

The mechanism is simpler than the marketing suggests. Running wrangler deploy --temporary creates or reuses a temporary preview account, deploys your Worker to a workers.dev URL, and prints a claim URL. Claim the temporary preview account within 60 minutes to keep the deployment and the Cloudflare resources created for it.

# From any agent with Node + wrangler installed
npx wrangler@latest deploy --temporary

# Output (abbreviated):
# Deployed worker-quiet-frost-1a2b to:
# https://worker-quiet-frost-1a2b.workers.dev
# Claim this account within 60 minutes:
# https://dash.cloudflare.com/claim/...

The clever bit is discoverability. How do agents and LLMs know this flag exists without a human explicitly telling them? Cloudflare updated Wrangler to prompt the agent with a message that tells it about the --temporary flag. Run a plain wrangler deploy with no credentials, and the CLI itself nudges the model toward the right command – self-bootstrapping by design.

What you need before you start

Short list. This flow requires Wrangler 4.102.0 or later – older versions won’t recognise the flag and will fail in the usual auth-loop way.

• Node 18+ and npm
• An agent that can run shell commands (Claude Code, Codex, Cursor, Cline – anything with terminal access)
• A wrangler.toml (the agent will write one for you if it doesn’t exist)
• No active wrangler login session – see the gotcha below

A real walkthrough: deploy a Worker from your agent

Open your coding agent in an empty folder and give it a deliberately bare prompt – no Cloudflare instructions, no token setup. Something like:

Pro tip: Tell the agent not to ask follow-up questions. The official docs use the prompt: “Make a very simple Hello World Cloudflare Worker in TypeScript and deploy it using the Wrangler CLI. Do not ask me questions.” The “don’t ask” line matters – without it, agents stall waiting for token input.

The agent writes src/index.ts and a minimal wrangler.toml, runs wrangler deploy, and hits the auth wall. Wrangler then prints the hint. The CLI output tells the agent: “To continue without logging in, rerun this command with --temporary.” That single line is how the agent discovers the flag without you being in the loop.

Re-run with --temporary and a workers.dev URL appears. In my test, the agent then curled its own deployment to spot-check the response – a small thing, but it shows how much of the verification loop these tools handle without prompting. According to the official Wrangler docs, the agent can iterate on the Worker script and redeploy as many times as it wants within the 60-minute claim window, reusing the same temporary account each time.

What’s actually supported (and what isn’t)

This is where the announcement is thin and the docs matter. Product support at launch is narrow.

The supported list comes directly from Cloudflare’s June 2026 changelog; everything in the right column is inferred from what’s absent. If your agent tries to provision an R2 bucket inside a temporary account, expect a clean failure rather than a silent one.

Which raises an honest question: as Cloudflare adds more products to this feature, where does the trust model break down? A temporary account that can provision SSL certificates and Durable Objects is already surprisingly powerful for something that requires no identity. The rate limit and proof-of-work gate are doing real work here – they’re not just anti-abuse speed bumps, they’re the entire accountability layer for unauthenticated infrastructure.

The gotchas competitors aren’t covering

1. The proof-of-work tax

First --temporary call in a fresh environment? Slower than you’d expect. Cloudflare runs a proof-of-work check before handing out a temporary account – the CLI handles it silently, but on a constrained Lambda or a slow CI runner that “short delay” from the docs can stretch to several seconds. Subsequent calls reuse the cached account and skip the check entirely, so it’s a one-time hit per environment, not per deploy.

2. Don’t mix –temporary with an authenticated CLI

Cloudflare’s docs are direct: use a permanent account with wrangler login or an API token for CI/CD. Skip --temporary when Wrangler is already authenticated. The tricky part – you won’t get a useful error. The flag quietly does the wrong thing if a session already exists, which makes it genuinely confusing in a shared dev environment where credentials may or may not be present depending on who ran wrangler login last.

3. Rate limits will bite a runaway agent

Hammer the temporary account endpoint in a loop and the CLI starts refusing. Cloudflare caps how fast you can create temporary preview accounts – too many requests too quickly, and you’re stuck waiting or authenticating permanently. An agent in a tight retry loop will trip this fast. Exponential backoff around deploy failures isn’t optional here; it’s what keeps your agent from sitting in a closed-door loop.

4. The free-PR-preview use case

The most popular comment on the HN thread wasn’t about agents at all. Someone pointed out: “Forget about agents, Cloudflare just provided free scratch deployments – ephemeral for 60 minutes – for anyone. This is going to be amazing for things like PR previews and code review. Being able to deploy a preview to a working URL for free is a huge reduction in friction.” If you’ve been paying for preview environments per branch, this is suddenly a free option for short-lived demos – no Cloudflare account, no card.

Claiming (or not claiming) the account

Once the 60 minutes are up, the account disappears with everything in it. If you want to keep what your agent built, open the claim URL the CLI printed, sign in or create a Cloudflare account, and the resources transfer. After claiming, the Worker and all Cloudflare resources created in that account remain available. To keep using Wrangler with the claimed account: run wrangler login, then deploy without --temporary.

And if it expires? Nothing dramatic. The Worker goes down, the temporary subdomain stops resolving, and the resources are gone. That’s the design – disposable infrastructure for an agent that may itself be disposable.

Try it in the next ten minutes

Update wrangler (npm i -g wrangler@latest), open your favourite coding agent in a scratch folder, and give it the deploy prompt. Watch the auth message appear, watch the agent pick up --temporary on its own, and bookmark the claim URL if you want to keep what it builds. The whole loop fits inside one coffee.

FAQ

Is it actually free?

Yes, for the 60 minutes. After you claim, you’re on normal Workers pricing – as of mid-2026, the free tier shuts off at 100,000 requests/day, which covers most personal projects comfortably.

Can I use temporary accounts inside GitHub Actions or other CI?

Don’t. Cloudflare’s own docs steer CI workloads toward permanent accounts with API tokens – the temporary flow is for situations where no Cloudflare identity exists yet. Run this daily in CI and two things break you: the rate limit on account creation, and the fact that you lose all state every 60 minutes anyway. Run wrangler login once, store the token as a GitHub secret, and stop thinking about it.

What happens to my data if the account expires?

Everything in the temporary account – Workers, KV namespaces, D1 databases – is deleted. No grace period, no recovery. If your agent populated a D1 database during the session, claim the account before the timer runs out or treat that data as throwaway from the start.