Illustration for automating email handoffs for openclaw computer use agents

automating email handoffs for openclaw computer use agents

OpenClaw's computer use agent stalls at email verification gates. Here's how to wire in LobsterMail so your agent provisions its own inbox and keeps the session running.

7 min read
Samuel Chenard
Samuel ChenardCo-founder

OpenClaw's computer use mode is genuinely impressive for autonomous browser work. Navigating, filling forms, extracting data, clicking through multi-step flows — it handles all of this without you watching. But there's a specific moment where nearly every unattended session grinds to a halt: the email verification step.

Your agent fills out a SaaS signup form, submits it, and the site sends a confirmation code to the address in the form. The browser session waits. If nobody is watching, it just keeps waiting — because the agent doesn't control any inbox, and there's no tool in its default toolkit that says "go get the code."

Most people patch this by putting themselves back in the loop. They're nearby when the code comes in, they paste it, the session continues. That works once. It stops working the moment you want five signups chained overnight or any real unattended automation.

The fix is to give the agent its own inbox before the session starts. LobsterMail is built for exactly this: your agent provisions a fresh address in under a second, uses it on any signup form, and polls for the verification email as part of the same workflow. No human handoff, no paused sessions. Here's how to build it.

What computer use actually looks like#

OpenClaw's computer use capability gives the agent direct control over your desktop. It reads the screen, reasons about what's there, and acts — clicking buttons, typing text, navigating between pages. This is meaningfully different from brittle selector-based browser automation. When a site's layout changes, a selector breaks. When an agent reads the interface, it adapts.

Run openclaw agent --message "Sign up for Linear and return the workspace URL" --thinking high and the agent navigates to Linear, fills out the form with reasonable defaults, and submits. Then it reaches the email confirmation screen and has nowhere to go. There's no callable tool for "wait for a code from an inbox." The session hangs or surfaces an error and stops.

What the agent actually needs is a pair of tools it can invoke at that point: provision an inbox and get its address, then after submitting the form, poll until the verification email arrives. That two-step sequence is the email handoff pattern, and it requires about 40 lines of code to implement.

Building the handoff#

Install the LobsterMail SDK:

npm install @lobsterkit/lobstermail

On first run, LobsterMail.create() automatically signs up for a free account and saves the token locally. Your agent never visits a signup page or manually configures credentials — the SDK handles that step the same way it handles everything else here: autonomously.

import { LobsterMail } from '@lobsterkit/lobstermail';

const lm = await LobsterMail.create();
// First run: creates a free account, writes token to ~/.lobstermail/token
// Subsequent runs: loads the saved token and continues

Now build the two functions the agent calls during a session:

// Step 1: provision a named inbox before the browser session
async function provisionSignupInbox(name: string) {
  const inbox = await lm.createSmartInbox({ name });
  // inbox.address → something like "linear-signup@lobstermail.ai"
  return { address: inbox.address, inbox };
}

// Step 2: poll until a code or magic link arrives
async function catchVerificationEmail(
  inbox: Awaited<ReturnType<typeof provisionSignupInbox>>['inbox'],
  timeoutMs = 60000
) {
  const start = Date.now();

  while (Date.now() - start < timeoutMs) {
    const emails = await inbox.receive();

    if (emails.length > 0) {
      const body = emails[0].text ?? '';
      const code = body.match(/\b\d{4,8}\b/)?.[0];
      const link = body.match(/https?:\/\/[^\s]*(confirm|verify|activate)[^\s]*/i)?.[0];

      return { code, link, subject: emails[0].subject };
    }

    await new Promise(r => setTimeout(r, 2000));
  }

  throw new Error('No verification email received within timeout');
}

Wrap a full OpenClaw computer use session with these:

const { address, inbox } = await provisionSignupInbox('linear-signup');

await openclaw.agent({
  message: `Sign up for Linear using the email address ${address}.
            After submitting the form, call the wait_for_verification tool
            and use the returned code or link to complete signup.`,
  tools: {
    wait_for_verification: async () => catchVerificationEmail(inbox),
  },
  computerUse: true,
  thinking: 'high',
});

The agent fills the form with the LobsterMail address, submits it, calls wait_for_verification, gets the code back, and continues. The session never pauses for human input.

Tip

createSmartInbox() generates a readable address from the name you pass in and handles collisions automatically — if linear-signup is taken, it tries variations. Use descriptive names so your logs stay readable when you're running multiple sessions.

Running sessions without watching them#

The handoff pattern pays off most when you take yourself out of the picture entirely. OpenClaw's daemon mode handles this:

openclaw onboard --install-daemon
openclaw gateway --port 18789 --verbose

