Playwright MCP
A managed automation profile
Use it when repeatable browser automation and project-scoped persistent state fit the job.
Official profile documentation ↗Browser MCP decision guide
Which browser fits your agent’s work?
Choose Hronaut for recurring work in a visible desktop browser. Compare the alternatives for repeatable tests, your current Chrome session, and remote automation.
Source review: September 27, 2026
What makes Hronaut different
Keep a browser you can return to.
Playwright MCP also preserves login state, cookies, and local storage by default. Hronaut combines that kind of persistence with a separate visible desktop browser that stays available independently of any one coding-agent client, with explicit human controls and named workspaces. See the three-lifetime architecture →
Quick choice
Choose based on the browser you want the agent to inherit.
agent-browser
A CLI-managed browser profile
Use it when agents should drive a browser through compact CLI commands, with named sessions or persistent profiles that can survive restarts.
Official authentication patterns ↗Chrome DevTools MCP
Your currently open Chrome
Use auto-connect when the agent should inspect the exact tabs, extensions, and application state you already have open.
Official auto-connect guide ↗Dowser
Element finding in your existing browser
Use it when a Chrome extension and local MCP server should find page elements from the accessibility tree in the browser you already use.
Dowser product description ↗Browser MCP
Agent tab groups in everyday Chrome
Use it when each conversation should control its own tab group through a Chrome extension and local server.
Product architecture ↗Browser Control
Trusted code in your existing browser
Use it when an OpenCode, Claude, CLI, or MCP workflow should run Playwright against selected tabs through a local relay and unpacked extension.
Official architecture and safety boundaries ↗Browser Controller
Stable tab targets for multiple agents
Use it when agents should address explicit tabs in your existing Chrome through a shared local daemon and Chrome extension, with optional locks for coordination.
Official architecture and profile boundary ↗Hronaut
A dedicated browser for agents
Use it when the visible browser, named workspaces, and debugging context should remain available as clients and coding tasks change.
Connect a client →Comparison
Nine valid tools, nine different boundaries.
This is a workflow comparison, not a universal ranking. Product capabilities change; follow the linked first-party documentation for current setup details.
| Tool | Browser ownership | Persistent state | Important boundary | Strong fit |
|---|---|---|---|---|
| Playwright MCP | Managed automation browser and project profile | Login state, cookies, and local storage persist by default | Can also connect to existing tabs through its browser extension | Repeatable automation, testing, and project-scoped workflows |
| agent-browser | CLI-managed Chromium or an explicitly connected Chrome instance | --profile persists the full browser profile; named restore sessions can save and reload auth state | Saved state can contain session tokens, while remote debugging grants broad local browser control | CLI-first agent automation, repeatable profiles, and headed human login steps |
| Chrome DevTools MCP | Your active Chrome instance with auto-connect | Inherits the live profile and current tabs | The trusted agent can access data exposed by that browser profile | Investigating an already-reproduced issue in your current Chrome |
| Dowser | Chrome extension and local MCP server in your existing Chrome-based browser | Uses the browser's current profile and tabs | Element finding operates inside that browser rather than a separate desktop workspace | Natural-language element finding in a browser already in use |
| Browser MCP | Conversation-owned tab group inside everyday Chrome | Uses the existing Chrome profile | Its local server exits when the client disconnects or after its idle limit | Authenticated work inside bounded Chrome tab groups |
| Browser Control | Selected tabs in your existing Chromium browser through an unpacked extension | A detached local relay and named sessions survive individual CLI or MCP process restarts | It executes trusted local Playwright code and the extension requires broad browser permissions | Existing-browser workflows that need code-level control, handoff, and session continuity |
| Browser Controller | Existing Chrome tabs through a shared local daemon and Chrome extension | Inherits the same cookies, sessions, and local storage as the connected Chrome profile | Real authenticated-profile access is broad; explicit tab IDs and optional tab locks coordinate agents | Existing-browser verification that needs stable tab targeting and concurrent agents |
| Hronaut | Separate Electron/Chromium desktop application | Dedicated profile, tabs, storage, windows, and named workspaces | Chromium-only; initial binaries are unsigned and a paid subscription is required after the 10-day trial | Long-lived visible work, client switching, human takeover, and local debugging |
| Browserbase | Hosted cloud browser sessions | Optional Contexts persist cookies, authentication, and application data across sessions | Browser state is stored on hosted infrastructure; Contexts are encrypted at rest | Remote execution, managed infrastructure, proxies, and concurrent automation |
Dowser details here come from its own product and About pages. These describe its browser model; their benchmark and safeguard claims have not been independently tested for this comparison.
Local vs cloud browser
Start with where the browser state should live.
Both models can preserve authenticated state. The meaningful difference is who operates the browser, where its profile is stored, and whether a person can take over on the same desktop.
- tabs, cookies, storage, and browser history should remain on your machine
- the browser should stay visible while coding-agent clients connect and disconnect
- a person needs an immediate pause and manual takeover path
- named local workspaces are more important than remote scale or proxy infrastructure
- automation must continue on remote infrastructure without the desktop running
- concurrent sessions, managed browser capacity, or proxy configuration are central requirements
- you accept storing reusable browser context with the provider
- a remote live view is sufficient for human login or intervention
Browserbase is included as a documented example of the hosted model, not as an exhaustive list or endorsement. Its Context documentation says persisted data includes cookies, localStorage, IndexedDB, session storage, service workers, and browser preferences.
Debugging evidence
Choose the depth and data boundary together.
Browser agents now differ in how much runtime evidence they collect, not only in how they click a page. Chrome DevTools MCP 1.7 added object-level heap-snapshot details on top of snapshot comparison, retaining paths, dominators, edges, and duplicate-string analysis. Hronaut takes a deliberately bounded path: aggregate heap and DOM counters, before/after deltas, and allocation hotspots without returning object values, page source, or a raw heap snapshot.
Deep heap forensics
Choose Chrome DevTools MCP
Use it when the investigation needs saved heap snapshots, object-level retained-size analysis, retaining paths, or snapshot-to-snapshot comparison. Chrome's own Memory documentation explains the object graph, retained size, detached nodes, and allocation profiling behind this workflow.
Official memory tool reference ↗Bounded repeatable evidence
Choose Hronaut
Use it when a person and agent should repeat an interaction in the same visible session, compare post-GC heap and DOM counters, and rank sampled allocation hotspots while keeping raw objects and page content outside the result.
Hronaut memory workflow ↗These are complementary boundaries, not equivalent outputs. Growth in one bounded sample is evidence to investigate, not proof of a leak; deep heap snapshots are appropriate when the object graph itself is required.
Hronaut's boundary
Choose Hronaut when the browser should outlive the task.
- you want a separate browser instead of granting access to everyday Chrome
- signed-in tabs and debugging context should remain visible between agent tasks
- parallel agents need named isolated workspaces
- a person needs a clear pause, lock, or manual takeover path
- clean and repeatable browser tests are the primary goal
- the agent must inspect the exact Chrome tab where you already reproduced a bug
- Firefox or WebKit coverage is required
- a cloud browser, proxies, or unattended remote execution is required
Sources and method
Verify the boundary before granting browser access.
Claims about other tools come from their own current documentation. Hronaut claims come from its public source and reference. No tool listed here is endorsed by another.
- Playwright MCP — Profile & State
- agent-browser — persistent profiles and session restoration
- Chrome DevTools — Connect your AI agent with auto-connect
- Dowser — extension and local MCP product description
- Dowser — About and existing-browser model
- Chrome DevTools MCP — memory tool reference
- Chrome DevTools — heap snapshot workflow
- Browser MCP — product architecture and session lifecycle
- Browser Control — local relay, existing-browser sessions, and safety boundaries
- Browser Controller — existing Chrome, explicit tab targeting, multi-agent coordination, and profile access
- Browserbase — persistent browser Contexts
- Browserbase — hosted session capabilities
- Hronaut — detailed reference
Try the dedicated-browser model
Keep the browser. Change the agent.
Watch the real 35-second product capture, then use the tested setup guide for Codex, Claude Code, Cursor, VS Code/Copilot, OpenCode, or any Streamable HTTP MCP client.