Skip to content
SceneRecap

Signed-in sessions

Our agent never types a password. When the flow you want checked, kept up to date or reproduced is behind a sign-in, you sign in yourself, in your own browser, on a test account, and hand us that browser’s session for that one site.

First, show us the site is yours

A session can only be added for a site your workspace has proven it controls. On Dashboard > Signed-in sessions, add the site and we give you a token. Serve it as a plain text file at https://your-site/.well-known/scenerecap-verification.txt and press Verify. A site already listed on one of your reporting-widget site keys counts too. We check again every time a session is used, so removing the file or the site key stops every run that relies on it.

Exporting a session

Sign in to the test account in a browser that Playwright controls, then save its storage state. With Playwright installed, this is the whole script:

import { chromium } from "playwright";
const browser = await chromium.launch({ headless: false });
const context = await browser.newContext();
await (await context.newPage()).goto("https://staging.example.com/login");
// sign in to the TEST account in the window, then come back and press Enter
await new Promise((r) => process.stdin.once("data", r));
await context.storageState({ path: "session.json" });
await browser.close();

Paste the file on Dashboard > Signed-in sessions, then delete it. We keep only that site’s cookies and storage and drop the rest. The SceneRecap command line will do this in one step (scenerecap session export) once it is published.

Use a test account

  • Never a real person’s account. Create one for this, with only the access the flow needs.
  • Our runs act as that account in your product: clicks are real clicks. Point them at staging where you can, and keep anything that sends, pays or deletes out of the flows you attach a session to.
  • Screenshots and videos from these runs show what that account sees.

How a session is handled

  • We never ask for a password. You sign in yourself. A session that appears to contain one (a value named like a password, a form-encoded or Basic credential) is refused, not stored. It is a check on the ordinary ways a page keeps a password, so export from a fresh sign-in rather than from a browser with saved form data.
  • One site. A session works only for the exact origin it was added for, and its cookies are pinned to that host. A signed-in run that is sent to another site stops before it acts there, and never reads that page.
  • Encrypted and write-only. It is encrypted at rest. Nobody can read it back, including you: the dashboard shows its name, its site, when it expires and when it was last used.
  • Used only by the browser that runs the flow. The session itself is never written to logs, prompts, exports, webhooks or job queues. What that browser sees while signed in (screenshots, the page’s text) is used the way any run’s is, including by our AI provider for the analysis.
  • Short-lived. You choose an expiry of up to 30 days. A week before, we email you. At expiry we wipe it, and runs that relied on it end as blocked with “session expired”.
  • Revocable. Revoke it on the dashboard at any time, even if the feature is later switched off; it is deleted from our database at once (encrypted database backups expire on their own schedule), and runs that used it end as blocked, saying so. A run already under way finishes with it.

Attaching one

Checks, living tutorials and Repro Agent runs have a Signed-in session picker that lists the sessions for their origin. Only a workspace admin can add, attach or revoke one. Signed-in sessions are available on Pro and up.

What it is not

  • It does not sign in for you. When a session expires, a person signs in again and exports a fresh one.
  • It does not get past steps that ask for a code during the flow itself (a one-time code, a CAPTCHA). Those still end as blocked.