Reuse Browser Authentication Across Missions

By default, every mission file starts with a new browser context. This gives strong isolation, but a suite with a login prerequisite may repeat the same password, email-code, or MFA flow for every file.

Use shared authentication for an ordered suite that runs as the same user:

testronaut --session=shared-auth \
  create-document.mission.js \
  search-documents.mission.js

After each mission, the CLI saves the context's Playwright storage state and loads it into the next mission's fresh context. Cookies, local storage, and IndexedDB authentication state are reused; pages, tabs, and in-memory JavaScript state are not. The temporary storage-state file is scoped to that CLI run and removed during normal cleanup. It is not included in reports or report uploads.

Mark a reusable launch protocol

Wrap the existing login prerequisite with launchProtocol(). It remains an ordinary preMission value; the metadata only enables deterministic reuse in a shared-auth run:

import { launchProtocol, runMissions } from "testronaut";

const loginInstructions = `
  Visit ${process.env.URL}.
  Complete the login flow and verify the dashboard heading.
`;

export const loginPrerequisite = launchProtocol(loginInstructions, {
  id: "authenticated:test-user",
  probe: {
    url: process.env.URL,
    selector: "#authenticated-dashboard",
    text: "Documents"
  }
});

export function executeMission() {
  return runMissions({
    preMission: loginPrerequisite,
    mission: "Create a document and verify it appears in the list."
  }, "create document");
}

The first occurrence executes the original instructions. After it passes, later occurrences with the same protocol id navigate to the probe URL and check the selector/text directly in Playwright. A passing probe skips the LLM phase. A failed probe safely falls back to the original login instructions.

Existing strings, functions, arrays, and unwrapped preMission values are fully compatible and continue to execute normally. In isolated mode, launch protocols also execute normally; probes and reuse are disabled.

Use a stable protocol ID for the same account and tenant. Use different IDs when credentials, roles, tenants, or environments represent different prerequisites.

Choose the right mode

Mode	Behavior	Best for
--session=isolated	New unauthenticated context for every mission file	Independent tests and parallel shards
--session=shared-auth	Cookies and local storage flow forward through the ordered run	Sequential suites using one account

isolated is the default. Shared authentication makes mission order meaningful:

• Let the first mission containing the launch protocol establish authentication.
• Put logout last; logging out invalidates state for following missions.
• Do not use one shared-auth state file across parallel workers. Each CLI run creates its own state file, so separate processes remain isolated.
• Do not rely on open tabs, session storage, or unsaved application memory.
• A mission can still intentionally change account or tenant state for every mission that follows it.

Measure the improvement

Run the same ordered files once in each mode:

testronaut --session=isolated create.mission.js search.mission.js
testronaut --session=shared-auth create.mission.js search.mission.js

Compare the JSON reports. Reports include session.mode, total duration, and per-step total/input/output token counts. Also compare login, email-code, MFA, and human-input tool calls. Model runs naturally vary, so use several trials before attributing a small token difference to session reuse.

Each mission-phase result can include launchProtocol metadata with an executed or reused status and the probe outcome.

This browser authentication setting is separate from the Testronaut API sessionToken used for report upload, automated email codes, and stored MFA. --session=shared-auth does not extend or refresh that API token.