Cloudflare Temporary Accounts: How AI Agents Deploy Workers Without Signup (2026)

On June 19, 2026, Cloudflare announced Temporary Accounts for AI agents — a way for coding agents to deploy Workers, APIs, and websites without hitting the human auth wall first.

The problem is familiar: an agent writes code, runs wrangler deploy, and stalls at browser OAuth, MFA prompts, API token copy-paste, or dashboard clicks. For an interactive copilot, that's friction. For a background agent with no human in the loop, it's a hard stop.

The fix is one flag: wrangler deploy --temporary. Cloudflare provisions a temporary preview account, deploys your Worker to a workers.dev URL, and prints a claim link. You have 60 minutes to make it permanent — or it expires on its own.

This guide covers the full flow, supported products, limits, and where this fits in the broader push toward frictionless agentic deployments.

Quick reference

Jump to:

• Why this matters for agents
• The full deploy flow
• How agents discover --temporary
• Iterating and redeploying
• Claiming the account
• Supported products and limits
• Security and abuse prevention
• The broader agent deployment stack

Why frictionless deployments matter

Cloudflare's announcement frames three reasons temporary accounts exist:

1. Background agents have no human in the loop

Agent sessions that run overnight, in CI sandboxes, or as sub-agents in a larger harness cannot complete browser OAuth flows. Any step requiring "click here in 60 seconds" or copy-paste from a dashboard means the agent gets stuck — and may deploy elsewhere.

This is the same class of problem our Agent Harness guide describes: the harness controls tool execution, verification, and loop termination. Deployment auth is just another tool gate — and until now, it was a gate only humans could open.

2. Trial-and-error is the agent's superpower

Agents work best in a tight write → deploy → verify loop. They need cheap, throwaway deployment targets so they can curl their own output and decide whether the result matches intent. A 60-minute ephemeral account is exactly that: a sandbox with a real public URL, not a mock.

3. Agent platforms expect deploy to "just work"

People are starting to expect that agents can ship code without signing up for services the user has never heard of. Cloudflare bet on Wrangler specifically because it's widely documented and agents already know how to use it — they just needed an unauthenticated entry point.

Step-by-step deploy flow

Requires Wrangler 4.102.0+. Update with:

npm install -g wrangler@latest
# verify
wrangler --version

Step 1: Prompt your agent

Give a coding agent a deploy task with no auth instructions. Cloudflare's docs suggest:

Make a very simple Hello World Cloudflare Worker in TypeScript and deploy it
using the Wrangler CLI. Do not ask me questions.

Step 2: First deploy fails (by design)

The agent runs wrangler deploy. With no credentials, Wrangler prints:

To continue without logging in, rerun this command with `--temporary`.
Wrangler will use a temporary account and print a claim URL.

This message is intentional — it lets the agent discover --temporary from CLI output without you specifying the flag in the prompt.

Step 3: Redeploy with --temporary

npx wrangler deploy --temporary

Expected output (from Cloudflare docs):

Continuing means you accept Cloudflare's Terms of Service and Privacy Policy.
Temporary account ready:
  Account:        example-name (created)
  Claim within:   60 minutes
  Claim URL:      https://dash.cloudflare.com/claim-preview?claimToken=<TOKEN>

Uploaded example-worker
Deployed example-worker triggers
  https://example-worker.example-name.workers.dev

Before creating the account, Cloudflare runs an automatic proof-of-work check. This can add a short delay but requires no user input.

Step 4: Verify the deployment

The agent can curl the preview URL and confirm output matches code:

curl https://example-worker.example-name.workers.dev

In Cloudflare's demo, the agent wrote the script, deployed with --temporary, curled the preview link, and verified the response — all without human intervention.

How agents discover the flag

A subtle design choice: Cloudflare did not assume agents would know about --temporary on day one.

Instead, the first unauthenticated deploy attempt returns a hint in stderr/stdout. Any agent that reads tool output and adapts — Claude Code, Pi, OpenCode, Codex — can self-correct on the second attempt.

This pattern mirrors how good agent harnesses handle tool failures: parse error output, retry with corrected parameters. Cloudflare built the retry hint into the CLI itself.

Important: --temporary is not a global flag. It is available only on commands that can use the short-lived temporary preview account token. If Wrangler is already authenticated, --temporary returns an error — use wrangler login and deploy normally instead.

Iterating within the 60-minute window

Agentic coding is rarely one deploy. A session might cycle through:

1. Deploy hello world
2. Change copy to "hello cloudflare"
3. Add a route handler
4. Redeploy and re-verify

This works. Wrangler caches the temporary preview account and reuses it while both the account and claim URL remain valid. Output shows whether the account was created or reused.

# First deploy
npx wrangler deploy --temporary

# Edit src/index.ts, then redeploy — same temporary account
npx wrangler deploy --temporary

The cache clears when you run wrangler login or wrangler logout.

Example iteration prompt:

Now change hello world to "hello cloudflare" and redeploy

The agent edits source, reruns wrangler deploy --temporary, curls the updated URL, and confirms the change — still within the claim window.

