One prompt, thread, or coding job.
Architecture guide
The browser should not die with the coding task.
A persistent profile can keep cookies on disk and still be locked, duplicated, or torn down with the client that launched it. Reliable agent-browser workflows begin by separating three lifetimes.
Source review: August 25, 2026
Messages between a client and an independent server.
Tabs, profile data, signed-in state, and visible context.
The core distinction
Persistence is storage. Ownership is lifecycle.
A profile may persist cookies, local storage, and cache after a process exits. That does not answer who launches the next browser, whether two clients can use the same profile concurrently, who can stop automation, or whether a person can still see the original tabs. Those are process-ownership decisions.
Three clocks
Do not collapse three different lifetimes into one.
“Session” is overloaded in browser automation. Modern MCP is stateless at the protocol level, while older revisions can establish a protocol session. Neither model defines the lifetime of a Chromium profile. A useful architecture names each lifetime explicitly.
Task lifetime
The unit of intent
A coding task can finish, be interrupted, fork into another thread, or switch clients. The browser does not automatically need to share that lifetime.
Transport lifetime
The MCP channel
In the July 2026 protocol, every request carries its own version and capabilities. stdio still has a client-owned subprocess lifetime, and Streamable HTTP has request-scoped responses. Legacy initialization or session state, when negotiated, is still not a Chromium profile or signed-in tab.
Browser lifetime
The process and profile
The browser owns renderers, tabs, cookies, IndexedDB, cache, downloads, and window state. Decide whether it should end with the task, stay with the human, or live on managed remote infrastructure.
Human lifetime
The visible handoff
Authentication, consent, CAPTCHA, payment, and visual judgment may require a person. The architecture needs a clear pause, takeover, and resume path rather than treating those moments as automation failures.
Transport changes ownership
stdio and Streamable HTTP create different defaults.
The current MCP specification defines both transports and a stateless core. It does not prescribe which component should own a browser; the transport simply makes some ownership models easier.
| Question | stdio | Streamable HTTP |
|---|---|---|
| Who starts the server? | The MCP client launches it as a subprocess. | The server runs as an independent process at an HTTP endpoint. |
| What ends the active work? | The client cancels a request on the shared channel or closes input and asks the subprocess to exit. | Each request has its own response; closing an SSE response stream cancels that request while the server process can continue. |
| Can clients change? | Usually requires another subprocess or an explicitly detached relay. | Multiple client connections can reach the same independent server. |
| Browser implication | Convenient when browser and tool server should be task-scoped. | Convenient when one desktop or hosted browser service should outlive individual clients. |
This is an architectural default, not a guarantee. A stdio server can delegate to a detached browser, and an HTTP server can still create disposable browsers. Verify the product's actual process tree and shutdown behavior.
A common surprise
A persistent profile is not a concurrency strategy.
Playwright MCP documents both useful profile persistence and the boundary that follows: one persistent profile can be used by only one browser instance at a time. Concurrent clients sharing a workspace need isolated mode or distinct user-data directories.
- will cookies and local storage still exist later?
- does the next browser instance reopen the same profile?
- can a test begin from known storage state?
- which process is allowed to open the profile?
- do parallel clients share, queue, or isolate work?
- who closes the browser and when?
- can a human see and interrupt the active session?
Four valid patterns
Choose the lifetime that matches the job.
Task-owned browser
Start clean, finish clean
Best for CI, regression tests, reproducible automation, and disposable work. The task or MCP server owns browser creation and teardown.
Existing human browser
Inspect the exact current tab
Best when the bug, extensions, or application state already exist in everyday Chrome. The tradeoff is broad authority over that profile.
Dedicated desktop browser
Keep visible work between clients
Best when signed-in tabs, named workspaces, and debugging context should remain on the person's machine while coding tasks connect and disconnect.
Hosted browser service
Keep work away from the desktop
Best for remote execution, managed capacity, proxies, and unattended jobs. Persisted profile data and live-view access move into the provider's trust boundary.
Failure modes
Lifecycle mistakes look like random browser bugs.
Duplicate GUI processes
One task, one headed server
A public Codex issue documents configured headed MCP servers accumulating as sessions are started or resumed. The processes are not necessarily orphaned; each may still belong to a live client session.
Profile lock
Two owners, one profile
The second client can connect to MCP successfully and still fail on its first browser action when another instance owns the persistent profile.
Invisible authority
State survives without a human boundary
Long-lived cookies can preserve powerful account access. Persistence without a visible owner, pause control, and workspace policy merely makes delegated authority last longer.
Coupled teardown
Closing the task destroys useful context
If tabs, logs, screenshots, and authentication disappear with the client, the next task must reconstruct the incident before it can continue debugging.
Concrete implementation
How Hronaut separates the lifetimes.
Hronaut is one implementation of the dedicated-desktop pattern, not proof that every workflow needs it.
- 1
The desktop application owns Chromium
The visible Electron app stays open independently of Codex, Claude Code, Cursor, Copilot, OpenCode, or another compatible client.
- 2
Persistent Electron partitions own workspace data
Named workspaces use durable partitions for browser state. Stable workspace IDs remain distinct from MCP requests and coding tasks.
- 3
Streamable HTTP accepts changing clients
The embedded server binds to loopback at a single MCP endpoint and uses stateless JSON responses. A compatible client can disconnect without making that client the owner of the browser process.
- 4
The human Default workspace is not an agent workspace
Agents must create their own workspace. Optional one-time storage transfer is explicit rather than silently granting access to the human workspace.
- 5
Pause, locks, and optional authentication remain visible
The person can stop new commands, lock interaction, take over a tab, and require a bearer token for local MCP access.
- the browser should outlive coding tasks
- the same visible session should work with changing clients
- parallel jobs need named durable isolation
- human login and takeover are part of the workflow
- ephemeral multi-browser CI
- Firefox or WebKit coverage
- unattended remote browser infrastructure
- controlling the exact everyday Chrome profile
Hronaut is Chromium-only. Initial binaries are unsigned and not Apple-notarized. Browser state remains sensitive local data, the desktop must keep running, and the public source uses PolyForm Noncommercial 1.0.0 rather than an OSI license.
Architecture checklist
Ask these questions before choosing a browser MCP.
| Question | Why it matters | Evidence to request |
|---|---|---|
| Who owns the browser process? | Defines startup, shutdown, reuse, and failure recovery. | Actual process tree and documented teardown behavior. |
| Where does profile data live? | Defines the credential, privacy, backup, and provider boundary. | Profile path or hosted-storage policy. |
| What happens with two clients? | Reveals profile locks, queues, tab collisions, and isolation. | A real parallel-client test, not only two successful MCP handshakes. |
| What survives a disconnect? | Separates protocol persistence from browser persistence. | Reconnect to the same visible tab and stable workspace identity. |
| How does a person stop it? | Authenticated browser automation is delegated authority. | Pause, lock, permissions, and manual takeover controls. |
| What is deliberately unsupported? | Prevents a local desktop tool from being mistaken for CI or cloud infrastructure. | Browser engines, platforms, signing, license, and remote-hosting boundaries. |
Sources and method
Verify process ownership, not just feature copy.
The transport and Electron claims below come from current first-party documentation. The failure examples are public issue reports and should be treated as documented field evidence, not universal measurements. Hronaut behavior is grounded in its public source and reference.
- Model Context Protocol — current transport overview and backward-compatibility boundary
- Model Context Protocol — stdio subprocess and shutdown lifecycle
- Model Context Protocol — stateless Streamable HTTP request lifecycle
- Electron — persistent session partitions
- Playwright MCP — persistent, isolated, and extension profile modes
- Playwright MCP issue #1594 — concurrent persistent-profile lock reproduction
- OpenAI Codex issue #21984 — headed MCP process lifetime report
- Hronaut — agent workspace reference
- Hronaut — embedded MCP server source
- Hronaut — persistent workspace storage source
Choose deliberately
Start from browser ownership, then choose the tool.
Use the comparison guide to match the task-owned, existing-browser, dedicated-desktop, or hosted model to your workflow. If the dedicated-browser model fits, the setup guide includes one observable isolated-workspace check.