Log In Once, Trawl Replays Your Session

Log in once, and Trawl replays your session

Some pages only exist once you are signed in. From this release you can hand a scraper your own browser session: one command opens a real Chrome window, you log in there as yourself, and Trawl replays that session on every run afterwards.

A run that still lands on a login page is now named as one, rather than reported as an empty result with a message about selectors. Live as API v2.5.0, web app v2.10.1, worker 1.4.0 and CLI 3.12.3.

A run that hits a login page now says so

Trawl reads the URL the browser actually ended on. If that is a login route, the run is filed as a login wall instead of an empty result, and the message says what it thinks is going on: this looks like a login redirect, and your own session is the likely fix. It is worded as a hypothesis, because on some sites a valid session is still not enough.

Automatic repair stands aside on those runs. There is no selector to fix on a login form, so guessing at one costs you money for nothing. One case we measured before the fix burned 96,000 tokens and 12 minutes on four candidate repairs, all of them dead on arrival. In our own data this was rare and expensive: 6 of 147 empty runs over 90 days were login walls, across two scrapers, and the message was wrong on every one of them.

Capture your session in one command

The remedy is a single command. A real Chrome window opens at the scraper's target page, you sign in exactly as you normally would, 2FA included, and you press Enter back in the terminal. The CLI reads the resulting session, cookies and local storage both, and uploads it.

Adding --json reports what was captured, never the session itself:

$ trawl scraps account session capture 6a9abafadaf706281f641ba4 --json

{
  "account": {
    "hasSession": true,
    "sessionSavedAt": "2026-09-08T09:12:41.208Z"
  },
  "targetDomain": "app.example.com",
  "capture": {
    "cookiesCaptured": 14,
    "cookiesDroppedOutOfScope": 31,
    "originsCaptured": 1,
    "closedEarly": false
  }
}

You stay authenticated as yourself the whole way through, and with capture Trawl never sees your password, only the session that comes out of it. Responsibility for lawful use of that session stays with you, and none of this is legal advice. Everything uploaded is scoped to the scraper's own domain, encrypted at rest, and kept for 30 days before it is cleared automatically.

Point one at a page you can only see when signed in: try Trawl.

Replayed before the first page loads

The captured session is applied by the worker before your script's first navigation, not somewhere in the middle of it. Cookies go onto the browser context, so every page and popup the script opens afterwards already carries them, and local storage is seeded per origin. Scripts that used to restore cookies by hand can drop that step.

An account can now be session only, with no username or password stored at all. That is exactly what capture produces, and it reaches the worker like any other account. When a session was genuinely replayed, the run carries a Session chip in the run list and on the run detail, so you can tell a signed-in run from an anonymous one at a glance.

What a session does not fix

A fresh session is the right first move on a page asking you to log in. It is not a guarantee. Some sites also object to where the request comes from, and a session replayed from a datacenter address gets refused on its own merits; the lever there is the proxy tier, not the cookies. Sites that rebuild the page from an authenticated background call can still come back empty with a perfectly good session. Trawl says likely, and means it. For the wider picture of why runs fail, we wrote up what actually breaks a scraper in production.

If you build with an agent or the API

Skip this if you only use the app.

• 🔗 API · Upload a session without the browser: PUT /api/scraps/:id/account/session takes a cookie array or a { cookies, origins } file, and validates it at ingest, so a malformed cookie is a clear 422 instead of a run that silently fails to sign in.
• ⌨️ CLI · A scripted path for CI: trawl scraps account session set <id> -c cookies.json uploads a session you already have, for the machines where no browser can open.
• ⌨️ CLI · Diagnosis leads with the remedy: trawl scraps doctor <id> names the login wall and hands you the capture command for that scraper, instead of the old verdict that called it unbeatable.
• ⌨️ CLI · Agents can find the manual: the machine contract and the error envelopes now carry the documentation URL, so an agent that hits a wall can read the page about it rather than improvise. The Claude skills bootstrap themselves on trawl login.

Also in this round

• ⚙️ Platform · A repair counts as applied only when it worked: a fix is recorded as applied when the re-run actually brought data back, not when the patch was merely written. The safety limit that pauses repeated repairs now counts real recoveries.
• ⚙️ Platform · Candidate repairs are tested honestly: a dry run now uses the same proxy tier as the run that failed, so a candidate cannot look good on an easier route than the one it will live on.
• ⚙️ Platform · Public guides: login walls, automatic session replay and capture are documented, including the parts that are not flattering.

A page you can only read when signed in was never going to work anonymously. Trawl now names what it hit, tells you the one move that usually helps, and stops paying an AI to repair a login form. The previous release taught it to notice a scraper that keeps failing; this one teaches it to say why.

Written by Pierre | September 2026