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. Keep different projects and accounts separate while you watch and control the work.
Workspace contract checked against Hronaut v2.5.0 · September 21, 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. See why a persistent profile is not a concurrency strategy →
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 a stable workspace ID and private resume key. Keep the key private so the same task can reconnect later. - 2
Choose storage
Use
storage=scratchfor a clean profile. To reuse sign-ins deliberately, calllist-fork-sources, then create withstorage=fork-workspace, asourceWorkspaceId, and only the requiredorigins. - 3
Stay scoped
Pass that workspace ID to every page tool. Hronaut rejects tabs that belong to another workspace. After reconnecting, use
action=resumewith the workspace ID and private resume key before inspecting the page. - 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 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.
A fork copies cookies and local storage into a new workspace with a blank tab; it does not copy source tabs, passwords, IndexedDB, or caches. It inherits the source’s navigation restrictions. Disabling direct agent access to a source still permits forks, so that switch does not keep its reusable sign-ins secret.
Returning to a task
Keep the state. Recheck before acting.
One live connection at a time can hold the workspace’s five-minute renewable write lease. Another authorized connection can inspect it, but conflicting writes return BUSY or LEASE_LOST without dispatching the action. Pause, disconnect, release, or expiry removes that write authority.
After a handoff, inspect fresh state, check ownership-status, and use claim-ownership only when ready to continue. This coordinates writers inside one Hronaut process; it does not coordinate separate installations. Archive useful state to keep it, or permanently close a workspace to delete its browser data.
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 other 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.