Reuse the login state. Do not publish the secret.

A release suite signs in before every small check. Most of the run is spent waiting for the same login form. Saving authenticated browser state can remove that repetition, but the saved file is not harmless test data. It may contain enough information to act as the test account.

This guide follows Playwright's authentication documentation to make the boundary explicit. The accompanying screenshot is a local fake account screen. No real login, token or customer record was used. The question is how to prepare reusable state safely, not how to bypass an application's authentication policy.

Decide what the suite is allowed to reuse

A test of a profile setting usually needs an authenticated session. It does not necessarily need to exercise the login form again. A test of login itself has a different job: verify the actual authentication flow, rejection behavior and relevant session rules. Reusing state in the first group must not silently erase the second group.

Write those groups down before adding a shortcut. A setup project can perform the approved login and save state; dependent tests can start from that state. The authentication guide shows this pattern. The state must belong to a controlled test identity in an approved environment, with only the privileges the test needs.

// After your approved test-account login has completed:
await expect(page.getByRole('button', { name: 'Sign out' })).toBeVisible();
await page.context().storageState({ path: 'playwright/.auth/user.json' });

The visible button is our illustrative app's readiness contract, not a universal proof that every authentication method has finished. Your application may need a different stable condition. Wait until the session is established before saving it, or the next test may receive incomplete state and produce a confusing failure.

The file belongs outside the repository

Playwright warns that saved browser state can include sensitive cookies and headers usable to impersonate an account. Its documentation discourages committing these files to either private or public repositories. A private repository is still a distribution channel, not a safe credential store.

playwright/.auth/

Ignoring the directory is prevention, not remediation. If a state file has already been committed, removing it from the working tree does not erase earlier revisions. Stop distributing that artifact and follow your organization's credential-exposure process. Do not put a real state file into a tutorial, issue attachment, trace bundle or screenshot to make an explanation more concrete.

Review artifact upload rules as well as source-control rules. A CI job may upload the entire workspace after failure. An ignored file can still enter that archive. Explicitly keep saved login state out of debugging bundles and backups that do not need it. Use test accounts and short-lived access where your environment supports them.

Reuse is not a lifetime promise

Stored state expires. The guide recommends deleting expired state and notes that project output directories are cleaned before runs. Choose a lifecycle that matches the session policy rather than assuming yesterday's file is valid forever. A setup failure should stop dependent checks with a useful reason, not become dozens of unrelated page failures.

Storage mechanisms matter too. Playwright's authentication guide discusses cookies, local storage and other mechanisms, with special handling for session storage. Do not assume every login implementation is captured by the simplest storageState call. Check what your application uses and verify a fresh context can reach the intended authenticated page.

A safe local experiment uses fake state to demonstrate the mechanism. It proves the browser can restore that selected value, not that an identity provider, MFA policy or production session was validated. Keep that distinction in the test report.

Give parallel tests enough independent state

Reusing one account can be reasonable for read-only tests that do not change shared server state. It becomes risky when several tests edit the same preferences or records. Browser context separation does not make the server account separate. Our earlier isolation guide covers that collision; here the practical rule is to match authentication setup to the suite's mutation pattern.

Keep the readiness check, identity scope, storage mechanism, expiry rule and artifact exclusions in a small setup note. That note makes a generated test easier to review. A reviewer can see why login is reused, which login tests still run and where the state is allowed to go.

AnyTest describes agents exploring an app and building end-to-end tests for human review. Apply the same questions to any proposed authenticated journey. This is a review practice, not a claim about AnyTest's credential storage or login configuration. Less repeated setup is useful only when the suite still protects the authentication boundary.