Chrome Co-Pilot Kit: governed browser automation
A Claude Code plugin that pilots a cloned copy of your signed-in Chrome, learns a task by watching once, then replays it the cheapest reliable way, with a human approval gate before anything changes.
Era 6, the AI-agent-native practice · Shipped, reusable product
The situation
Most browser automation tools ask you to trust a script with your accounts. You either hand over full, unsupervised control, or you write brittle click-by-click recipes that break the moment a page changes. Neither option is safe enough to run against your own logged-in accounts unattended. We built the kit to give a third option: full automation that still stops and asks before it does anything that matters.
What we built
Chrome Co-Pilot Kit is a Claude Code plugin that pilots a cloned copy of your own authenticated Chrome profile (your real profile is never touched). You show it a task once by letting it watch you do the work. It distills that session into a repeatable recipe, then replays the recipe using the cheapest reliable method available: a signed API call if one exists, a headless browser if not, a full visible browser session if the site requires it, or a handoff to you if nothing else will work.
In plain terms, it climbs a ladder of automation methods and only escalates to something slower or more expensive when a cheaper method cannot do the job.
The approval-gate angle
Every action that changes something (submitting a form, clicking a button that commits data, sending a message) passes through an approval gate before it fires. The system can watch, learn, and prepare an action. It cannot commit that action without a human saying yes. This is the same governance boundary that runs the rest of our practice: AI drafts, a person approves.
Verified results
- 51tests passing
- Live platformend-to-end validated on a live notarization platform
- Every changegated for human approval
The kit ships with 51 passing tests and was validated end-to-end against a real, live notarization platform, not a mock or a sandbox. The transfer package documents exactly which subsystems are production-real (the pilot engine, executors, router, approval gate, knowledge base, and MCP server) versus which are still scaffolding, so nothing is overstated as finished when it is not.
What this means for your business
If your team repeats the same browser task across a portal, a dashboard, or a vendor site with no usable API, this is how we make that task safe to automate: teach the system once by demonstration, then let it run the cheapest reliable path, with your approval required before anything actually changes. You keep the veto. The system keeps the memory.