# Browser Sessions

Save a logged-in browser session per site so scheduled tasks can scrape authenticated
pages without you being present.

## How to add a session

1. Open Settings → ツール設定 → Browser Sessions.
2. Click **Add site session**.
3. Fill in:
   - **Label**: human-readable name (e.g., "My Twitter").
   - **Start URL**: the page that proves you're logged in (e.g., `https://twitter.com/home`).
   - **Logged-in selector** (optional): a CSS selector that only exists when logged in.
   - **Login URL pattern** (optional): a glob that matches the site's login page (e.g., `https://twitter.com/i/flow/login**`).
4. Click **Open login window** — a browser appears inside the dialog.
5. Log in normally. Solve any CAPTCHA / 2FA.
6. Click **Save**. The session is captured, encrypted, and stored.

## How to use a session in a task

When creating a local or scheduled task, pick the saved session from the
**Browser session** dropdown. The agent's `BrowseWeb` calls inside that task
will run with your saved cookies / localStorage.

## Expiry

If the session expires (cookie rotation, password change, etc.) the next task
will fail with `AUTH_SESSION_EXPIRED`, the session will be marked **Expired**
in the settings list, and a comment will be posted on the task notifying you.
Click **Re-login** in the Browser Sessions list to capture a fresh state.

## Security

- Sessions are encrypted with a personal key derived per user. Other users
  cannot read them. Admins can revoke and delete sessions, but cannot decrypt them.
- Sessions are not shared with org / public visibility — they are always bound to
  the task owner.
- Audit logs record every save / use / decrypt with timestamp, actor, and result.

## Limitations (v1)

- Sessions are read-only snapshots — cookie mutations during a task run are NOT
  written back. Sites that rotate refresh tokens on every request may need
  re-login periodically.
- IndexedDB and sessionStorage are not captured by `Playwright.context.storageState`,
  so sites that depend heavily on them may not work.
- One profile, one site. Cross-domain SSO sessions need every involved origin
  visited during the initial login.