BROWSER USE

- Browser Use Agents: give Browser Use a task and receive completed work. API V4 is current for new integrations.
- Browser Infrastructure: connect your agent or automation to managed browsers through SDK, REST, or CDP. Starts at $0.02/browser-hour.
- Developer tools: Open Source, Browser Harness, SDK, and MCP support the two products above.

[Developer Index](https://browser-use.com/index.md)
[Product Map](https://browser-use.com/llms.txt)
[Full Product Context](https://browser-use.com/llms-full.txt)
[Pricing](https://browser-use.com/pricing.md)
[Cloud Docs](https://docs.browser-use.com/cloud/quickstart)
[Open Source Docs](https://docs.browser-use.com/open-source/introduction)

---

# 2FA automation: logins the agent handles on its own

> Automate logins and two-factor codes without a person in the loop. Four ways the agent gets a code: TOTP generated from the secret, emailed codes read from an inbox the run owns, SMS forwarded to that inbox, and 1Password typing username, password and TOTP. Then a saved profile so the site stops asking.

[HTML page](https://browser-use.com/login-automation) · [2FA docs](https://docs.browser-use.com/cloud/guides/2fa) · [1Password and 2FA](https://docs.browser-use.com/cloud/guides/1password) · [Profiles](https://docs.browser-use.com/cloud/guides/authentication) · [Profile sync](https://docs.browser-use.com/cloud/guides/profile-sync)

## Four roads to the code

1. **Authenticator app (TOTP).** Give the agent the TOTP secret (shown as "can't scan the QR code" during 2FA setup) as a `sensitive_data` value whose name ends in `bu_2fa_code`. When the agent types the placeholder, a fresh six-digit code is generated. The model never sees the secret. In Cloud, the TOTP field of a 1Password item does the same.
2. **Emailed code.** Set `agentmail: true` on a V4 run (`POST /api/v4/runs`). The run gets a persistent inbox via AgentMail; the agent knows the address, signs up with it, waits for the verification email, and reads the code. The open-source library does the same with AgentMail tools or the built-in Gmail integration (`browser_use.integrations.gmail`).
3. **SMS code.** Forward the number's texts to an inbox the agent can read (carrier forwarding, Google Voice, or a Twilio number that emails you). From there it is an emailed code.
4. **Password manager.** Pass `opVaultId` and `opVaultAllowedDomains` on a V4 run, or per-field `secretBindings` (alias, source, allowedDomains). The server types username, password or TOTP on the allowed hosts; the model works with aliases, and once typed the value is on the page like any input, so keep bindings scoped to the hosts that need them. Browser Use does not store browser passwords.

## Then stop being asked

Save a profile after the first login and pass `profileId` on later runs (`browser_settings={"profileId": ...}`) or standalone browsers (`{"profileId": ...}` on `POST /api/v4/browsers`). Cookies, localStorage and login state persist, so the site does not challenge again while they are valid. Already logged in on your laptop? `curl -fsSL https://browser-use.com/profile.sh | sh` syncs selected cookies from your Chrome into a cloud profile.

## Keep it contained

`allowed_domains` and `prohibited_domains` limit where a logged-in agent can navigate. `use_vision=False` keeps screenshots of sensitive pages away from the model. Works for Playwright sessions at $0.02 per browser-hour as well as for agent runs.

## When a person is still needed

Push-approval 2FA on a phone you do not control, or a bank that insists on a human. A run can pause at that step and hand the live view to someone; the session continues after.
