browser-profile

# browser-profile A thin profile registry on top of Chrome's `--user-data-dir` + `--remote-debugging-port`. Solves three problems at once: 1. **Persistent state per logical user.** Cookies, localStorage, IndexedDB, disk cache survive across runs. 2. **Manual access.** You open the profile in real Chrome and log in / poke around without Claude involved. 3. **Programmatic access on the same window.** Claude attaches via CDP using `agent-browser connect <port>` - no separate Chromium spawn, no SingletonLock collision. Why not Playwright `launchPersistentContext`? Because that path requires Playwright to own the browser lifecycle - you can't have a normal Chrome window on the same `user-data-dir` simultaneously. The CDP-attach pattern here lets both of you share one window; connect-over-CDP is exactly how agent-browser participates in it. That's also why agent-browser must attach in `connect` mode, never `--profile` mode: profile mode launches its own Playwright-owned browser, which breaks the shared window this skill exists to provide. ## When to use - Frontend tests where re-running the login flow on every iteration is wasteful or impossible (MFA, SSO). - Long-lived debugging sessions where you want to come back tomorrow and have the same logged-in dashboards. - Hand-off flows: you log in manually, then ask Claude to drive the rest. **Not for:** cloud-only / anti-bot use cases (use Browserbase contexts via `vd:browser` `--context-id` instead) or one-shot ephemeral scrapin...