Hronaut runs a separate visible Chromium application. Zed Agent—or an external ACP agent launched inside Zed—can use its browser tools while named workspaces, sign-ins, and debugging state remain available after one thread ends.
Hronaut is an independent project and is not affiliated with or endorsed by Zed Industries.
Local MCP endpoint
http://127.0.0.1:47812/mcp
The loopback endpoint is reachable only from the computer running Hronaut. Configure it in the local Zed application, not in a remote machine or container that cannot reach host loopback.
One server, two local agent paths
Zed can use Hronaut directly or forward it over ACP.
Zed Agent uses servers from Zed's context_servers settings directly. Zed can also forward those servers to external agents over Agent Client Protocol. A terminal thread is different: its CLI reads that client's own native MCP configuration, so use the matching Hronaut client guide instead.
Local user setup
Add Hronaut as a custom remote server.
Open Settings → AI → MCP Servers → Add Server → Add Remote Server, or run zed: open settings file and add the entry below under context_servers.
The marker is not a credential. Hronaut ignores authorization values while authentication is disabled. It is present because Zed otherwise starts its standard OAuth flow for a remote entry without an Authorization header, while Hronaut does not provide OAuth.
Authentication enabled
Keep the actual bearer token in local user settings
Enable Require MCP authentication in Hronaut, then replace the marker with Bearer <token from the owner-only file> in Zed's local user settings. Hronaut Home identifies that private file without displaying its value.
Zed's current MCP documentation shows literal header values but does not document file or environment interpolation for context_servers. Do not invent a placeholder, commit the token, paste it into chat, or place it in project settings.
Zed's official MCP guide documents the remote url and headers shape, automatic OAuth behavior when the authorization header is absent, and the Settings UI flow. Read the current Zed MCP documentation ↗
Observable verification
Verify the server before trusting a browser task.
1 · Server status
Look for the green indicator
Open Settings → AI → MCP Servers. The dot next to hronaut should be green and its tooltip should say Server is active.
2 · Runtime
Watch Hronaut Home
Confirm the Zed connection appears under Connections. This proves a live client reached the browser, not only that the JSON parsed.
3 · Browser task
Create an isolated workspace
Ask: “Using the Hronaut MCP server, create a workspace named first-check, open https://example.com inside it, and tell me the page title and workspace ID. Do not use my Default workspace.”
Expect a visible first-check workspace showing Example Domain.
Tool and browser authority
Keep confirmation on for durable browser access.
In Zed v0.224.0 and later, agent.tool_permissions.default controls approvals; confirm is the default and includes MCP calls. Keep it unless you have reviewed the individual Hronaut tools and the browser profile they can reach. Agent profiles decide whether MCP tools are available, while tool permissions decide whether calls require confirmation.
A new Hronaut profile starts without authentication. In that mode, any process running as your user can control it. Enable authentication before storing valuable signed-in sessions, and pause MCP before entering passwords, security keys, payment details, or other human-only information.
Primary sources
Configuration and agent-path evidence.
Zed MCP documentation — remote server configuration, headers, OAuth behavior, status, ACP forwarding, and tool approvals.
Zed agent paths — the distinction between Zed Agent, external ACP agents, and terminal threads.
Use a named Hronaut workspace for every durable browser job.
Named workspaces isolate cookies and storage from the human Default workspace while remaining available to the next Zed thread—or another compatible local MCP client.