Hronaut

Hronaut is a visible, persistent Electron browser that exposes durable agent workspaces through MCP. It keeps the browser open independently of any individual AI session, so people can watch, pause, and take over while agents work in separate local browser profiles.

Website · Setup · Browser MCP decision guide · Downloads · Issues · Detailed reference

Where Hronaut fits in your agent stack

Hronaut is a local, visible MCP execution layer for agents that already have their own orchestration. The caller keeps workflow and orchestration state; Hronaut binds each browser command to a tool contract and a named local workspace with its own profile, account, origin, and tab context. People can watch, pause, approve, or take over, and the caller can require bounded browser evidence before it treats an external action as complete.

Responsibility	Owner
Plan the workflow and retain task state	Your SDK, agent framework, or application
Define the requested browser operation	MCP tool contract and arguments
Execute with a specific browser identity and site context	Hronaut workspace, profile, account, origin, and tab
Approve or complete a consequential manual step	The person using visible Hronaut controls
Decide whether the workflow may continue	The caller, using verified postcondition read-back

For example, a code-first agent can retain its own task state, ask Hronaut to submit a reviewed change in one named workspace, wait for human approval when required, and continue only after verified postcondition read-back confirms the external result.

Hronaut is not an agent framework, hosted browser fleet, no-code platform, or universal production-safety guarantee. Use it when the browser should remain local, visible, and deliberately reusable; keep orchestration and final business decisions in the calling system.

See Hronaut in action

Watch the 35-second product overview, then download Hronaut for Windows, macOS, or Linux.

Not sure which browser model fits your workflow? Read the source-backed Browser MCP decision guide, which compares Hronaut with Playwright MCP, Chrome DevTools MCP, and an extension-based Browser MCP without claiming persistence is unique.

Start in three steps

1. Download the latest Hronaut for Windows, macOS, or Linux and start it.
2. On Hronaut Home, choose your coding agent and copy its generated setup, or use the generic setup guide. The in-app setup always reflects the current local endpoint and authentication choice.
3. Ask the connected agent: Using Hronaut, create a new isolated workspace named “Hronaut first run”, open https://example.com, take a semantic snapshot, and tell me the page heading. Use only that task workspace.

A successful run stays visible in Hronaut, creates an isolated workspace, and remains available after that coding-agent conversation ends.

Ready for a real task? Use the copy-ready starter workflows for authenticated handoff, localhost QA, and responsive review without weakening Hronaut's workspace and privacy boundaries.

For recurring work, run the scheduled and triggered browser workflow. Its disposable Docker fixture shows which component owns triggers, browser authority, human takeover, retries, cancellation, and authoritative outcome reconciliation.

Hronaut automates web pages in its own browser, not native desktop applications or other application windows. See browser and native testing boundaries to choose the right test surface, and approval boundaries before consequential actions.

Choose a persistent profile or Hronaut workspaces

A dedicated persistent browser profile can be enough for one project and one identity. Playwright MCP supports this through --user-data-dir; persistence does not require Hronaut. Its profile documentation also explains separate profiles for concurrent browser instances.

Choose Hronaut when you want named profiles managed together in a desktop browser, visible pause and takeover, or deliberate workspace resumption across compatible MCP clients. Each new workspace has separate website storage; bookmarks, history, download records, and remembered permissions remain application-wide. See the workspace contract for the exact boundaries. Hronaut adds a desktop application to run and maintain; its terms are in License.

Each live MCP transport can hold a bounded exclusive write lease for the workspace it creates or resumes. A resume remains usable for read-only inspection when another transport already owns writes, but conflicting mutations return a typed BUSY result without dispatch. Pausing agents, rotating authentication, disconnecting, releasing ownership, or lease expiry revokes that transport's write authority; claim it again only after inspecting fresh state. This lease prevents concurrent writers inside one Hronaut process, not coordination across different Hronaut installations.

Try the short first-run checks for both paths before committing to a workflow. Hronaut's client connection guide and Playwright MCP's client setup instructions cover their respective connections.

Move reviewed setup between machines with portable workspace templates, without copying browser sign-ins. The Support, recovery, and exit path explains how to reconnect a client, replace or remove a workspace, recover local data, and get help.

