AgentDock MCP: a self-hosted runtime that lets ChatGPT drive your machines

The gap AgentDock fills between a chat window and a real machine

Most agent tooling stops at the edge of a sandbox. The agent writes files into a temporary directory, runs a command in an ephemeral container, and the result never touches the machine you actually deploy from. AgentDock takes the opposite position. It is a runtime that gives an AI client controlled access to the real environment: local workstations, LAN hosts, cloud VPS instances, and containers. The README frames the responsibility narrowly, saying AgentDock "does not provide a chat interface or perform model inference" and instead lets agents "operate real environments within explicit permission boundaries and return structured, traceable, and verifiable results."

The intended user is someone who already has machines to manage and an AI client to manage them with. The README's own example is opening ChatGPT in a browser and handling several computers and servers from one conversation, including code edits, configuration changes, command execution, and deployment. A second stated motivation is quota: the README claims you can do this "without consuming a dedicated Codex coding quota." That is a positioning statement rather than a measured result, and it depends entirely on which client you connect.

What makes the project more than a remote shell wrapper is the multi-instance model. The architecture diagram shows one client connecting to several AgentDock instances at once, labelled Local Mac, LAN Host, and Cloud VPS, each with its own downstream surface (files, shell, Git on one; tunnels on another; proxy and deploy on a third). Coordination happens across those instances inside a single conversation rather than through repeated SSH sessions.

MCP Streamable HTTP, a Bearer token, and a deliberately small command environment

AgentDock speaks MCP over Streamable HTTP. The client configuration in the README points at a local URL and carries an Authorization header:

{
  "mcpServers": {
    "agentdock": {
      "url": "http://127.0.0.1:8765/mcp",
      "headers": {
        "Authorization": "Bearer <AGENTDOCK_AUTH_TOKEN>"
      }
    }
  }
}

The Go module file lists github.com/modelcontextprotocol/go-sdk v1.7.0 and github.com/uvwt/agentdock-protocol v0.8.1, so the MCP layer is the official Go SDK plus a project-specific protocol package. OAuth is also present as a dependency (github.com/go-oauth2/oauth2/v4), which matches the README's mention of "Bearer Token or OAuth sign-in details" from the control panel or terminal.

One design decision deserves attention. The README states that exec_command "intentionally starts from a small environment instead of inheriting the complete AgentDock process environment." Variables are forwarded only through an explicit child-to-host mapping, given as an environment variable containing JSON:

export AGENTDOCK_COMMAND_ENV_FROM_ENV_JSON='{"NIX_LD":"NIX_LD","NIX_LD_LIBRARY_PATH":"NIX_LD_LIBRARY_PATH"}'

The README notes that only mapped variables are copied and that a missing host variable is skipped. This is the right default for a tool that runs untrusted-ish instructions on a production host, but it breaks anything that assumes a full inherited environment. Nix-based toolchains are the example the README itself uses, which suggests the maintainers hit this problem directly.

The tool surface described in the README is broad: file reads and structured edits with atomic writes and path boundaries, command execution with timeouts and output limits, long-running sessions with PTY support, output truncation and sensitive-value redaction, Git operations, browser automation over chromedp, Skills, and dynamic MCP servers. The chromedp dependency (v0.14.2) confirms the browser path is native Go rather than a wrapper around an external driver.

Installing AgentDock from the package or from Docker Compose

The README directs regular users to the official package for their operating system and says you do not need the source code or Go. Platform-specific pages exist for Docker, Linux, Linux/VPS with systemd, macOS, and Windows. Because the exact package commands live on those documentation pages rather than in the README, the reproducible path available here is the Compose file.

First create a .env from the example and set a real token. The Compose file requires it: the variable is written as `${AGENTDOCK_AUTH_TOKEN:?set AGENTDOCK_AUTH_TOKEN before docker compose up}`, so Compose refuses to start without it.

cp .env.example .env
# edit .env and replace replace-with-a-random-token with a real random value

The .env.example also carries AGENTDOCK_SERVER_URL (a fixed HTTPS origin for a Named Tunnel, left empty for a Quick Tunnel) and TUNNEL_TOKEN, which the file marks as needed only for Named Tunnel and warns not to commit.

Then start the service. The default image is ghcr.io/uvwt/agentdock:latest, and the published port defaults to 127.0.0.1:8765 on the host.

docker compose up -d

A healthcheck runs `agentdock-healthcheck` every 30 seconds with a 10 second start period, so `docker compose ps` should show the container as healthy before you connect a client. State lives in two named volumes: agentdock_home at /home/agentdock/.agentdock and agentdock_workspace at /home/agentdock/AgentDock.

