Browser
Drive the external product
Fill forms, trigger the message, enter the code, and assert the resulting UI state through the browser automation framework.
Built for browser automation
Let the browser agent cross the email verification boundary safely.
Keep web interaction in the browser and mailbox retrieval in a scoped tool, then join them through a code or confirmation link.
Direct answer
Browser automation needs an external inbox when the tested site sends a code, magic link, invitation, or confirmation email. mails0 gives the automation a dedicated address and a separate retrieval tool, so the browser does not need to open a human webmail account or share broad OAuth credentials.
Decision map
The browser and the inbox should be separate tools
- 01Drive the external product
Fill forms, trigger the message, enter the code, and assert the resulting UI state through the browser automation framework.
- 02Retrieve only expected mail
Use a scoped CLI, API, SDK, or MCP tool to wait for the message instead of logging into a personal webmail page.
- 03Bind both sides to one run
Track the recipient and trigger time so the automation can prove which message belongs to which browser session.
Tool separation
The browser and the inbox should be separate tools
Mailbox
Retrieve only expected mail
Use a scoped CLI, API, SDK, or MCP tool to wait for the message instead of logging into a personal webmail page.
Coordinator
Bind both sides to one run
Track the recipient and trigger time so the automation can prove which message belongs to which browser session.
Automation sequence
A safe browser-to-inbox handoff
-
01
Create the mailbox before navigation
Acquire the address and credential first so the browser task does not block on identity setup mid-form.
-
02
Submit the address on the target site
Complete the form and capture the pending or confirmation state before checking mail.
-
03
Wait outside the browser
Use the mailbox tool with a deadline and expected recipient rather than scraping another browser tab.
-
04
Validate the payload
Confirm sender context and restrict confirmation links to expected HTTPS hosts before navigating.
-
05
Finish and assert
Enter the code or open the link, then assert the verified application state and clean up test state.
Playwright companion command
mails code --to "$TEST_EMAIL" --timeout 60Risk controls
Browser agents amplify untrusted email content
An email can direct a browser to any URL. A test or autonomous agent that follows links without validation can leave the intended site, expose session state, or execute an attacker-controlled workflow.
Treat the inbox result as data. Parse the link, require HTTPS, compare the hostname with the expected service, and preserve a human approval step when the action affects a real account or external system.
- Do not allow arbitrary links from unrelated senders.
- Use disposable test accounts and non-production environments.
- Keep browser cookies separate from personal sessions.
- Capture screenshots and message IDs on failure without storing full sensitive content broadly.
Use-case map
Common browser-email patterns
| Pattern | Mailbox result | Browser assertion |
|---|---|---|
| Numeric OTP | Extract current code. | Code is accepted and verification state appears. |
| Magic link | Retrieve and validate expected-host URL. | Navigation establishes only the intended session. |
| Invitation | Read organization, inviter, and link. | Correct account joins the intended tenant. |
| Password reset | Retrieve single-use reset link. | Password changes and old link no longer works. |
| Approval email | Extract approved or rejected state. | Browser reflects the same workflow outcome. |
Implementation judgment
A browser run should leave evidence, not uncertainty
Keep the trigger timestamp, recipient, selected message ID, extracted value, navigation target, and final application state together in the test result. This makes a failed run diagnosable without preserving sensitive mailbox content or relying on a screenshot alone.
Evidence
Sources and product scope
Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.
- mails0 source repositoryImplementation, license, and deployment source
- Playwright official documentationBrowser automation framework
- mails0 Playwright guideEmail verification workflow
Questions and answers
Questions that come up in practice
Can Playwright read email directly?
Playwright controls browsers, not mailboxes. Pair it with an email API, SDK, CLI, or MCP tool so the test can retrieve the message outside the browser.
Why not automate Gmail in another tab?
A human Gmail session exposes unrelated mail and adds fragile UI automation. A scoped test inbox is smaller, safer, and easier to reset.
How should an agent handle magic links?
Parse the URL, require HTTPS, verify the expected hostname and path, then navigate in an isolated browser context. Do not follow arbitrary inbound links.
Can a temporary mailbox receive a verification email?
Yes. The hosted provisional mailbox is designed for receive-only first-run workflows such as codes and confirmation links.
Start with a bounded inbox
Give the agent an inbox, then prove the workflow.
Start with a receive-only temporary mailbox. Move to a permanent identity or self-hosted deployment only after the workflow reaches a real email value event.