Claiming the temporary account

To keep the deployment permanently:

1. Open the claim URL from Wrangler output within 60 minutes
2. Sign in to Cloudflare or create a new account
3. Follow dashboard prompts to claim the temporary preview account

Claiming transfers ownership of everything in that account — not just the Worker, but also D1 databases, KV namespaces, Queues, and other bindings created during the session.

After claiming:

wrangler login
wrangler deploy   # no --temporary needed

If you do not claim within 60 minutes, Cloudflare automatically deletes the temporary account and all resources inside it.

Security note: Claim URLs grant ownership of the temporary preview account. Treat them as sensitive — do not commit them to git or paste them in public channels.

Supported products and limits

Temporary preview accounts support a subset of Cloudflare products. From the official docs:

Cloudflare says it will add support for more products over time. Check the docs before assuming a binding works on a temporary account.

Other limits

For production and CI/CD, use a permanent Cloudflare account with wrangler login or a scoped API token. Do not use --temporary in pipelines where credentials already exist.

Security and abuse prevention

Temporary accounts are designed for low-friction prototyping, not anonymous production hosting. Cloudflare applies:

• Proof-of-work before account creation (automatic, no user input)
• Rate limits on temporary account creation
• Abuse prevention checks on temporary preview accounts
• Sensitive claim URLs that transfer full account ownership

For agents running in untrusted environments, treat temporary deployments as public-by-default preview URLs. Do not deploy secrets, production data, or unauthenticated admin endpoints to a temporary account expecting privacy.

If your agent harness needs deployment in a locked-down environment, use permanent accounts with scoped API tokens and explicit permission gates — the pattern described in our Claude Code permission modes guide.

The road to frictionless agentic deployments

Temporary accounts are one piece of a larger Cloudflare push to make infrastructure agent-ready:

Stripe partnership (account provisioning protocol)

Cloudflare announced a partnership with Stripe and co-designed a protocol that lets agents provision Cloudflare on behalf of users — creating an account, starting a subscription, registering a domain, and getting an API token to deploy code, with no copy-pasting tokens or entering credit card details manually.

auth.md with WorkOS

Cloudflare collaborated with WorkOS on auth.md — an open standard for agents to provision new accounts using existing OAuth flows. Any platform can adopt it.

Agents SDK and MCP

Cloudflare is also expanding the Agents SDK as a runtime other agent frameworks (starting with Flue) can build on, plus MCP server support for agent tool integration. See our MCP guide for the protocol basics.

isitagentready.com

Cloudflare points developers to isitagentready.com — a checklist for making apps accessible to agents without human intervention at every step.

The through-line: signup and auth were built for humans. Agents need the same infrastructure access with programmatic entry points. Temporary accounts solve the cold-start problem; Stripe provisioning and auth.md solve the permanent-account problem.

When to use what

Example: full agent session

Here is what a complete unauthenticated agent session looks like:

# Agent creates project
npm create cloudflare@latest my-worker -- --type hello-world

cd my-worker

# First attempt — no credentials
npx wrangler deploy
# → "rerun with --temporary"

# Second attempt — succeeds
npx wrangler deploy --temporary
# → https://my-worker.abc123.workers.dev
# → claim URL printed

# Verify
curl https://my-worker.abc123.workers.dev

# Iterate
# (agent edits src/index.ts)
npx wrangler deploy --temporary
# → Account: abc123 (reused)

curl https://my-worker.abc123.workers.dev
# → updated response

# Human claims within 60 min, then:
wrangler login
wrangler deploy

Summary

Cloudflare Temporary Accounts remove the first-deploy auth wall for AI agents. The key facts:

1. wrangler deploy --temporary provisions a 60-minute preview account with a live workers.dev URL — no signup required upfront.
2. Agents self-discover the flag from Wrangler's unauthenticated deploy hint — no need to hardcode --temporary in every prompt.
3. Redeploy freely within the claim window; Wrangler caches and reuses the temporary account.
4. Claim to keep — open the claim URL, sign in, and the Worker plus bindings become permanently yours.
5. Not for production — use permanent accounts with scoped tokens for CI/CD and shipped products.

For anyone building agent harnesses that include a deploy step, this is the most practical Cloudflare integration to test first. Point your agent at a Worker project, let it hit the auth wall once, and watch it self-correct.

Related reading

• What Is an Agent Harness? — the scaffolding layer agents deploy through
• Agent Harness Engineering — when the model stays fixed and scaffolding wins
• What Is MCP? Model Context Protocol Guide — how Cloudflare Agents SDK fits agent tool loops
• Loop Engineering for Coding Agents — write → deploy → verify loops in Claude Code
• Pi: Minimal Agent Harness — a harness you own, with deploy as a tool call

Official sources: Cloudflare blog post · Claim deployments docs · Wrangler releases · Stripe agent provisioning · auth.md

Wrangler version requirements, product limits, and claim window duration reflect Cloudflare documentation as of June 20, 2026. Verify current limits at developers.cloudflare.com before production use.