Keep personal and agent work separate

Open Home to find a project, switch to its tabs, or create a new space. The Open and Archived views keep ongoing and saved work easy to find. Search by workspace name or page title. Each workspace card shows direct agent access and any site restrictions; choose Manage to edit them. Workspace options can hide a workspace from the left sidebar or protect it from permanent deletion. Hidden workspaces stay accessible from Home, and protected workspaces can still be archived.

The browser mute button works from Home before any website tabs exist. It silences existing and future tabs, survives restart, and restores individual tab mute choices when turned off.

Choose Archive when you finish a task. Tabs and sign-ins remain saved, and Undo archive restores an accidental archive immediately. Use Restore workspace in the Archived view to pick up where you left off. Permanent deletion asks for confirmation and removes the workspace’s website data.

Hronaut starts on Home without creating a Default workspace. Opening your first tab creates an isolated workspace. Obsolete base-profile data and unsupported persistence formats are discarded.

• Fork a workspace to reuse its cookies and local storage in an independent profile. Choose any active or archived source; the fork starts with a blank tab and keeps the source's site restrictions.
• Disable direct agent access when a workspace should stay under your control. Agents can still fork it, but cannot browse or change its original tabs. The fork receives a copy of its site data, so this setting does not prevent agents from reusing copied sign-ins.
• Copy or Move site data with explicit source and destination controls. Move requires both workspaces archived and verifies the destination before removing transferred data from the source. Profiles with background site-worker storage cannot currently be moved.

Transfers include cookies and local storage, not history, saved passwords, IndexedDB, cache, or downloaded files. They are one-time copies, not ongoing synchronization. Deleting a workspace permanently removes its browser profile; archiving keeps it for later.

Works with your coding agent

Connect through Hronaut's local Streamable HTTP MCP endpoint. Choose the focused guide for your client, or start with the generic setup:

• Terminal and desktop agents: Codex, Claude Code, Gemini CLI, Goose, OpenCode, Devin Local, Mistral Vibe, Grok Build, Qwen Code, and Warp.
• Editor agents: Cursor, VS Code / GitHub Copilot, Cline, Zoo Code, Kiro, Kilo Code, JetBrains Junie, Zed, and Windsurf.
• Other clients: use the generic Streamable HTTP setup.

When Hronaut is the right browser

Hronaut fits when you already have a coding agent and want the browser to remain local, visible, and reusable after one task or chat ends.

• Keep authenticated sites in named, isolated workspaces instead of rebuilding login state for every agent session.
• Watch work as it happens, pause agent access, lock website interaction, or take over the same tab for CAPTCHA, 2FA, payment, and other human-only steps.
• Resume one deliberately scoped browser workspace across compatible local MCP sessions with its private task capability, without exposing it to other connected clients or connecting the agent to your everyday browser profile.
• Preserve tabs and evidence between coding sessions for debugging, authenticated QA, and multi-agent handoffs.
• Track long browser workflows with bounded deadlines, heartbeats, and runtime-checked completion evidence instead of relying on a model message alone.

Explore the source-backed workflows for authenticated browser handoff, parallel agent workspaces, localhost QA, local Web3 wallets, and security and release trust.

Use a task-owned headless browser or automation library when the browser should be disposable or embedded inside your own agent runtime. Use a hosted browser service when you need remote regions, managed proxies, stealth, or fleet-scale execution. The decision guide covers the tradeoffs in more detail.

Highlights