With the daemon running, you trigger sessions from a cron job or an orchestration script. Each session provisions its own inbox at startup, catches its own codes, and completes without surfacing a "waiting on human" state anywhere in the loop. You check finished results rather than monitoring individual verification steps.

For chained workflows — sign up for service A, authenticate with it, use those credentials on service B, extract data from both — each step gets a dedicated inbox. No address reuse, no ambiguous codes landing in a shared inbox, no cross-contamination between sessions.

Patterns this enables beyond verification#

Autonomous email access opens up more than just signup flows.

Human approval gates. Before the agent takes an irreversible action — sending a message, making a purchase, deleting records — have it email your personal inbox and poll for a reply using the same inbox.receive() loop you already set up. Your reply is the signal. This is the lowest-friction human-in-the-loop implementation I know of, and it requires zero additional infrastructure. More patterns like this in what agents do with email.

Coordinated multi-agent sessions. Two OpenClaw instances can coordinate asynchronously through LobsterMail inboxes. Instance A finishes a browser research task and emails findings to instance B's address. Instance B picks them up on its next scheduled run. Slower than a direct API call, but emails persist across restarts and you get a readable record of everything that passed between agents. See scheduling meetings and tasks with agent email for more coordination patterns.

Digest from authenticated sources. OpenClaw logs into dashboards on a schedule, extracts the metrics or data you care about, and emails a summary to your personal inbox from its own LobsterMail address. No webhook setup, no custom reporting pipeline. One agent, one cron schedule, one email in your inbox each morning.

Each of these patterns builds on the same two functions from this guide. Once you have inbox provisioning and the receive loop in your agent's toolkit, the coordination patterns are just about connecting the steps differently.

If you want to go from zero to a working inbox in under a minute, the LobsterMail quickstart for OpenClaw agents covers the fastest path end to end.


Give your agent its own inbox. Get started with LobsterMail — it's free.

Frequently asked questions

Does LobsterMail require any manual account setup to use with OpenClaw?

No. LobsterMail.create() provisions a free account on first run and saves the token locally. Your agent handles the entire setup step — no human signup required.

What happens if the verification email never arrives?

The polling function throws after your configured timeout. You can catch that error and have the agent retry the signup with a fresh inbox, or mark the session as needing manual review. Setting a reasonable timeout (60 seconds) catches most legitimate delays while surfacing real failures quickly.

Will services reject the @lobstermail.ai domain as disposable?

Some aggressive spam filters block known disposable domains. For services with strict email validation, a custom domain is the cleaner solution. For most SaaS signups and API trials, @lobstermail.ai passes without issue.

How fast is inbox provisioning?

Under a second. createSmartInbox() returns immediately and the address can receive email as soon as the call completes — there's no warm-up period.

Can I run multiple computer use sessions in parallel, each with its own inbox?

Yes. Each call to createSmartInbox() returns an independent inbox with its own address. Parallel sessions poll separate inboxes, so verification codes never land in the wrong place.

What if the service sends a magic link instead of a numeric code?

The catchVerificationEmail function in this guide extracts both. It looks for numeric codes and for URLs containing "confirm", "verify", or "activate". The agent receives whichever form the email contains.

Is there a cost to run this?

The free tier covers 1,000 emails per month with no credit card required. For most agent computer use workflows — including running these verification handoffs regularly — the free tier is enough.

What's the difference between createInbox() and createSmartInbox()?

createSmartInbox() generates a readable address from a name you provide, with automatic collision handling. createInbox() gives you a random address like lobster-xxxx@lobstermail.ai. For workflows where you want recognizable addresses in logs, createSmartInbox() is the better choice.

Can the agent reuse the same inbox across multiple sessions?

Yes. Persist the inbox reference between runs and call receive() on the same address. For signup workflows, a fresh inbox per session keeps verification emails unambiguous. For coordination or monitoring workflows, a persistent inbox makes more sense.

Does LobsterMail work if OpenClaw is running as a background daemon?

Yes. The SDK loads the persisted token on each LobsterMail.create() call and doesn't require a persistent connection on the LobsterMail side. It works the same whether it's running in a foreground terminal or a background daemon.

Does LobsterMail protect against prompt injection in emails?

Yes. Every email returned by the SDK includes security metadata and an injection risk score. If you're passing email body content to your agent, you can inspect the risk score before acting on it. The security and injection guide covers the full protection model.

What OpenClaw version is required for computer use?

Computer use is available in current OpenClaw builds. Check the OpenClaw GitHub repo for the minimum version that ships with the --computerUse flag stable on your platform.

Related posts