Identity and state

Reuse browser state across Sessions

Store cookies and local storage in a persistent Context for reuse in later Sessions, reducing repeated logins across automation tasks.

Example · reuse browser state in a new Session

Integration options

Prerequisite:
Fetch and fully execute the official Lexmount Setup Prompt returned by https://browser.lexmount.cn/api/agent-setup/browser-cli.
Continue only after installation, authentication, and environment validation all pass; otherwise stop and report the failure truthfully.

Task:
Use browser-cli only to complete one public demo login at https://www.saucedemo.com/, then create a new Lexmount Cloud Browser Session with the same persistent Context and verify that the authenticated state is reused across Sessions.

Execution:
1. Create a persistent Context and Session 1. Confirm that the login page displays the public demo username standard_user and password secret_sauce, enter those values, and submit the form.
2. Confirm that the final URL pathname is /inventory.html and that [data-test="inventory-container"] is visible, then close Session 1 without logging out.
3. Wait until the Context is available again. Create Session 2 with the same Context, open https://www.saucedemo.com/inventory.html directly, and confirm that the page does not return to the login form and that [data-test="inventory-container"] remains visible.
4. Save the Context reference, authenticated URL, origin, and ownership metadata to .lexmount/persistent-login-state.json. Do not save login values, cookies, or browser storage. If the file already exists, append a UTC timestamp instead of overwriting it.
5. Close Session 2 and retain the Context.
6. Never request or use real credentials. If human verification unexpectedly appears, hand control to the user only through Remote View.

Acceptance:
Both Sessions must use the same Context, Session 2 must retain the authenticated state without another login, both Sessions must close successfully, and the Context must remain reusable. The generated state JSON must be available as a clickable file in the final Codex response. Otherwise report failure or partial success truthfully.

Cleanup:
On success, failure, timeout, or cancellation, close only the Sessions created by this task and retain the Context. Never close a pre-existing Session or Context.

Return:
Report only the status, authenticated URL, cross-Session verification result, state file path, Context availability, cleanup result, and sanitized error summary, then provide the generated state JSON file as the final item. Do not expose API keys, Project IDs, Context IDs, Session IDs, connect URLs, WebSocket URLs, login values, cookies, or browser storage.

Integration options

Prerequisite:
Fetch and fully execute the official Lexmount Setup Prompt returned by https://browser.lexmount.cn/api/agent-setup/browser-cli.
Continue only after installation, authentication, and environment validation all pass; otherwise stop and report the failure truthfully.

Task:
Use browser-cli only to complete one public demo login at https://www.saucedemo.com/, then create a new Lexmount Cloud Browser Session with the same persistent Context and verify that the authenticated state is reused across Sessions.

Execution:
1. Create a persistent Context and Session 1. Confirm that the login page displays the public demo username standard_user and password secret_sauce, enter those values, and submit the form.
2. Confirm that the final URL pathname is /inventory.html and that [data-test="inventory-container"] is visible, then close Session 1 without logging out.
3. Wait until the Context is available again. Create Session 2 with the same Context, open https://www.saucedemo.com/inventory.html directly, and confirm that the page does not return to the login form and that [data-test="inventory-container"] remains visible.
4. Save the Context reference, authenticated URL, origin, and ownership metadata to .lexmount/persistent-login-state.json. Do not save login values, cookies, or browser storage. If the file already exists, append a UTC timestamp instead of overwriting it.
5. Close Session 2 and retain the Context.
6. Never request or use real credentials. If human verification unexpectedly appears, hand control to the user only through Remote View.

Acceptance:
Both Sessions must use the same Context, Session 2 must retain the authenticated state without another login, both Sessions must close successfully, and the Context must remain reusable. The generated state JSON must be available as a clickable file in the final Codex response. Otherwise report failure or partial success truthfully.

Cleanup:
On success, failure, timeout, or cancellation, close only the Sessions created by this task and retain the Context. Never close a pre-existing Session or Context.

Return:
Report only the status, authenticated URL, cross-Session verification result, state file path, Context availability, cleanup result, and sanitized error summary, then provide the generated state JSON file as the final item. Do not expose API keys, Project IDs, Context IDs, Session IDs, connect URLs, WebSocket URLs, login values, cookies, or browser storage.