Testing logged-in flows used to mean one of two things: either your AI agent logs in every time (slow, flaky, burns credits on the login page), or you hardcode test credentials and hope they don't expire mid-run.

Neither is great. So we added cookie injection.

What this solves

You give us the session cookies, we inject them into the browser before the test starts. The AI agent lands directly in the authenticated state. No login forms, no 2FA prompts, no CAPTCHA battles.

Works for:

Session cookies - Test logged-in user journeys
Auth tokens - Access protected API endpoints
Feature flags - Test specific variations
Bypass tokens - Skip rate limiting during tests

Three levels of configuration

Cookies cascade from broad to specific:

Project → Test Plan → Runtime (API)

Each level overrides the one before it. Same cookie name + domain at a later level wins.

Project level - Shared auth for all test plans in a project. Set it once, all tests inherit it.

Test plan level - Overrides for specific tests. Maybe one test plan needs admin cookies while others use regular user auth.

Runtime level - Pass cookies in the API call. Perfect for CI where you generate fresh tokens per run.

Setting it up in the dashboard

Project-wide cookies

Go to Projects, edit your project, expand Advanced Settings, and add your cookies there. Every test plan in that project automatically gets them.

Test plan cookies

Same deal, but in Test Plans. Anything you add here overrides project-level cookies with the same name.

The UI shows a badge when cookies are inherited from the project, so you know what's already in play.

Dynamic cookies via API

This is where it gets interesting for CI/CD. Generate fresh auth tokens in your pipeline and pass them at runtime:

curl -X POST https://test-lab.ai/api/v1/run \
  -H "Authorization: Bearer $TESTLAB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "testPlanId": 123,
    "cookies": [
      {
        "name": "session",
        "value": "fresh_token_from_ci",
        "domain": ".myapp.com"
      }
    ]
  }'

Runtime cookies override everything. Your CI pipeline can authenticate however it wants, grab the token, and pass it to Test-Lab.

GitHub Actions example

Here's the pattern we've seen work well:

- name: Get auth token
  id: auth
  run: |
    TOKEN=$(curl -X POST https://myapp.com/api/login \
      -d '{"email":"test@example.com","password":"${{ secrets.TEST_PASSWORD }}"}' \
      | jq -r '.token')
    echo "token=$TOKEN" >> $GITHUB_OUTPUT

- name: Run Test-Lab
  run: |
    curl -X POST https://test-lab.ai/api/v1/run \
      -H "Authorization: Bearer ${{ secrets.TESTLAB_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d '{
        "testPlanId": 123,
        "buildId": "${{ github.sha }}",
        "cookies": [
          {
            "name": "auth_token",
            "value": "${{ steps.auth.outputs.token }}",
            "domain": ".myapp.com"
          }
        ]
      }'

Fresh tokens every run. No stale sessions. No shared test accounts that randomly get logged out.

The domain field controls which URLs receive the cookie. This is where most auth issues come from.

With the leading dot (.example.com):

Cookie is sent to the root domain AND all subdomains
example.com ✓
www.example.com ✓
app.example.com ✓
api.staging.example.com ✓

Without the leading dot (example.com):

Cookie is sent ONLY to that exact domain
example.com ✓
www.example.com ✗
app.example.com ✗

Most apps use subdomains (www., app., api.), so always use the leading dot unless you have a specific reason not to.

{
  "name": "session",
  "value": "abc123",
  "domain": ".myapp.com"  // ← covers all subdomains
}

If your test navigates from myapp.com to app.myapp.com and suddenly loses auth, the domain is wrong.

Why not just let AI log in?

You can. It works. But:

Credits - Login flows burn through tokens. If you're running 20 tests, that's 20 logins.
Speed - Cookie injection is instant. Login flows add 10-30 seconds per test.
Reliability - Some login flows have CAPTCHAs, rate limits, or 2FA. Cookie injection bypasses all of that.
Test isolation - You're testing your app, not your auth provider.

For quick smoke tests, AI login is fine. For anything running at scale or in CI, cookie injection is the way.

If you've got specific auth scenarios that are tricky to test, let us know. We're building this based on real workflows.

Full docs at /docs/cookies with more examples and troubleshooting tips.

Test Authenticated Flows with Cookie Injection