Why your agent's browser should outlive the session
An agent session lasts minutes. The browser it works in holds sign-ins, tabs and evidence that took longer to build. Three lifetimes to keep apart, and when a short-lived browser is the right call.
Many browser tools for coding agents start a browser when the agent connects and close it when the agent is done. For automated tests that is the right default. For everyday work next to a person, it throws away the part that took longest to build.
What closes with the session
Some tools keep a profile on disk, so sign-ins can survive: Playwright MCP does this by default. What still goes away with the browser process:
- Open tabs and live page state. The next session reopens and re-navigates the pages under test, and anything kept only in session storage or in memory is gone.
- The evidence. The console, the network log and the screen that showed the problem.
- A view for the person. If no one was watching, the only record is the agent's own report.
The last one matters more than it sounds. An agent can report “done” while the page shows a login wall or an empty shell. A browser that is still open, and visible, after the session ends is a cheap way to check.
Three clocks
| Lifetime | Typical length | What it holds |
|---|---|---|
| Agent task | minutes | one prompt, thread or job |
| MCP connection | a request, or a client process | messages between the agent and a tool server |
| Browser | days or weeks, if you let it | process, profile, tabs, sign-ins, windows |
With the stdio transport, the client starts the MCP server as a subprocess and ends it, so a browser owned by that server ends with the client. With Streamable HTTP, the server runs on its own and each request gets its own response, so the browser can outlive any one client. The transport doesn't decide ownership, but it makes one choice easier than the other.
Keeping data is not keeping the browser
A persistent profile answers “will the cookies still be there?” It doesn't answer who owns the browser, or whether two clients can use it at once. Playwright MCP's README says it plainly: a persistent profile can only be used by one browser instance at a time, so parallel clients in the same project need --isolated or a separate profile directory.
When a short-lived browser is right
CI, regression suites, and anything that must start clean, run in parallel on servers and leave nothing behind. There, a browser that dies with the task is a feature, and a test runner such as Playwright is the right tool. Hronaut is not built for that.
How Hronaut keeps the browser
- The desktop app owns Chromium and stays open while agents connect and disconnect.
- Each task can work in its own named workspace with persistent storage, so parallel tasks don't share sign-ins.
- An agent that comes back resumes its workspace with a private key. The workspace ID alone grants no access.
- A person can pause new commands, take over a tab and hand it back.
The longer version, with failure modes and four patterns compared, is Why browser lifecycle matters for coding agents.
Sources: Playwright MCP README, “User profile”, MCP specification (2026-07-28): transports, the browser lifecycle guide, and Why I built my own browser for AI coding agents (an agent reporting “done” on a login page).
Written with the help of AI.