For temporary public access, the Compose file defines a cloudflare-quick profile that runs cloudflared against http://agentdock:8765. The README warns that this address may change after the Tunnel restarts. For a stable address you need a Cloudflare-managed domain and a Tunnel Token. Once running, take the MCP URL and token from the control panel or terminal and paste them into the MCP, Tools, or Connectors settings of your client, using the JSON shape shown earlier in this article. The README is explicit that public access must keep authentication enabled and that credentials should not appear in screenshots, issues, or public conversations.

Where AgentDock is the wrong tool

The container defaults to listening on 0.0.0.0 inside the container, and the Compose comment states that a token is therefore mandatory. That is a correct default for containers and a dangerous one for the human reading the file, because the host-side publish binding is what actually decides exposure. The default `${AGENTDOCK_PUBLISH_HOST:-127.0.0.1}` keeps it local, but changing that variable to 0.0.0.0 on a VPS with no firewall puts an authenticated remote-execution endpoint on the public internet. The README's own warning about keeping authentication enabled reads as an acknowledgement of that risk.

Browser automation has a sharper boundary. The Compose comments state that a container cannot enumerate host processes or profiles, so automatic discovery only applies to the container's own environment. If you want AgentDock in Docker to drive the Chrome you already have open on your desktop, you must set AGENTDOCK_BROWSER_CDP_URL explicitly and enable AGENTDOCK_BROWSER_REUSE_EXISTING_CDP. The browser image also needs a larger /dev/shm, which is why shm_size is set to 1gb.

If you want a hosted product with a chat interface, an account system, and no server to run, AgentDock is the wrong shape. It has no chat UI and no inference of its own, so you must bring a client. If your threat model forbids an AI client from touching production at all, no amount of token configuration fixes that; the tool's entire purpose is to execute commands in real environments.

The maintenance picture is current rather than settled. The repository is not archived, and the last push was on 2026-09-10, with v0.8.3 tagged on 2026-09-09. That is a fast release cadence, which for a tool holding shell access to your machines means you should read release notes before upgrading rather than tracking latest blindly.

How AgentDock differs from a plain MCP filesystem or shell server

The closest alternative is a single-purpose MCP server, such as a filesystem server or a shell server, connected directly to your client. The difference is scope and boundary handling. A filesystem server gives you one class of operation over one directory tree. AgentDock bundles files, commands, Git, browser automation, Skills, and dynamic MCP servers behind one endpoint, and adds what the README calls "atomic file writes, path boundaries, and private-directory protection" plus output truncation and sensitive-value redaction. If all you need is to let an agent read a docs folder, a filesystem server is fewer moving parts and a smaller blast radius.

The second alternative is an SSH-based agent setup, where the client is given credentials and shells out. That works, but every session re-establishes context, and there is no structured result format. AgentDock's stated goal of returning "structured, traceable, and verifiable results" and persisting long-running task state is aimed at exactly that friction. The trade-off is that you now run a long-lived service with a token instead of holding SSH keys.

A third comparison is against hosted agent platforms that ship their own execution sandbox. Those are easier to start with and keep the agent away from your production hosts. AgentDock inverts that: the value is that the work happens "in the real environment where the work belongs," as the README puts it, and the cost is that you own the security boundary. Multi-device orchestration is the feature neither a single filesystem server nor a hosted sandbox offers, and it is the main reason to accept that cost.

Licence, upgrade cost, and what the repository does not tell you

AgentDock is licensed under Apache-2.0, with the LICENSE file at the repository root. That permits commercial use and modification and includes a patent grant, but it also carries attribution and notice requirements; if you redistribute a modified build, the Apache-2.0 terms apply to what you ship. This is a description of the licence text, not legal advice, and the Dockerfile pins base images by digest, which matters if you rebuild for compliance reasons.

Upgrade cost is dominated by the protocol package. go.mod depends on github.com/uvwt/agentdock-protocol v0.8.1, a version that trails the v0.8.3 release tag. If the protocol package changes shape between releases, a self-built binary and a released binary can disagree about message format. Building from source is supported (the Dockerfile compiles ./cmd/agentdock with Go 1.26.5 and stamps commit and build date via ldflags), but the README does not document a rollback procedure, and the Compose file's named volumes hold persistent state at /home/agentdock/.agentdock. Downgrading an image without checking whether that state format changed is the risk the documentation leaves open.

Two other things the README does not settle. There is no stated compatibility matrix for which MCP client versions are supported beyond the generic MCP Streamable HTTP description. And the README's claim about avoiding a dedicated coding-agent quota is a positioning claim, not a documented measurement; treat it as an intent, not a guarantee.

Editorial conclusion

Adopt AgentDock if you already run your own hosts and want a chat client to operate them under a token you control. Skip it if you need a managed service, a built-in chat UI, or model inference: the README states plainly that AgentDock provides neither. Before rolling it out, verify the AGENTDOCK_AUTH_TOKEN is set to a real random value and that port 8765 is bound to 127.0.0.1 rather than 0.0.0.0 on any host reachable from the internet.

Frequently asked questions

Official sources

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