- Treat 2FA as a one-time setup cost, not a per-run tax: authenticate once with a human present, then persist the session for recurring automation.
- One-time codes come through a few channels — an authenticator app, a text message, an email, or a magic link — but they all funnel into the same design pattern: a human, or a securely vaulted credential, clears the challenge, and the resulting session is what the automation reuses.
- Re-auth should be the exception path, triggered by session expiry or a forced device check, not the default path for every scheduled run.
- Airtop's authenticated cloud browsing keeps credentials and sessions in a secure vault per workspace, so agents can log in and stay logged in without exposing secrets in code or logs.
- Building or documenting a 2FA bypass is off the table. The durable-session approach keeps automation compliant with the account owner's own MFA policy.
You automate a nightly CRM export with Claude and a workflow tool. During the demo you watch the login, grab the authenticator code from your phone, paste it in, and the export finishes. You schedule it for overnight. The run stops on "verify it's you," and nobody is awake to paste a code. By morning the queue is empty and someone has to run it by hand again.
That is a common first design: log in fresh every time because it is easy to build. The same wall shows up on ad platforms and finance portals, and it shows up again on internal admin tools. Each site has its own 2FA path and timeout, but the fix is the same: clear the challenge once, save the session, and only bring a person back when the session actually expires.
This article covers why login-every-run designs break, how durable sessions work for one-time codes across channels, how to hand off rare re-auth cleanly, and how Airtop approaches authenticated cloud browsing without bypassing MFA.
Why 2FA breaks naive browser automation
A workflow tool logs into a CRM or ad platform on a schedule, hits a "verify it's you" prompt, and stalls. Someone opens a phone, grabs a code, and pastes it in by hand. Multiply that by every portal and every run, and the automation stops saving time.
This is the pattern most teams fall into without meaning to. They wire up a script that logs in fresh each time, because that's the simplest thing to build first. It works in a demo. It falls apart the moment the schedule runs unattended and nobody's there to paste in a code.
The failure gets worse at the authentication step specifically. Login pages and 2FA challenges are where sites watch hardest for bot-like behavior: a new device with no cookie history, paired with a script-shaped click pattern. A workflow that re-solves 2FA on every run looks, to the site, like a new suspicious login each time. That's the opposite of what you want from something meant to run unattended.
Design login as saved state. If every run has to pass 2FA again, someone has to be available for codes, and the schedule cannot stay fully unattended. Treating login as a step to repeat also means every failure mode compounds: a flaky network or a slower-than-usual page load can knock the login step over, and each one triggers the same manual rescue.
The durable-session model: solve it once, persist it
Asessionis the bundle of cookies, tokens, and device-trust signals a site uses to recognize a browser it has already verified. Once you clear a 2FA challenge from a given browser, most sites won't ask again from that same browser for days or weeks.
Airtop reuses earlier work in two different places. Compiling the workflow once removes repeated planning. Saving the authenticated session once removes repeated 2FA. Both reduce later run cost, but they are not the same mechanism. The first login is hard. The later logins, on the same authenticated browser, should usually be uneventful. Airtop's broader framing for reusing solved work appears in deterministic AI and the agency spectrum.
Persisted sessions beat re-solving every run for two reasons. First, they remove the human from the loop for routine runs. Second, they keep the automation's login pattern looking like what it is: the same trusted browser returning, instead of a fresh unverified device showing up on a schedule.
A persisted session means the automation can run at any hour, on any cadence, without waiting on someone to be near their phone. A nightly sync or a weekly export can run unattended once the session is established, and so can an hourly check on a lead form, because the hard part already happened once, with a person watching.
Handling the three common 2FA types
Most 2FA challenges you'll meet in GTM and ops tooling reduce to a couple of patterns: codes generated on a device, like TOTP, and codes delivered to a channel, like SMS, email, or magic links. Each one leads to the same design pattern once you strip away the delivery mechanism.
"TOTP"("time-based one-time password"), the six-digit code from an authenticator app, can come from a seed stored in a vault and generate the code at login time without a person reading a phone. Use that code to establish the session once, then reuse the saved session on later runs whenever the site still trusts it. Nothing has to wait on a device receiving a message at the right moment, which makes TOTP the most direct of the three to fold into an automated flow.
SMS codesrequire a phone number that can receive a text at the moment of login. This is harder to fully automate safely, which is exactly why persisting the session afterward matters. You want to hit this path as rarely as possible, not on every run. Treat an SMS-gated login as a rare, human-assisted event, then lean on the resulting session for every run in between.
Email codes and magic linkswork the same way as SMS: something has to check an inbox at login time. In every case, the pattern holds. Something clears the challenge once, and the session that results is the reusable asset. The delivery channel doesn't matter; the session does.
Some sites layer a second check on top, like a device-approval prompt inside a mobile app, or a periodic re-verification tied to IP address changes. These extra layers don't change the underlying approach. They just mean the human-assisted event happens slightly more often for that particular site, while the same session-first design still applies.
Keeping a human in the loop, once
Sessions do expire. A site might force a fresh check after a password change, a new IP range, or a routine trust reset. When that happens, re-auth is unavoidable, and the right move is a clean handoff, not a scramble.
Design the handoff before you need it: send an alert that names the portal and the reason, and pair it with a link to a live view of the stuck browser, so a person can step in at a clear point, enter a code, and hand control back. Airtop's approach to agents that recover from broken runs applies the same logic here: the system notices the failure and routes it, instead of quietly retrying into a lockout. Related reliability work, like handling cases where a session dies mid-run, tends to show up in the same workflows as re-auth, and both deserve the same treatment: an expected edge case with a designed path, not a surprise.
A good handoff has a few concrete parts: a clear name for which portal triggered it, a reason if the site gives one, a link to step into the live session, and a way to resume the run once the person clears the check. Build this before the first re-auth event happens, rather than improvising it in the moment.
Re-auth should stay the exception. A concrete signal makes the point: if re-auth is firing on every run, that's a bug in how the session is being persisted, not a reason to add more manual steps to the default path. Treat a spike in re-auth events as something to fix in the session-handling logic, not as a new normal to build around.
How Airtop approaches authenticated cloud browsing
Airtop runs agents in a cloud browser built for this problem, not a local script that loses its cookies every time it restarts. The idea is direct: sign in once, stay signed in. Credentials live in a per-workspace vault, sessions persist alongside them, and agents authenticate against real sites behind logins, 2FA, and SSO without secrets showing up in code or logs.
An operator doesn't need to re-prompt an LLM at every login. Airtop compiles the login flow into a compiled agent that runs like software, reusing the resolved session state instead of reasoning through the same challenge again. That compiled agent then runs as one of Airtop's agents that run on a schedule, with the authentication problem already handled upstream.
For marketers building this without touching code, agents that browse the web, even behind logins is the same capability, described through Mark. And for teams that trigger agents from a coding assistant, it's possible to run agents directly from your terminal, calling an already-authenticated Airtop agent instead of scripting a login from scratch each time.
The login and 2FA problem gets solved once, at setup — and stays solved across whichever surface an operator prefers to work from afterward: a scheduled agent, a no-code builder, or a terminal command.
What not to do
Stay inside the account owner's MFA policy. A person or a vaulted credential should clear the real 2FA check, and the automation should reuse the resulting session. Do not design around bypassing 2FA. Don't scrape one-time codes out of a third-party inbox without the account owner's authorization. If you want to see this pattern in practice, try it for free and watch a session persist across runs instead of resetting on each one.
FAQs
What's the difference between solving 2FA and persisting a session?
Solving 2FA is the one-time act of clearing a challenge, whether that's entering a code, confirming a device, or approving a push. Persisting a session means saving the cookies and tokens that result from that act, so the next run reuses a browser the site already trusts. Teams that only solve 2FA, without persisting the result, end up solving it again on every run.
Can browser automation handle TOTP codes automatically?
As a general mechanic, yes. Because a TOTP code is generated from a stored seed rather than delivered to a device, it can be produced programmatically at login time without a person present. The seed itself becomes the durable credential, and the session that results from using it is what the automation reuses afterward.
Is it safe to store 2FA-authenticated sessions for scheduled agents?
It's safe when the session and any underlying credentials sit in a proper vault, scoped per workspace, and never appear in agent code or logs. Airtop stores both this way, backed by SOC 2 Type II certification and HIPAA compliance, with full run logs and video replay for auditability.
What happens when a site forces re-authentication mid-workflow?
The workflow should stop cleanly and hand off to a person, rather than retry blindly into a lockout. Airtop's agents recover from broken runs, flagging the issue and drafting a fix a person reviews, the same pattern that applies to a forced re-auth: notice the failure, route it to a person, and let that person clear it once.
Does Airtop store my credentials or 2FA secrets?
Airtop stores credentials and sessions in a secure, per-workspace vault built for authenticated cloud browsing. They're never exposed in agent code or logs, and Airtop never uses customer data to train models.
Can Airtop agents read SMS or email codes for me?
Airtop's approach is built around persisting the session that results from clearing a 2FA challenge, not around intercepting one-time codes from SMS or email on your behalf. For SMS and email codes, a human clears the challenge once, and the resulting session is what the agent reuses on later runs.
How do I avoid getting flagged as a bot at the 2FA step?
Stop treating every run as a fresh login. Sites flag new, unrecognized devices hardest at the 2FA step, so the fix is a browser the site already trusts, returning with an intact session, instead of a script showing up unverified on a schedule.
What if I run agents from a coding assistant instead of a no-code tool?
The same durable-session model applies. You can run agents directly from your terminal, calling an already-authenticated Airtop agent for the login and 2FA-gated steps instead of scripting a fresh login sequence from scratch each time.
Try it for free
A practical next step is to create an agent, complete one supervised sign-in, and confirm the session carries into later runs. Start here: Try it for free.
