Mistral Vibe browser MCP
Hronaut runs a separate visible Chromium application. Vibe CLI and the local VS Code extension can share one Streamable HTTP configuration while named browser workspaces, sign-ins, and debugging state remain available between agent sessions.
Hronaut is an independent project and is not affiliated with or endorsed by Mistral AI.
Local MCP endpoint
http://127.0.0.1:47812/mcpThis guide is for Vibe running locally on the same computer as Hronaut. Vibe Code Web runs in a remote environment and cannot reach a loopback service on your desktop.
One local configuration
Vibe's local CLI and VS Code extension share the same engine, config.toml, MCP servers, profiles, and conversation history. Vibe can also run through ACP-compatible local IDEs. The Web surface is different: its repository and agent run remotely, outside the desktop loopback boundary.
User-level setup
Append the matching entry to ~/.vibe/config.toml. Vibe otherwise treats remote servers as OAuth candidates, while Hronaut supports either no authentication or its own bearer token—not OAuth.
Authentication disabled
[[mcp_servers]]
name = "hronaut"
transport = "streamable-http"
url = "http://127.0.0.1:47812/mcp"
[mcp_servers.auth]
type = "static"
headers = { "Authorization" = "Hronaut local-no-auth" }The marker is not a credential. Hronaut ignores authorization values while authentication is disabled; the explicit static block prevents Vibe from starting an OAuth login that Hronaut does not provide.
Authentication enabled
[[mcp_servers]]
name = "hronaut"
transport = "streamable-http"
url = "http://127.0.0.1:47812/mcp"
[mcp_servers.auth]
type = "static"
api_key_env = "HRONAUT_MCP_TOKEN"
api_key_header = "Authorization"
api_key_format = "Bearer {token}"Enable Require MCP authentication in Hronaut, then load the owner token into HRONAUT_MCP_TOKEN before launching Vibe. Hronaut Home identifies the owner-only token file without rendering its value.
Keep the token out of config.toml, project files, chat, screenshots, and shell history. Vibe's environment-backed API-key fields produce the header without storing the credential in this configuration.
Current Vibe configuration uses a nested [mcp_servers.auth] block. Older top-level header and API-key fields remain accepted, but this guide uses the current shape rather than the legacy compatibility form. Current Vibe configuration reference ↗
Observable verification
1 · Reload
Start or restart Vibe after editing config.toml. In an existing session, run /reload so the process reads the updated file.
2 · Server status
Run /mcp hronaut. Vibe should list tools with the hronaut_ prefix. Then confirm the live client appears under Connections on Hronaut Home.
3 · Browser task
Ask: “Using Hronaut, 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
Vibe exposes MCP tools under {server_name}_{tool_name}. Per-tool permission blocks accept ask or always; keep browser-control tools on ask until you have reviewed the profile and task. Avoid auto-approve or --yolo for valuable signed-in browser sessions.
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
/reload and /mcp verification behavior.Keep the browser; change the agent surface
Named workspaces isolate cookies and storage from the human Default workspace while remaining available when you move between Vibe CLI, the local VS Code extension, or another compatible local MCP client.