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.

Authentication disabled

Use a non-secret local marker header

{
  "context_servers": {
    "hronaut": {
      "url": "http://127.0.0.1:47812/mcp",
      "headers": {
        "Authorization": "Hronaut local-no-auth"
      }
    }
  }
}

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.

Keep the browser; change the thread

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.