Check the browser session before the agent starts

A browser agent can click every control correctly and still do the wrong job. It might be signed into the wrong account, looking at the wrong workspace, or using a session that expires halfway through the task.

Before debugging selectors or changing the prompt, verify the session the agent will actually use. The procedure below is a proposed preflight for authenticated browser work. It does not depend on a particular agent provider.

Define the destination

Write down the application, account, workspace, and permitted action. For example:

In the staging support workspace, open the fixture ticket named Session Check. Add a draft internal note. Do not send a customer reply or change the ticket status.

Use a disposable fixture that your team is authorized to modify. An account with suitable limits makes mistakes easier to contain. The task brief still matters: access to a control does not mean the task calls for using it.

Inspect the agent's browser

Open the account or workspace indicator in the session the agent will operate. Confirm the destination against the brief. Do not infer identity from a familiar landing page or from the account open in your own separate browser.

Navigate to the fixture. Check that the agent can see the expected record and the required action. If either is missing, investigate account selection, workspace membership, or permissions before asking the agent to work around the problem.

An empty list and an access error require different responses. Capture enough evidence to tell them apart without retaining unnecessary customer data.

Treat saved state as access material

Playwright's authentication documentation warns that saved browser state can contain sensitive material usable to impersonate an account. It recommends keeping that state out of repositories, including private repositories.

For an agent workflow, decide where authentication state is stored, who can retrieve it, and how it is invalidated. Do not attach the state file to a debugging issue. Use an approved authentication flow when the session must be renewed.

Browser isolation also needs a practical check. Two sessions can still operate on the same server-side records. Playwright recommends a separate account per parallel worker when tests modify shared server-side state. Distinct records within one account do not isolate account-level settings. Use independent accounts for those tests or run them sequentially.

Saved state is not necessarily the whole session. Playwright's storage-state mechanism does not persist session storage; verify the authentication mechanism your application actually uses.

Run one complete task

Have the agent create the fixture's draft note. Read it back in the intended ticket. Confirm the text and confirm that the ticket status did not change.

Then test an expired session in a controlled environment. A useful recovery result is an explicit authentication blocker followed by a verified continuation after reauthentication. The agent should recheck the account and workspace before resuming a write.

If the draft was created before the interruption, recovery should find it rather than create another copy. This is the same uncertain-outcome problem that appears in API integrations.

Keep the preflight small

Record the verified account label, workspace, fixture, observation time, and result. Do not record cookies or tokens. Repeat the check when credentials, permissions, or the browser execution environment changes.

You now have a concrete baseline: the agent can reach the correct destination, perform one bounded action, and recognize when authentication is unavailable. Expand from that baseline using Put a browser agent to work.