Skip to content

Data sovereignty

AgentMux runs locally. The marketing summary is “zero telemetry”; this page is the detailed version, so you can verify it.

The following are stored only on the local filesystem and are never transmitted by AgentMux itself:

  • Session state. Every block, message, tool call, diff, and terminal output — all persisted in the local SQLite database under ~/.agentmux/state.db (path may vary by platform; see Persistence).
  • Prompts and replies. The full content of what you send agents and what they send back.
  • File contents agents read or write. When an agent reads or modifies a file, AgentMux records the diff in the local database. The file itself stays where it was.
  • Terminal output. PTY output is streamed into the local database and rendered in the pane. Not uploaded.
  • Identity bundle metadata. Provider, key name, scope — see Identity & credential storage for the full model.
  • Workspace layout and configuration. Pane positions, tabs, settings, themes.

The TL;DR: if you ran AgentMux on an air-gapped machine, you’d lose the ability to run agents (because the agents talk to LLM providers), but you’d lose nothing else.

Explicit negatives, verified by the security audit:

  • No telemetry. AgentMux makes no outbound HTTP calls to any AgentMux-controlled endpoint. No analytics, no usage pings, no feature-flag check-ins.
  • No crash reporting. Crashes are local. No exception data leaves the machine.
  • No version check. The app does not phone home for update availability. See Update model.
  • No license check. AgentMux is open source under Apache 2.0; there’s no license server to call.

The exceptions are scoped, explicit, and user-initiated:

When you launch an agent and send it a message, the agent’s CLI (Claude Code, Codex, Gemini, Copilot, etc.) makes HTTPS calls to the agent’s provider. AgentMux is not in the data path for these calls. The prompt goes from your machine directly to Anthropic / OpenAI / Google / GitHub, governed by their privacy policies. AgentMux records the call locally, but does not proxy it.

If you want to inspect or block this traffic, configure your network at the OS level (proxy, firewall, mitmproxy) — the agents will route through whatever you’ve set up.

MCP (Model Context Protocol) servers are processes the agent talks to over JSON-RPC. Whatever URLs or APIs an MCP server accesses are entirely the MCP’s behavior, not AgentMux’s. If you install a remote MCP server (one that opens an HTTPS connection to an external service), that connection is on you.

Local MCP servers (running as a subprocess on your machine) make no network calls unless they’re configured to.

When you install a tool from AgentMux’s tool catalog (e.g., installing an agent CLI), AgentMux downloads the binary from the URL in the catalog. Each download is SHA-256 pinned against the catalog entry — a mismatched hash is rejected. The URLs are typically GitHub release assets or upstream-vendor download endpoints.

The catalog itself ships with AgentMux. Adding a new tool is a code change, not a runtime fetch.

Cross-instance forwarding (opt-in, default off)

Section titled “Cross-instance forwarding (opt-in, default off)”

If you run multiple AgentMux instances on the same machine and enable the agentbus, they discover each other via a local file registry (~/.agentmux/instances/) and forward messages over 127.0.0.1 between them. No external network involved.

A separate cloud agentbus poller can be configured to receive inbound messages from a hosted relay; this is opt-in and off by default. See Reactive event bus once that page lands.

If you enable mDNS, AgentMux broadcasts on the local network (0.0.0.0:5353) to announce its presence to other AgentMux instances on the LAN. Off by default. When on, the only data broadcast is the instance ID and port — no session content.

SettingDefaultEffect
mDNS discoveryOffLAN broadcast of instance presence.
Cloud agentbus pollerOffInbound messages from a hosted relay.
Crash reportingNot applicable (none exists)
Update checkNot applicable (none exists)See Update model.

If you want to verify any of this for yourself:

  • Audit network traffic. Run AgentMux behind a packet inspector (mitmproxy, tcpdump, your firewall logs). All you’ll see is the LLM provider traffic from agent CLIs and any explicit user actions (tool download, etc.).
  • Read the source. The full outbound HTTP surface in the Rust backend is limited to: the tool store (agentmux-srv/src/backend/tool_store.rs), the cross-instance forwarder (agentmux-srv/src/server/reactive.rs), and the cloud agentbus poller (opt-in, see above). Search for reqwest::Client in the codebase to see every outbound call.
  • Inspect the SQLite database. ~/.agentmux/state.db is a normal SQLite file. Open it with the sqlite3 CLI to confirm what’s there.

Source-of-truth references:

  • agentmux-srv/src/backend/tool_store.rs — tool download path + SHA-256 pinning
  • agentmux-srv/src/server/reactive.rs — cross-instance forwarding
  • agentmux-srv/src/main.rs — mDNS opt-in default-off
  • ~/.agentmux/state.db — local persistence (see Persistence)

Marketing claims this page substantiates: “zero telemetry”, “data sovereignty by default”, “audit trail” on agentmux.ai.