AgentDock MCP: a Go runtime that gives AI clients shell, file and Git access on your own machines

The gap AgentDock fills: an execution layer, not another chat client

Most MCP servers are small: they wrap one API and expose a handful of tools. AgentDock takes the opposite position. The README states plainly that it does not provide a chat interface and does not perform model inference, and that it focuses on one responsibility: letting AI agents operate real environments within explicit permission boundaries and return structured, traceable, verifiable results. That sentence is the whole product thesis. The intended user is someone who already has a ChatGPT, Claude or Codex client they like and wants that client to touch a real machine. The README's own framing is blunt about the motivation: open ChatGPT in a browser and manage multiple computers and servers from one conversation, without consuming a dedicated Codex coding quota. That last clause matters. If your team pays per-seat for a coding agent, routing the same work through a general chat client plus a self-hosted runtime changes the cost shape. The audience is therefore operators: people with a Mac, a LAN host and a cloud VPS who already SSH between them and want one conversation to reach all three.

Architecture: one MCP endpoint per host, clients fan out over Streamable HTTP

The README's diagram is the clearest statement of the design. A client (ChatGPT, Claude or Codex) sits at the top and connects over MCP to multiple AgentDock instances, each running on a different machine: a local Mac, a LAN host, a cloud VPS. Each instance then reaches its own local surface, files, shell, Git, tunnels, proxies, deploys. There is no central coordinator process described in the material. Coordination happens because the client can hold several MCP connections at once and the user asks for cross-device work in a single conversation. That is a real architectural choice with consequences. It means there is no single AgentDock control plane to compromise, but it also means there is no single place where cross-device policy is enforced. Each instance carries its own authentication and its own boundaries. The transport is MCP Streamable HTTP, per the README, and the connection options are split three ways: local only (client and AgentDock on the same computer), a temporary public address for remote access where the README warns the address may change after the Tunnel restarts, and a fixed domain requiring a Cloudflare-managed domain and Tunnel Token. Those three modes are not cosmetic. They correspond to three different exposure profiles, and the README is explicit that public access must keep authentication enabled.

Getting a client connected: the actual config and the environment mapping

The README gives a concrete client configuration block. Under mcpServers you declare an entry named agentdock with a url of http://127.0.0.1:8765/mcp and a headers object containing Authorization with a Bearer token. That is the local-only shape. For remote use you replace the host with your tunnel address and keep the same header. Installation itself is deliberately not source-based: the README says regular users can install from the official package for their operating system and do not need the source code or Go, with separate documented paths for Docker, automated Linux install, manual systemd deployment on a VPS, macOS, and a graphical Windows installer. After installation you retrieve the MCP URL and either a Bearer Token or OAuth sign-in details from the control panel or terminal. One detail deserves attention because it is easy to miss. The exec_command tool does not inherit the AgentDock process environment. The README says it intentionally starts from a small environment, and that additional variables must be declared through an explicit child-to-host mapping, given as a JSON object in AGENTDOCK_COMMAND_ENV_FROM_ENV_JSON. The README's example maps NIX_LD and NIX_LD_LIBRARY_PATH. Only mapped variables are copied, and a missing host variable is skipped rather than causing an error. If a command fails on a host with an unusual library path, this variable is the first place to look.

Where the permission boundary is drawn, and where it is not

The README lists the guards: atomic file writes, path boundaries, private-directory protection, command execution with timeout and output limits, separate stdout, stderr and exit status, output truncation, and sensitive-value redaction. Those are meaningful defaults, and the separation of stdout from stderr with an exit status is the kind of detail that makes tool output actually usable by a model rather than a blob of merged text. But read the list carefully and note what it does not claim. There is no mention of a sandbox, no container isolation for command execution, no seccomp profile, no per-command allowlist. Path boundaries and private-directory protection constrain where file tools may write; they do not constrain what a shell command can reach once it runs. The environment mapping is the same story: it limits what is inherited by default, which is good hygiene, but any variable you map is then available to every command the agent runs. The README's warning about credentials, that public access must keep authentication enabled and that credentials should not appear in screenshots, issues or public conversations, is doing a lot of work here. Treat the boundary as authentication plus a set of tool-level defaults, not as a security sandbox.

Long-running sessions, PTY and the persistence claim

AgentDock advertises long-running command sessions with PTY, observation, input and termination, plus the ability to persist long-running task state and continue after an interruption. This is the feature that separates it from a stateless command wrapper, and it is also the one with the least detail in the supplied material. The README does not describe how session state is stored, what happens to a session when the AgentDock process restarts, or whether observation is polling or streaming. If your workflow depends on attaching to a long build or an interactive process, those are the questions to answer from the documentation site before committing. The platform coverage is broader than most tools in this category: macOS, Linux, Windows and WSL are all named, with the same tool model across them. Windows support in an MCP runtime is uncommon enough to be worth noting, though the README does not say whether the Windows path goes through WSL for shell execution or runs natively.

The honest comparison: AgentDock versus a plain SSH MCP server

The obvious alternative is a minimal MCP server that exposes a single shell tool over SSH to one host. That approach is smaller, easier to audit, and has no daemon to keep updated. The difference in approach is structural. A single-host SSH wrapper gives the client one connection to one machine and nothing else; every additional host is another server entry, and there is no shared model for files, Git or browser automation across them. AgentDock instead runs an agent on each host and standardises the tool surface, so files, commands, Git, Skills, MCP servers and browser automation all appear through the same interface regardless of which machine is behind it. The trade is a larger attack surface per host and a daemon you must run and upgrade. If your requirement is genuinely one machine and one shell, the smaller tool wins on auditability. AgentDock earns its size when you have three or more environments and want the same tool semantics on all of them.

Release cadence, licence and what upgrades cost you

The release history shows v0.8.1, v0.8.2 and v0.8.3 landing within roughly two weeks of each other in late August and early September 2026. That cadence is the maintenance cost in concrete form. A pre-1.0 project moving this fast will change tool behaviour between minor versions, and because AgentDock sits between your AI client and your machines, a behavioural change in a tool can alter what an agent does on a host without any change on your side. Pin a version, read the release notes before moving, and keep the previous binary available for rollback. The licence is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It also requires that you preserve copyright and licence notices and state significant changes if you redistribute a modified version. That is a summary of the licence text, not legal advice; if you plan to embed AgentDock in a product you ship, have counsel read the actual LICENSE file. The README does not describe a support contract, an enterprise edition or a hosted control plane, so the upgrade path is self-managed.

Editorial conclusion

Adopt AgentDock if you already run self-hosted Linux or macOS hosts and want an AI client to operate them through an authenticated MCP endpoint you control, rather than granting an agent broad remote access through some other channel. Do not adopt it as a way to give an agent unattended production access: the README describes path boundaries, private-directory protection, output truncation and sensitive-value redaction, but those are constraints on tool calls, not a substitute for a staging host. Before connecting a client, verify three things: that your MCP URL is not reachable without authentication, that AGENTDOCK_COMMAND_ENV_FROM_ENV_JSON maps only the variables your workloads genuinely need, and that your long-running command sessions have a timeout policy you have actually read.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. uvwt/agentdock on GitHub