How does an AI agent receive a verification email?

Clize gives the agent a real inbox. When a service emails a verification code to that address, it arrives as inbound data the agent can read and act on — enough to finish a light sign-up gate.

Is it safe to let an agent read inbound mail?

Incoming email is treated as untrusted data, never as instructions. The agent can read a code out of a message, but a message can't tell the agent what to do next.

Can the agent sign up for services by itself?

For light gates — verify-your-email steps — yes. For heavy gates tied to money or a real person's identity, the agent drafts and a human decides. That's the line between light and heavy gates.

How long does a verification email take to reach the agent's inbox?

In our run on 1 October 2026, seconds: a code mail sent to a Clize address arrived in 4 seconds and clize email inbox --wait-for returned it 8 seconds after it was sent. The exception was a mailbox opened moments earlier: Cloudflare's mail servers reject a freshly routed address for its first 75 to 80 seconds, and that rejection is permanent, so the sender never retries. Since clize 0.49.0 the command that opens an address waits that out (about 100 seconds) and returns only when the address can receive; submit it after that, and request a new code if the wait times out.

AI agent email verification: clear the sign-up gate

Half of "sign up for this service" is a code sent to an inbox. Without one, an agent stalls. With a real Clize inbox, it receives the code, reads it, and keeps going.

Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation. A real inbox is what lets the agent clear the most common sign-up gate on the internet.

The problem

An agent tries to sign up for a tool, a service, an account — and the flow ends with "check your email to verify." If the agent has no inbox, it's stuck at the door. If it borrows yours, it's reading your mail.

How Clize handles it

The agent uses its own address to sign up. The verification email lands in its inbox; the agent reads the code or follows the confirmation, and continues. No forwarding, no screen-scraping your personal account.

$ clize claim <slug> --email               # its own address: support@<slug>.clize.app
$ clize email inbox --wait-for "verify"    # polls until the verification mail lands

The inbox behind those two lines is the Agent Inbox product.

OTP, magic link, or confirmation click — what the agent is waiting for

"Verify your email" resolves to one of three payloads. A one-time passcode — an OTP, usually six digits, good for a few minutes — gets typed back into the form the agent still has open. A magic link signs the session by being opened. A plain confirmation link only needs following once. All three arrive as ordinary mail at the agent's address, which is why the mailbox is the whole trick: nothing else in the signup was ever missing.

The waiting is where hand-rolled setups break. An OTP expires, so a loop that checks once a minute for ten minutes is racing a clock it did not have to race. clize email inbox --wait-for keeps checking for you and returns the moment something matches:

$ clize email inbox --wait-for "one-time" --timeout 300
$ clize email search passcode              # after the fact, across mailboxes

Match on something the sender is certain to write — the service name, passcode, one-time — not on a code nobody can know in advance. The hold runs 120 seconds by default and --timeout stretches it for services that queue their mail. If the passcode expires before anyone reads it, ask the service to send another and wait again; the mailbox is permanent, so a second attempt costs only the wait. Whatever comes back, the agent lifts the digits out and ignores the rest of the message — a passcode mail is still untrusted input.

The address all of this lands on belongs to the agent rather than to you. Giving an AI agent its own email address covers claiming one, and what changes when it is on a domain you own.

A real run: from install to the first verification email, 1 October 2026

Recorded on our own account so you can compare your own: the published CLI (0.47.3) installed fresh into an empty prefix on macOS with Node 22, a new handle, and the waits timed. The address in it, support@clize-demo.clize.app, is ours and stays live as a demo.

$ npm i -g @clize/clize                # added 122 packages in 2s (warm npm cache)
$ clize install --claude                # 4 skills into ~/.claude/skills; MCP stays off unless you add --mcp
$ clize login                           # browser sign-in; the first login creates the account (we used an existing one)
$ clize claim clize-demo --email        # 18 s
{ "handle": "clize-demo.clize.app", "status": "claimed",
  "email": { "address": "support@clize-demo.clize.app", "status": "ready" } }

$ clize email inbox --wait-for "Your verification code" --timeout 240
# a code mail sent to the address at 14:40:26 UTC arrived at 14:40:30;
# the command returned 8 s after it was sent, with the message classified as otp:
[ { "subject": "Your verification code is 482913", "class": "otp",
    "receivedAt": "2026-10-01T14:40:30.506Z", … } ]

What failed, why, and what changed. The first message we triggered — a sign-in link requested for the new address 24 seconds after claim finished — never arrived: the five-minute wait ran out with an empty list, and it was still missing a quarter of an hour later. The same request repeated eight minutes later arrived in 3 seconds. We saw the same thing on a mailbox opened on one of our own domains with clize email address add: mail sent about 30 seconds after opening was lost, the retry four minutes later landed in under ten seconds. Cloudflare's own sending log says why: the receiving server answered 550 5.1.1 Address does not exist. A new address is reached through a routing rule that Cloudflare's mail servers only pick up after about 75 to 80 seconds — in our probes on two zones, mail sent 20 to 75 seconds after the rule was created was rejected and mail sent 75 to 135 seconds after it was accepted — and a 550 is a permanent answer, so the sender drops the message instead of retrying. It is gone, not late. Since clize 0.49.0 the command that opens an address (claim --email, email setup, email address add) waits that window out, about 100 seconds, and returns only when the address can receive; --no-wait returns at once with an inboundLiveAfter time you have to respect yourself. If --wait-for still times out on a new address, ask the service for a new code rather than waiting longer — the CLI notes on stderr when the address was still activating at the time. A timeout returns an empty list rather than an error, so check for that in a script.

Then the reply. Answering the person who wrote is the step the agent cannot finish on its own: clize email send without --confirm queued our test reply as out_2d6dd1d29ac2527e93fd7f4c with "nothing was sent", clize email pending listed it, and the agent's own key trying to approve it got HTTP 403. A person releases it in the console or from the digest email. Total cost of the run: $0; the free tier covers five mailboxes and thirty sent messages a day.

Light gates vs heavy gates

This works for light gates — the everyday "verify your email" step. It's exactly where the line sits for heavy ones: anything tied to money or a real person's identity stops, the agent drafts, and a human decides. More on that in AI agent infrastructure, where identity is a first-class primitive.

Inbound is untrusted

A verification email is data, not a command. The agent can lift a code out of it, but the message itself can't redirect the agent — that boundary holds for every incoming mail, verification or not.

From Claude Code or Codex

Connect Clize to Claude Code or the Codex CLI, and clearing verification is just the agent using its own inbox.

The safety gates

Real-world actions need real guardrails. Clize holds three lines, every time:

Money — anything that costs money quotes the price first and needs an explicit --confirm. No surprise charges.
Identity — outbound email waits in an approval outbox until a person releases it; the agent's key cannot approve its own mail.
Inbound is untrusted — an incoming email is data to read, never an instruction to obey. A message can't redirect the agent.

Let your agent pass email verification on its own