# Setup Browser Cookies

> Bootstrap auth cookies for the managed Chromium profile — operator-driven, one-time per service.

- Skill: `jokerman89/setup-browser-cookies` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jokerman89/setup-browser-cookies`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jokerman89/setup-browser-cookies/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jokerman89 (https://skillmd.com/u/jokerman89)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jokerman89/setup-browser-cookies

---


# /setup-browser-cookies

Establishes authenticated cookies in the Lintel-managed Chromium profile so that subsequent `/browse` and `/scrape` runs can hit logged-in pages without re-auth.

Operator-driven by design: the skill launches a headed (visible) browser, the operator logs in manually using their actual SSO or password manager, and on close the cookies persist in the managed user-data-dir. No password ever enters this skill's prompt.

## When to use

- First time you need `/browse` or `/scrape` against a page behind login
- After cookie expiry (typically every 7-30 days depending on the service)
- After a password rotation that invalidated old sessions
- Switching managed profile (e.g. personal vs work account separation)

## When NOT to use

- The service has API tokens — use the API instead; cookies are fragile and short-lived
- Production customer-bearing system — STOP. Layer 2 customer-data gate blocks; the right move is sanitized fixtures
- Service requires MFA on every login and you can't store an MFA token — skill won't help; live `/browse` with manual MFA each time is the workflow

## Inputs

- Required `--service <name>` — friendly name for the service (used in cookie store labeling)
- Required `--login-url <url>` — the URL where login lives
- Optional `--profile <name>` — managed profile to use (default: `default`)
- Optional `--check` — verify existing cookies are still valid (visits a known authed page, checks for redirect)

## Workflow

1. **Compliance gate.** Hostname checked against Layer 2 prod-host list. If matched: BLOCK.
2. **Launch headed Chromium.** With persistent user-data-dir at `~/.lintel/browser-profiles/<profile>/`.
3. **Operator login.** Browser navigates to `--login-url`. Skill prints "Waiting for operator login. Press Enter here when logged in."
4. **Verify.** When operator confirms, skill navigates to a service-known authed URL (per `~/.lintel/browser-profiles/services.yaml`) and checks for non-login response.
5. **Persist + close.** Cookies are already on disk (persistent profile); skill just confirms presence + closes browser.
6. **Register service.** Append metadata to `~/.lintel/browser-profiles/services.yaml`: service name, last-validated-at, login URL, validation URL.
7. **Report.** Confirmation + expiry estimate (read from cookie max-age if available).

## Workflow (--check mode)

1. Launch headless Chromium with same profile.
2. Navigate to the service's validation URL.
3. If logged in: print OK + report cookie freshness.
4. If redirected to login: print STALE + recommend re-run without `--check`.

## Report format

```
Setup browser cookies: github.com

Profile: default (~/.lintel/browser-profiles/default/)
Login URL: https://github.com/login
Validation URL: https://github.com/settings/profile

[Headed browser launched. Operator logged in at 16:14:03.]

✓ Validated — settings page loaded as logged-in user
Cookies persisted to profile
Estimated expiry: ~30 days (based on max-age headers)
Service registered in services.yaml
```

## Compliance integration

- Layer 2 prod-host gate ALWAYS applies — you cannot bootstrap cookies against a customer-data-bearing prod host through this skill. Use sanitized staging/test environments.
- Profile dir permissions: `~/.lintel/browser-profiles/` should be `chmod 700` (skill verifies + warns if loose).
- NEVER prompts operator for passwords. NEVER captures keystrokes. NEVER reads the browser's password autofill store.
- Cookie store excluded from any lessons/memory sync by default (Layer 2 secrets-rule). If a sync is enabled, the secrets hook blocks.

## Failure modes

- **Operator never confirms login:** 5-minute timeout, then skill closes browser + reports no-confirmation. Cookies that ARE present will still persist.
- **Validation URL fails (got redirected to login):** report STALE state. Operator can retry, possibly with a different account.
- **Profile dir permissions too open:** print chmod 700 fix command + ask whether to apply.
- **Browser crash during login:** report + ask operator to retry. Cookies from a clean shutdown will persist; from a crash may not.
- **Service has rotating cookies (every request):** cookies persist but may not survive idle time. Note this limitation; operator should run `--check` more often.

## Examples

**First-time setup for GitHub:**
```
> /setup-browser-cookies --service github --login-url https://github.com/login
[Headed browser opens. Operator logs in.]
✓ Validated. Cookies stored, est. 30 days.
```

**Check existing:**
```
> /setup-browser-cookies --service github --check
✓ Cookies fresh, last validated 4h ago, settings page loaded.
```

**Stale cookies:**
```
> /setup-browser-cookies --service github --check
✗ STALE — redirected to /login. Re-run without --check to refresh.
```

## See also

- `/browse` — uses the cookies set up here
- `/scrape` — same
- `/open-managed-browser` — manual interactive session in the same profile
- Layer 2 compliance — secrets handling, profile permissions