browser-profile
browser-profile
A thin profile registry on top of Chrome's --user-data-dir + --remote-debugging-port. Solves three problems at once:
- Persistent state per logical user. Cookies, localStorage, IndexedDB, disk cache survive across runs.
- Manual access. You open the profile in real Chrome and log in / poke around without Claude involved.
- 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 scraping (just use agent-browser directly, no profile needed).