Navigation
Tabs stop meaning one thing
One agent can navigate, close, or reuse a tab while another agent still treats it as the page from an earlier snapshot.
Parallel coding agents
Keep every agent in its own browser workspace.
Give each Codex, Claude Code, Cursor, Copilot, or OpenCode task its own visible tabs and isolated persistent browser profile—without letting agents browse the human Default workspace.
Product and source review: August 24, 2026
A practical default
Create one fresh workspace per agent task.
A persistent profile is useful, but concurrent work still needs an ownership rule. Hronaut requires an agent to create a named workspace first and use the returned UUIDv7 workspace ID for every browser tool call. Tabs and site state stay inside that task boundary.
The shared-profile problem
Parallel agents should not race through one browser context.
Identity
Roles and cookies collide
Two tasks may need different test accounts, organizations, feature flags, or local-storage state on the same origin.
Lifecycle
One task can end another
If the browser belongs to a single client process, disconnecting or restarting that client can destroy useful state for other work.
Hronaut workspace contract
A visible boundary agents can follow.
- 1
Create
Start with
browser_workspacesand a fresh, human-readable task name. Hronaut returns the stable workspace ID. - 2
Choose storage
Use a clean scratch profile, or make a one-time copy of selected reusable state from Default with
fork-default. - 3
Stay scoped
Pass that workspace ID to every page tool. Hronaut rejects tabs that belong to another workspace and never exposes Default through MCP.
- 4
Archive or close
Archive useful task state for later, or permanently close the workspace and its isolated browser data when the task is finished.
Storage boundary
Separate cookies and storage, not just separate tab labels.
Every non-Default Hronaut workspace receives its own persistent Electron partition for cookies, local storage, cache, service workers, and related site state. Workspace membership is immutable: tabs cannot move between workspaces, and a tab ID from another workspace is rejected.
Copying state from Default or saving selected state back is an explicit one-time operation. It is not live synchronization, and agents still cannot browse the human Default workspace directly.
Choose the right model
Isolation can belong to the project, the current browser, or a dedicated app.
Project-scoped automation
Playwright MCP profiles
Playwright MCP creates persistent profiles from the workspace root and supports isolated sessions. Its documentation notes that a persistent profile can be used by only one browser instance at a time.
Playwright MCP profile modes ↗Exact browser already open
Existing Chrome
Connect when the task must inspect the exact tab and profile already on screen. This gives the agent the authority and shared state of that everyday browser.
Chrome DevTools auto-connect ↗Durable multi-agent work
Hronaut workspaces
Use one separate visible browser app when task profiles should persist independently of client sessions and remain isolated from both Default and other agent workspaces.
Compare browser ownership models →Sources and limits
Use workspace isolation for interactive local tasks, not as a CI replacement.
Hronaut embeds Chromium and is designed for visible, long-lived desktop work. Use Playwright or another test runner when ephemeral headless jobs or Firefox and WebKit coverage matter more than durable human-visible sessions.
Try the workspace boundary
Run two browser tasks without sharing tabs or login state.
Install Hronaut, connect two MCP clients, and have each create a clearly named scratch workspace before opening a page.