• Persistent tabs, cookies, storage, sessions, workspaces, split views, and window state.
• A workspace-first desktop layout with compact icon navigation, searchable settings, tab previews, a full-page viewer, and clear active-tab treatment. New profiles use the resizable, collapsible left rail; top tabs remain available in Appearance.
• Ten appearance choices: System, Light, Dark, Midnight, Sepia, Cyberpunk, Cyberpunk Turbo, Matrix, Machine, and Galactic.
• Local Streamable HTTP MCP endpoint with browser navigation, interaction, inspection, diagnostics, downloads, storage, and accessibility tools.
• Multi-agent workspaces with isolated browser profiles, connection-scoped access, and private restart-safe resume capabilities.
• Independent public-outcome verification that compares a writer view with a distinct clean, read-only observer workspace and returns a privacy-bounded audience-separated receipt.
• Optional trusted workspace site-access allowlists covering direct navigation, redirects, page actions, popups, and history without granting policy changes to agents.
• Runtime action-authority fences that treat page content as untrusted and reject consequential actions when their origin, navigation, workspace, policy, or target context changes before dispatch.
• Human-interaction locks, instant MCP pause, explicit permissions, and optional bearer-token authentication.
• Independent Follow agents mode that keeps the active agent tab visible without taking keyboard or mouse focus. With it off, agent-created tabs, workspace tab selections, and agent-triggered popups leave the tab you are viewing in place.
• Built-in history, bookmarks, downloads, password vault, site controls, responsive preview, visual comparison, and Chromium diagnostics.
• Automatic update checks against public GitHub releases; downloads and installation always require user action.
• English, Ukrainian, Russian, German, French, Spanish, and Polish interface languages.

Install

Download the latest package for Windows, macOS, or Linux from GitHub Releases.

Mac requirements: macOS 13 Ventura or later, on either Apple Silicon or Intel. Check your macOS version in Apple menu → About This Mac before downloading.

On Windows x64, install the verified portable build and Start Menu shortcut with Scoop:

scoop install https://raw.githubusercontent.com/hronaut/hronaut/main/packaging/scoop/hronaut.json

The Windows binary remains unsigned, and the macOS packages are not Apple-notarized, so Windows SmartScreen or macOS Gatekeeper may show a warning. Verify downloads with the published hashes.txt file and GitHub artifact attestations.

Verify an unsigned download

Keep the downloaded package in one directory, replace PACKAGE_FILENAME below with its exact filename, and use the GitHub CLI to verify both the package and the checksum manifest against this repository's release workflow:

gh release download --repo hronaut/hronaut --pattern hashes.txt
gh attestation verify hashes.txt --repo hronaut/hronaut
gh attestation verify "./PACKAGE_FILENAME" --repo hronaut/hronaut

Compute the package's SHA-256 digest with the command for your platform:

# Linux
sha256sum "./PACKAGE_FILENAME"

# macOS
shasum -a 256 "./PACKAGE_FILENAME"

# Windows PowerShell
Get-FileHash .\PACKAGE_FILENAME -Algorithm SHA256

Compare the result with the matching filename in hashes.txt. Attestations and hashes establish release-workflow provenance and file integrity; they do not make these packages platform code-signed or Apple-notarized. The release trust guide explains the boundary and additional checks.

Run from source

Requirements: Node.js 22 or newer and a graphical Linux, macOS, or Windows session.

npm install
npm run dev

Build and run the desktop application:

npm run build
npm start

Development uses a separate persistent hronaut-dev profile. Installed builds use the normal Hronaut profile.

Connect an MCP client

To connect from another computer on your LAN, open Settings → MCP security, turn on Allow connections from other computers, then fully quit and restart Hronaut. This listens on all IPv4 interfaces. Token authentication is optional and controlled separately by Require MCP authentication. Use http://YOUR-HRONAUT-COMPUTER-LAN-IP:47812/mcp on the remote computer (replace the address and use your configured MCP port). If authentication is enabled, create a credential under Capability profiles in the same settings panel and configure your remote client to send Authorization: Bearer YOUR-CREDENTIAL. Allow the configured port through the host firewall. Local clients still use their existing loopback URL. Use direct HTTP only on trusted networks; it does not encrypt credentials or browser traffic. For untrusted networks, use an encrypted tunnel or TLS proxy. Turning remote access off also requires a restart. Authentication changes apply immediately. Without authentication, anyone who can reach the listener can control the browser profile and attach local files. Browser Origin restrictions remain in place; this option is for MCP clients, not arbitrary browser pages.

Start Hronaut, then configure a Streamable HTTP client with the local endpoint:

{
  "mcpServers": {
    "hronaut": {
      "url": "http://127.0.0.1:47812/mcp"
    }
  }
}

