persist_browser_session flag saves sessions but never retrieves them on subsequent runs

[pengu-fr]

Problem

The workflow settings UI provides a "Save & Reuse Browser Session" checkbox, clearly indicating that the expected behavior is to both save and reuse browser sessions across workflow runs. However, while sessions are saved at the end of each run, they are never retrieved on subsequent runs.

This means cookies, localStorage, and login states are lost between workflow executions, defeating the purpose of the feature.

Expected Behavior

When "Save & Reuse Browser Session" is enabled:

1. First run: Browser session is created and saved
2. Subsequent runs: The same browser session is loaded, preserving cookies, localStorage, and authentication state

Actual Behavior

Each workflow run starts with a fresh browser context, ignoring any previously saved session data. The flag only triggers a save operation at the end, but the saved session is never reused.

Related Issues

• Persistent Browser Session Doesn't Work #2110 - Browser session persistence issues
• Persist browser session #1579 - Session management improvements
• Receiving cookies or sessions after the success of the task to log in to the personal account of the site. #3980 - Cookie persistence problems

---

Root Cause Analysis

Issue 1: Sub-workflows don't inherit persist_browser_session

When task_v2 blocks create sub-workflows, they don't inherit the parent workflow's persist_browser_session setting. The browser state is created before the block executes, using the sub-workflow's settings (which default to false).

Issue 2: No mechanism to load existing sessions

Even when persist_browser_session=True, there's no logic to check for and load an existing session directory when launching the browser.

Issue 3: SingletonSocket/Lock file copy errors

When saving browser profiles, Chromium's lock files (SingletonSocket, SingletonLock, SingletonCookie) cause copy errors because they are Unix sockets, not regular files.

---

Solution

1. Propagate persist_browser_session from parent workflows

Check parent workflow for persist_browser_session setting in all 7 call sites where browser state is created:

• skyvern/services/task_v2_service.py (3 locations)
• skyvern/forge/sdk/workflow/models/block.py (2 locations)
• skyvern/forge/agent.py (1 location)
• skyvern/core/script_generations/script_skyvern_page.py (1 location)

2. Create and reuse persistent session directory

Create a stable session directory path based on organization_id and workflow_permanent_id, and pass it to the browser factory to use as user_data_dir. If the directory was manually deleted, it is simply recreated empty and the workflow starts with a fresh session.

3. Skip Chromium lock files when saving

Filter out SingletonSocket, SingletonLock, and SingletonCookie files when copying browser profiles.

---

Test Results

Tested with a workflow that visits a website displaying a cookie consent banner:

• First run: Cookie banner appears and is dismissed
• Second run: Cookie banner does not appear (cookies were preserved)

This confirms the fix correctly saves and restores browser session state across workflow runs.

---

Known Limitations

1. Concurrent runs not supported: Chromium locks the user_data_dir, so only one workflow run can use a persistent session at a time.

2. Not compatible with browser_profile_id: If browser_profile_id is set, persist_browser_session is ignored (browser profiles take precedence).

[skyvern-agent]

For the issue you're experiencing with the persist_browser_session flag not retrieving sessions on subsequent runs, let's break down the points relevant to your situation:

1. Propagation of persist_browser_session: When working with sub-workflows, ensure that the persist_browser_session setting is passed from the parent workflow. This may require checking all relevant code locations to adjust this inheritance [1].

2. Session Loading Logic: Currently, there is no mechanism implemented to check for and load a previously saved session directory when launching the browser. To resolve this, you will need to implement a routine that creates and utilizes a persistent session directory based on identifiers like organization_id and workflow_permanent_id [1].

3. Handling Chromium Lock Files: When saving browser profiles, make sure to filter out the SingletonSocket, SingletonLock, and SingletonCookie to prevent copy errors that arise from these being Unix sockets and not regular files [1].

With these adjustments, your workflow should be able to reuse browser sessions as intended. If you need further assistance or want to see these changes in action, checking out our documentation or booking a demo could be beneficial.

Need another reply? Mention @better-auth-agent in a comment.

Tag @skyvern to trigger a response from the agent

Diagram • Discord • GitHub