Support for authenticated flows (cookie/localStorage injection)

[gabrielgene]

Problem

There's currently no way to test flows that require authentication. Many web apps gate features behind login, so expect-cli can only test public pages. The browser opens without any session and the app redirects to login before reaching the target page.

Suggestion

A few possible approaches:

Option A: Cookie/localStorage injection

expect-cli -m "test the dashboard" \
  --cookie "session=abc123" \
  --local-storage '{"auth-token": "{...}"}' \
  -y

Option B: Auth config file

// expect.config.json
{
  "auth": {
    "localStorage": {
      "auth-token": "..."
    }
  }
}

Option C: Setup script

expect-cli -m "test dashboard" --setup ./scripts/inject-auth.sh -y

Environment

• macOS Darwin 25.3.0 (Apple Silicon)
• Node 24
• expect-cli v0.0.8

[coreyward]

I'm not sure what you chose during setup, but it copies all of your cookies from all of your other browsers if you enable cookies. It's not a very wise approach, but that's what they've done so far.

[gabrielgene]

I use Arc and I want to authenticate as a test user, not the default user of my browser, but I'll check that, thx @coreyward

[aidenybai]

This will be addressed incrementally. In the next release:

• Cookie extraction from system browsers is already supported and can be toggled via Ctrl+K in the TUI or the new --no-cookies flag
• The SKILL.md now documents the cookie/auth behavior

For the broader feature request (explicit --cookie, --local-storage, auth config file), we'll track that separately.

[aidenybai]

@coreyward curious what you see wrong with our approach how we can improve?

[aidenybai]

@gabrielgene are you using Playwright or any existing tools? I'd love to learn some context behind your current work, that way I can figure out how to improve the product for your use case

[coreyward]

@coreyward curious what you see wrong with our approach how we can improve?

Honestly, I think the suggestion by the OP is good: allow the agent to specify cookies (or a cookie jar) rather than slurping up what are exceedingly likely to be sensitive cookies. What you're doing now is technically session hijacking.

[aidenybai]

@coreyward got it, thank you. I'll look into a solution that involves the user more instead of implictly grabbing cookies

[aidenybai]

Partial progress going out now on main — the `--no-cookies` flag is now wired through to the headless runner (it was previously declared but never read). (2bd400c3)

Full cookie/localStorage injection support (explicit --cookies <path> flag, storageState support) is still on the roadmap.