The public setup guide provides tested commands for Codex, Claude Code, Gemini CLI, Goose, Cursor, Cline, Zoo Code, Kilo Code, JetBrains Junie, Devin Local, Zed, Mistral Vibe, Grok Build, Qwen Code, Warp, Windsurf, VS Code/GitHub Copilot, OpenCode, and generic MCP clients. Hronaut Home contains the current profile-specific version for every built-in client, including the right endpoint and authentication settings.

Before configuring a client inside WSL, Docker or Podman, a Dev Container, a VM, Remote SSH, or a hosted environment, use the client topology and loopback reachability guide. 127.0.0.1 belongs to the client process's network namespace, which may not be the desktop host running Hronaut. The release-tested path is a native client on that same host; do not expose browser control through a LAN bind, proxy, or public tunnel to work around an unreachable loopback endpoint.

Local MCPB 0.3 hosts can use the adapter bundle attached to each matching desktop release. Follow the MCPB adapter guide for the separate desktop prerequisite, loopback endpoint, owner-token file selection, reconnect, and bounded first-call checks. The bundle does not install or start Hronaut and cannot make its loopback endpoint reachable from a hosted agent.

Compatible clients also receive concise server instructions during MCP initialization: create a fresh isolated workspace first, prefer semantic snapshots and refs, and request human attention only for a genuinely manual step. These instructions improve tool selection but do not replace Hronaut's enforced workspace and interaction boundaries.

Hronaut Home includes a copy-safe readiness report that distinguishes the local listener, MCP initialization, the catalog Hronaut advertises, tools actually visible in the active client, and a successful browser_status or browser_snapshot probe in a task-owned workspace. A healthy endpoint or valid configuration alone does not prove that a custom-agent host exposed the tools to the current task. Tool-list comparison runs locally, and copied diagnostics omit tokens, client/session identifiers, raw errors, arguments, URLs, and page content. Hronaut defaults to loopback; LAN access is an explicit Settings opt-in.

Install the Hronaut Agent Skill

Skill-aware coding agents can install Hronaut's portable workflow guidance directly from this repository:

npx skills add hronaut/hronaut --skill hronaut

The skill teaches the agent to create its own isolated workspace, prefer semantic page interactions, preserve the user's original workspaces, and request a safe human handoff for CAPTCHA, 2FA, or credential entry. It does not configure the MCP connection or contain an authentication token; start Hronaut and copy the current client setup from Hronaut Home first.

After trying it, share a short setup report—successful connections are useful too. The structured form asks for the client, operating system, Hronaut version, and outcome. Never include credentials, MCP tokens, private page data, or personal browser-session information in a public issue.

First successful run

After your client reports Hronaut as connected, paste this into the coding agent:

Using Hronaut, create a new isolated workspace named “Hronaut first run”, open https://example.com, take a semantic snapshot, and tell me the page heading. Use only that task workspace.

Hronaut Home provides the same prompt with a copy button. A successful run visibly creates a separate workspace, opens the page, and records content-free tool activity on Home; the workspace and its browser profile remain available after the coding-agent conversation ends.

OpenCode

For a new Hronaut profile with MCP authentication disabled, add this server to the global ~/.config/opencode/opencode.json or a project's opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "hronaut": {
      "type": "remote",
      "url": "http://127.0.0.1:47812/mcp",
      "enabled": true,
      "oauth": false
    }
  }
}

Start Hronaut, then verify the connection with opencode mcp list. If MCP authentication is enabled, copy the OpenCode configuration from Hronaut Home; it references the owner-only token file without placing the token in the JSON. Use opencode mcp debug hronaut to diagnose connection or authentication failures. Hronaut's focused OpenCode browser MCP guide includes stable and V2 configuration, verification, security boundaries, and browser-ownership tradeoffs. See OpenCode's official MCP guide for the current stable schema.

Gemini CLI

Hronaut Home generates the current user-level ~/.gemini/settings.json entry with Gemini CLI's documented httpUrl field and authentication-aware headers. After saving it, run gemini mcp list to verify that Hronaut is connected. The public Gemini CLI browser MCP guide covers setup, observable verification, browser-lifecycle tradeoffs, and security boundaries. See Gemini CLI's official v0.57.0 MCP server guide for the verified configuration schema.

Goose