One MCP endpoint can operate several machines
AgentDock's default MCP endpoint is http://127.0.0.1:8765/mcp, and each instance controls the machine where it runs. The service exposes file, command, Git, browser, Skill, task, and dynamic MCP operations through Streamable HTTP. Adding instances lets one conversation reach a laptop, LAN host, or cloud server. AgentDock supplies execution and structured results; ChatGPT, Claude, Codex, or another compatible client supplies the model and conversation.
The breadth is useful when work crosses device boundaries. A request can inspect a process on a server, edit a repository on a workstation, or drive a browser with saved login state. Recoverable tasks keep goals and checkpoints for longer jobs. State lives under ~/.agentdock, while relative file and command operations start in ~/AgentDock. Those 2 paths organize the runtime, but neither replaces operating-system access controls.
The operating-system user is the security boundary
The security guide names 3 practical boundaries: runtime-user permissions, container mounts, and network policy. It says AgentDock is not a complete operating-system sandbox. A native service can reach whatever its runtime user can reach, while a Docker service is limited by its container user and mounted volumes. The recommended server pattern is a dedicated low-privilege account with access only to required project directories. Command execution and file modification are deliberate capabilities, so chat instructions cannot replace those host controls.
Network defaults are more conservative. The service listens on 127.0.0.1:8765, and a non-loopback address refuses to start unless Bearer Token or OAuth authentication is configured. OAuth requires a password of at least 12 characters and a persistent signing secret of at least 32 bytes. Public endpoints must use HTTPS. Those checks reduce accidental exposure, while the operator still decides who can authenticate and what the runtime account can do afterward.
What happened when we ran it
Our sandbox installed 78 packages in 33 seconds. Building commit 84abde2 succeeded in 31 seconds, and all 82 tests passed in 60 seconds. The repository occupied 5.5 MB before dependencies and contained 639 files with roughly 92,099 lines of source. Among these three assigned projects, AgentDock was the only available repository whose complete measured test step passed.
The checkout had 4 CI workflow files, a Dockerfile, and a Compose file. There was no top-level tests directory, which does not imply missing tests in a Go project because package tests usually live beside their source. The passing run is useful evidence about the checked-out commit under 3 CPUs and 8 GB of RAM. It does not show that a shell command chosen by an agent is safe or that a mounted home directory is appropriately restricted.
Web ChatGPT needs public HTTPS and OAuth
AgentDock's ChatGPT guide requires 3 things: a public HTTPS origin, OAuth, and an MCP URL ending in /mcp. Web ChatGPT cannot reach the local endpoint on port 8765. A temporary Cloudflare address works for a trial but can change after restart. A fixed address needs a Cloudflare-managed domain and Tunnel Token. Local clients can avoid that public setup and connect directly, with a Bearer Token when the deployment requires one.
Manual deployments must forward /mcp, /register, /oauth/*, and /.well-known/* through the reverse proxy. OAuth also needs the public server URL, a login password, and a token-signing secret that survives restarts. Closed issue 77 records one ChatGPT Plus user whose plugin appeared enabled but was not visible through the expected menus; the user later confirmed that asking ChatGPT directly to call AgentDock worked. That issue is useful troubleshooting evidence, not a permanent promise about every ChatGPT plan.
Browser and ACP features widen host access
Browser automation is disabled by default and can use Chrome, Chromium, or Edge after an operator enables it. Persistent profiles can retain logins, so the security guide recommends a dedicated browser profile. Docker cannot control the macOS desktop, and native desktop automation needs operating-system permissions. A browser session with cookies plus command access is a powerful combination; keep it away from a daily personal profile.
ACP is also disabled by default. Once enabled, it can start local coding-agent sessions and handle permission prompts. The configuration reference explicitly says ACP working directories have no AgentDock project-root allowlist and may use any directory accessible to the host process or container. Open issue 52 reports flashing console windows on Windows 11 during some v0.8.1 command calls. Open issue 41 reports Defender quarantining the v0.8.0 x64 binary, so Windows teams should test the current signed or unsigned artifact under their own endpoint policy.
v0.8.2 is active, with 2 fixes still awaiting merge
Release v0.8.2 shipped on September 4, 2026. It added a built-in user-guide Skill, expanded ACP adapter configuration, fixed OAuth metadata handling, and changed host environment forwarding to an explicit mapping. The release also added 10 MiB x 5 log rotation for several background-service paths. Release files have SHA-256 checksum companions, and the release workflow pulls and starts the published container image.
The last push was September 7, 2026, the day we fetched the repository. GitHub showed 671 stars and 4 open issues and pull requests: 2 issues and 2 pull requests. Pull request 67 proposes resource caps for fallback text search when ripgrep is absent. Pull request 68 would expose health details for dynamic MCP servers but says it is blocked on a protocol change. The activity is current and responsive; those open changes also show that resource limits and capability status are still being tightened.