Hronaut Keeps Your Test Browser Open After an AI Agent Disconnects
Your AI agent disconnects mid-test, and the browser it was driving goes with it. What does Hronaut keep open, and when do you still have to sign in again?
- Hronaut keeps a separate desktop browser available after an agent disconnects.
- A person can pause control, sign in and return the session to the agent. Website session expiry still applies.
- Playwright MCP already supports persistent logins; Hronaut’s distinction is its visible desktop and human handoff workflow.
The browser belongs to the app, not each coding task
Ending an agent connection does not have to close the test browser. Hronaut’s lifecycle design separates the task, its MCP connection and the browser workspace. The desktop application owns the browser while clients connect to operate it.
Developer Yevhen Tienkaiev described the motivation in an October 24 development post: a visible browser where someone can watch and intervene. Hronaut checks signed-in applications and localhost through a dedicated window instead of taking over personal Chrome.
In the project’s recorded reconnect example, a tab and its checkbox state survive a client disconnect. A new connection cannot take over with the workspace ID alone; it needs the private resume key. That example uses a 3.3.1 source build, a synthetic local page and MCP SDK clients. It demonstrates reconnect behavior, not a real website login or operating-system restart.
Pause the agent before signing in yourself
The documented handoff starts with a named workspace and its login page. Pause MCP to reject new commands while leaving the window open, then:
- Enter credentials and complete any additional authentication yourself.
- Resume MCP after the authenticated page is visible.
- Have the agent inspect the current page and reclaim write ownership before continuing.
Resuming after a disconnect requires the workspace ID and private key. A website can still expire the session or request authentication again. Keeping the browser available does not override the service’s login policy.
Login persistence alone may already be covered
Playwright MCP’s default persistent mode retains login state, cookies and local storage between sessions. Its isolated mode starts fresh.
| Need | Selection criterion |
|---|---|
| Reuse authentication in later tests | A Playwright MCP profile or saved state may be sufficient. |
| Alternate between human and agent in a visible window | Consider Hronaut’s separate app, pause and resume workflow. |
| Run concurrent tasks | Separate workspaces; a Playwright profile is usable by only one browser at a time. |
Preserving cookies on disk and keeping a live window under someone’s control are different jobs. Existing profile settings suit repeatable automation. Hronaut is more relevant when recurring interactive checks need a person nearby to authenticate and take over.
Local profiles do not keep page content away from the agent
Hronaut supports Windows, macOS and Linux; bring your own agent or model. Its October 26 pricing offers ten consecutive trial days from the first agent tool call, with no card or automatic trial billing. Ongoing use costs $4 monthly or $24 annually per named user. The source is available under a subscription-and-trial license.
A connected agent can read authenticated pages and act with the account’s permissions. If it uses a cloud model, page content may reach that service even though the browser profile stays on the computer.
The security documentation also distinguishes a local listener from authentication: MCP authentication starts disabled. Enable Require MCP authentication when other local processes are not equally trusted. Workspace separation and pause controls help a person supervise access; they do not make an untrusted agent safe to connect.
The buying question is therefore more specific than whether logins can be saved: do you need a visible browser where a human signs in, takes control and explicitly returns the same workspace to an agent across tasks?