A browser job needs more than a remembered window name. When several agents or scheduled tasks use the same browser, the application needs to know which task opened each live session, whether that session still exists, and who is allowed to close it.
Our browser automation sessions guide explains the distinction between a task session and a browser identity. This post turns that model into an operating checklist for an Agent-assisted workflow. It is not a claim that a session name remains valid across restarts or that separate sessions create separate accounts.
Keep identity separate from the task window
In BrowserAct, multiple sessions on one browser share browser-level login state while keeping navigation and live task context separate. Use a new task session for independent work under the same approved identity. If the identity must differ, choose the appropriate separately configured browser instead of assuming a new session isolates cookies.
That distinction matters during recovery. A missing session means the runtime handle is unavailable. It does not by itself establish that the browser profile disappeared, that an account logged out, or that another identity should be used.
A saved session name is a reference to something that may be live, not a guarantee that the underlying window still exists.
Record what your job actually opened
Keep a small application-side record with the job reference, approved browser reference, session name, creation time and current lifecycle state. Record creation from the actual command result, rather than discovering a convenient existing session and claiming it as your own.
For an Agent workflow, the conversation's tool-call history is also evidence of ownership. A session appearing in an inventory does not establish that this job created it. Treat the inventory as a view of runtime availability, then combine it with the ownership record before deciding what to operate.
Use task-specific names so two concurrent jobs are less likely to collide. Avoid putting customer secrets or credentials into session names; those names can appear in logs and command output.
Open, inspect, act and verify
The following is a command skeleton with placeholders. Replace the browser ID with an existing authorized browser. The click target must come from the current state output, interpreted by the Agent.
browser-act --session invoice-check-A browser open <existing-browser-id> https://example.com
browser-act --session invoice-check-A state
browser-act --session invoice-check-A click <current-index>
browser-act --session invoice-check-A state
The element index belongs to that state snapshot. After navigation, a click or another page change, inspect the current state before choosing the next target. Do not save an old index as a reusable selector or use shell text matching as a substitute for deciding which control is correct.
A reusable Agent procedure can preserve the target meaning, such as the relevant invoice row or a Download control. It should still let the Agent inspect the page and resolve the current control at execution time.
Recover from evidence, not from the name alone
Before resuming a stored session reference, check the live runtime and your own creation record. If your session still exists, continue in it rather than reopening the same name as though it were new.
If it is unavailable, determine whether opening a new owned session on the same approved browser is appropriate. Then inspect the resulting account and page state. Do not treat the recovery as permission to close unrelated sessions or switch to a different person's account.
If another job owns the matching session, leave it alone. Independent task windows are useful precisely because recovery in one job should not interrupt another job's navigation or unfinished form.
Close only the resources you own
When your work is complete and no user handoff remains, close the session your job opened:
browser-act session close invoice-check-A
Record the close result. If cleanup fails, retain the session reference and error so a later operator can distinguish an orphaned resource from an intentionally active handoff. An unconditional cleanup of every session in an inventory creates a much larger failure than one unfinished job.
This procedure still requires Agent judgment about the current page, ownership and outcome. Packaging it as a Skill makes that judgment reusable; it does not turn the procedure into a standalone unattended script. Keep the lifecycle record, page evidence and business result distinct so the next run can continue from facts instead of assumptions.
Top comments (0)