Show HN: Chromectl – CLI to give an AI agent its own Chrome session

[bartek_gdn]

Most browser automation tools (Playwright MCP and similar) create a browser process owned by the agent. chromectl flips that: you start a named session, and the agent connects to it. The session is isolated — no cookies, no saved logins, no way for the agent to wander into your banking tab.

This also unlocks human handoff. Start a session, navigate to a site, log in manually, then hand control back to Claude. Useful for anything behind auth that you don't want to automate credentials for. Each session gets a dedicated Chrome profile. Stop it, start it again tomorrow, you're still logged in.

Claude Desktop can drive Chrome too, but it requires a plugin and works inside your main browser profile — there's no way to scope it to a clean session.

Cloudflare and Anthropic have both written about why agents work better through code than through tool definitions — MCP front-loads every tool description into context whether it's used or not. A CLI is lighter still: give Claude a terminal and `--help`, and it figures out the rest. No tool schemas, no context bloat.

Standard stuff like navigate, eval, screenshot, and scrape is there, plus `pick` — click any element on a live page and get back its selector, HTML, and computed styles as JSON. Paste into Claude and say "fix this."

Sharing in case it's useful — curious how others are handling the browser problem with agents.

---

Sources: - Cloudflare Code Mode: https://blog.cloudflare.com/code-mode-mcp/ - Anthropic on code execution with MCP: https://www.anthropic.com/engineering/code-execution-with-mc...

[CloakHQ]

Cool approach. One thing I've run into working with teams that do browser automation for data collection: the session isolation piece solves the "agent wandering into your main profile" problem, but there's a second layer that bites people at scale — even with perfectly isolated profiles, if multiple sessions run on the same machine they tend to share hardware-level signals (canvas fingerprint, WebGL renderer, screen resolution, timezone) that detection systems pick up on.

So you end up with ten "isolated" sessions that all look like siblings from the same host. Curious if you've hit that or whether the use case here is more single-session handoff rather than running many in parallel.