How to keep an AI agent signed in between browser runs

Many agent runs start a fresh browser, so the cookies from the last login are gone. Browserbase, for example, starts each session with a fresh user data directory unless you use a Context [3]. The agent then meets the login page, and often the 2FA prompt, again.

A saved session is mostly cookies and local storage. Playwright's docs warn that the browser state file "may contain sensitive cookies and headers that could be used to impersonate you or your test account", and strongly discourage checking it into private or public repositories [1].

Playwright recommends authenticating once in a setup project, saving the state with storageState, and starting each test from that saved state [1].

Browser Use can log in with a real browser profile, export the state with export_storage_state, and load it again with storage_state, for example in headless mode [2].

A Context persists the Chromium user data directory, including cookies, localStorage and IndexedDB, across sessions [3]. With Stagehand on Browserbase, you pass the context id with persist: true [4].

Kernel profiles persist cookies, site data, open tabs and preferences, and are encrypted end to end with a per-organization key. Changes in a browser stay isolated unless you enable save_changes [5].

Steel's contexts endpoint captures and transfers browser state, including cookies and local storage, between sessions [6]. Its Profiles API stores auth, cookies, extensions, credentials and browser settings, with a 300 MB limit, and deletes a profile that has not been used for 30 days [7].

save_session saves cookies and localStorage for one site from the browser, and restore_session puts them back into the browser. Cookie values are not returned [8]. The session is stored encrypted for that identity, next to its logins, codes and log.

Saving and restoring need a CDP address that runnerID can reach: an http, https, ws or wss address, such as a Browserbase connectUrl or a Steel connect URL, and not a loopback or private address [8]. So they do not run on the laptop route.

runnerID keeps a saved session until you save over it, delete it, or revoke the identity. The cookies inside still expire on the site's own schedule. Revoke marks the identity unusable, deletes saved sessions, expires pending approvals, and invalidates outstanding secret tokens, and a revoked identity returns 409 identity_revoked on session creation [8].

• ›If runnerID can reach the browser (a hosted browser or one on your own server): Agents that drive a browser runnerID can reach, such as a hosted browser (Browserbase, Steel) or one on your own server, get the strongest mode: runnerID types the password itself.
• ›If the browser is on your own laptop: When the browser runs on your own laptop, the helper uses its local route: the password passes through your own code once to be typed, and still never reaches the model.
• ›If a hosted agent's browser is out of runnerID's reach: Hosted agents that connect over MCP get authenticator and emailed codes returned to them, and approvals and the log work the same. Typing a password into the page needs the runnerID helper next to the browser (Stagehand, Playwright or Browser Use), on a laptop or in a cloud container.

Tool results never include a password or seed. Only get_email_code and get_authenticator_code return a code, and each release is logged. Authenticator codes are covered in the guide at /guides/authenticator-codes-ai-agents, and keeping the password out of the prompt in /guides/stop-pasting-passwords-into-prompts.

Entries for other tools come from their own pages. Not stated means the page did not say, as of October 24, 2026.

• ›Where the state lives: A state file you choose [1]
• ›How to delete it: Delete the file

• ›Where the state lives: A storage state file or a real browser profile [2]
• ›How to delete it: Delete the file

• ›Where the state lives: A Browserbase Context [3]
• ›How to delete it: Not stated

• ›Where the state lives: A Kernel profile, encrypted with a per-organization key [5]
• ›How to delete it: Not stated

• ›Where the state lives: A Steel context or profile [6][7]
• ›How to delete it: A profile unused for 30 days is deleted [7]

• ›Where the state lives: runnerID, encrypted per identity and site
• ›How to delete it: Delete one site's session, or revoke the identity to delete them all

Keep the seed out of your code; fill_code and get_authenticator_code.

Steel, Kernel, Browserbase with 1Password, and runnerID over a CDP address.

• ›1. Playwright, Authentication: https://playwright.dev/docs/auth
• ›2. Browser Use, Authentication: https://docs.browser-use.com/open-source/customize/browser/authentication
• ›3. Browserbase, Contexts: https://docs.browserbase.com/features/contexts
• ›4. Stagehand, User Data Directory: https://docs.stagehand.dev/v3/best-practices/user-data
• ›5. Kernel, Profiles: https://www.kernel.sh/docs/browsers/profiles
• ›6. Steel, Reusing auth context: https://docs.steel.dev/overview/sessions-api/reusing-auth-context
• ›7. Steel, Profiles API: https://docs.steel.dev/overview/profiles-api/overview
• ›8. runnerID API docs: https://api.runnerid.torchrunner.ai/llms.txt

Playwright, Browser Use, Browserbase, Stagehand, Kernel and Steel belong to their owners. runnerID and Torchrunner are independent and are not affiliated with, endorsed by or sponsored by any of them.