# Agenvoy: a self-hosted Go agent harness that writes and sandbox-tests its own tools

> Agenvoy ships as one Go binary, serves a dashboard on 127.0.0.1:17989, and exposes its sandboxed tool library to Claude Code, Codex and other MCP clients. The interesting part is tool generation; the part to check before adopting is what the documentation does not say.

**agenvoy/Agenvoy** — Self-hosted AI agent harness in a single Go binary — writes, sandbox-tests and repairs its own tools, and lets Claude Code, Codex and any MCP client build and share them.

- Repository: https://github.com/agenvoy/Agenvoy
- Website: https://agenvoy.com/
- Stars: 535 · Forks: 46
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/agenvoy-agenvoy

## The gap Agenvoy targets: an agent that produces a result file, not a paragraph

Most chat interfaces end at text. Agenvoy's pitch is that the agent should finish work on the machine it runs on: search live data, touch local files, run a scheduled report, and hand back an outcome. The README frames this as turning conversation into completed work, and the audience it names is narrow and specific: people who want research and recurring reporting turned into reusable automation, developers who want a self-hosted agent with local data control, teams that want Claude Code and Codex to share tools rather than each rebuild them, and operators who want private access to a local agent through Telegram or Discord. That last group matters more than it looks. The README states the local daemon connects outward to Telegram and Discord, so the host does not need inbound ports opened. If your constraint is a laptop behind NAT or a workstation you do not want exposed, that design choice is the reason to read further. If your constraint is a shared cluster with a service account, it is not aimed at you.

## One binary, a loopback dashboard, and an MCP server on the other side

The architecture visible in the repository is a single Go program with a TUI, an HTTP dashboard, a scheduler and an MCP surface. go.mod pins the pieces: bubbletea and lipgloss for the terminal interface, gin for HTTP, modelcontextprotocol/go-sdk for MCP, go-telegram/bot and discordgo for messaging, go-scheduler for recurring jobs, go-llm-router for model routing, and mvdan.cc/sh for shell parsing. The dashboard is embedded in the binary rather than served from a separate front end, which is why the README can say you start the daemon and open http://127.0.0.1:17989 with nothing else installed. The second role is the one worth pausing on. Agenvoy is also an MCP server, so Claude Code, Codex, OpenCode and other MCP clients connect to it and use the same sandboxed tools. When no suitable tool exists, the agent creates one, tests it in the sandbox, and keeps it for reuse. Two demo tools are checked into the repository, doc/demo/fetch_weather/ and doc/demo/fetch_crypto_price/, which is how the README illustrates a workflow where Claude Code builds a weather tool, Codex reuses it and adds a crypto tool, and Agenvoy tests both. That shared-library idea is the strongest technical argument for the project: tool definitions accumulate in one place instead of being rewritten per client.

## Installing Agenvoy and reaching the dashboard for the first time

The README does not print a package-manager command or a release-download table. It points at the project homepage, https://agenvoy.com/, and at the GitHub releases page for the binary, so the first step is to get a build for your platform from one of those two places. The repository also ships a makefile, so building from source is the documented-by-layout alternative. The module path in go.mod is github.com/pardnchiu/agenvoy and the required Go version is 1.25.1, so a source build needs at least that toolchain.

```bash
git clone https://github.com/pardnchiu/agenvoy
cd agenvoy
make
```

Running make in the repository root is the build entry point the repository provides. The README does not document the target names, so read the makefile before assuming what a given target produces.

Once a binary exists, the first real use is the dashboard. Start the daemon and open the loopback address in a browser:

```bash
./agenvoy
```

```text
http://127.0.0.1:17989
```

The README states the dashboard is served by your own machine, so nothing leaves the device. From there you manage sessions, tools, schedules and memory in the browser rather than the TUI. The README does not document the daemon's command-line flags, so the binary name and any start options should be confirmed against the release notes for v1.0.4 rather than guessed.

## Tool generation is the selling point and also the least documented part

The claim that Agenvoy writes, sandbox-tests and repairs its own tools is the reason to look at it, and it is also where the README stops being concrete. It says a tool is created when none exists and kept for reuse, and the two demo directories show what a finished tool looks like. What the README does not describe is the sandbox itself: which syscalls or paths are blocked, whether generated code runs in a container, a chroot, or a restricted shell, how long a test may run, and what happens when a generated tool passes its test and then misbehaves in production. The presence of mvdan.cc/sh/v3 in go.mod suggests shell parsing is involved in how commands are handled, but parsing is not isolation. Treat the sandbox as a design intent you must verify on your own host, not as a guarantee you can read off the README. The same caution applies to the confirmation flow: the README says sensitive paths and restricted actions require confirmation, which is a useful default, but it does not enumerate what counts as sensitive.

## Where Agenvoy is the wrong tool

Three cases stand out. First, if you need a documented threat model before you let an agent execute generated code on a machine that holds credentials, Agenvoy does not give you one yet; the confirmation prompts are a control, not an audit trail. Second, if your team standardises on a hosted agent platform with a managed control plane, self-hosting is a cost rather than a feature, and the loopback-only dashboard plus outbound Telegram and Discord connections will not fit an environment that expects central administration. Third, if you want a library to embed in your own Go service, this is not that: Agenvoy is an application with a TUI, a web dashboard and a scheduler, and the AGPL-3.0 licence plus the COMMERCIAL.md file in the repository root mean the terms for embedding it in a closed product are a separate conversation. None of these are defects. They are the boundaries of what a single-binary, self-hosted harness is for.

## How it differs from wiring MCP servers together yourself

The obvious alternative is to skip the harness and register individual MCP servers directly in each client's config. That approach is more transparent: every tool is a server you chose, with its own permissions, and nothing generates code on your behalf. The difference in approach is where tools come from. With hand-registered MCP servers, the set of capabilities is fixed by what you installed; Agenvoy's model is that the set grows at runtime when a request has no matching tool, and the new tool is then available to every connected client. You trade predictability for coverage. A second alternative is a general automation runner driven by cron and shell scripts, which is cheaper to reason about and has no model in the loop, but it cannot decide that a task needs a new capability, and it cannot describe a schedule in a sentence the way the README's scheduler example does. Agenvoy sits between those two: more adaptive than scripts, less inspectable than a hand-curated MCP config.

## Licence and the cost of keeping up

Agenvoy is licensed AGPL-3.0, and the repository root also contains COMMERCIAL.md, which signals that commercial terms exist separately from the open source licence. If you run the daemon for yourself, the network-copyleft obligation is unlikely to reach you. If you offer a modified Agenvoy as a network service, AGPL-3.0 is the clause to read carefully, and this article is not legal advice; read the LICENSE file and, if the answer matters commercially, COMMERCIAL.md as well. On upgrades, the release cadence is visible: v1.0.2 on 2026-09-07, v1.0.3 on 2026-09-08, v1.0.4 on 2026-09-09, with the last push to master on 2026-09-10. Three patch releases in three days is a fast-moving pre-1.1 line, and the README does not document a rollback procedure or a migration path between versions. The practical upgrade cost is therefore unknown rather than zero: go.mod pins exact dependency versions, so a source rebuild is reproducible, but you should keep your own copy of any generated tools and schedules before replacing a binary.

## Conclusion

Adopt Agenvoy if you already run Claude Code or Codex and want one sandboxed tool library shared across them, or if you need recurring local automation driven from a browser on your own machine. Do not adopt it if you need a documented security model, a published upgrade path, or a permissive licence for a closed product, because the README does not cover any of those. Verify first that the Go toolchain resolves the pinned dependencies in go.mod, that port 17989 is free on the host, and that the AGPL-3.0 and COMMERCIAL.md terms fit how you plan to distribute anything built on top of it.

## FAQ

### How do I start Agenvoy and get to the dashboard?

Start the daemon binary, then open http://127.0.0.1:17989 in a browser. The README states the dashboard ships inside the binary and is served by your own machine, so nothing leaves the device.

### Can Claude Code and Codex use the same tools through Agenvoy's MCP server?

Yes. The README describes Agenvoy as an MCP server that Claude Code, Codex, OpenCode and other agents connect to, using the same sandboxed tools and auto-building new ones when none exists. The README calls it one line of config.

### What licence does Agenvoy use?

AGPL-3.0, with a COMMERCIAL.md file alongside LICENSE in the repository root. The README does not explain the split, so read both files if you plan to offer it as a network service.

### Does Agenvoy need inbound ports opened to reach Telegram or Discord?

The README states the local daemon connects outward to Telegram and Discord, so your host does not need to be made public or to open inbound ports. The dashboard itself is bound to 127.0.0.1:17989.

## Sources

- [agenvoy/Agenvoy on GitHub](https://github.com/agenvoy/Agenvoy)
- [License: AGPL-3.0](https://github.com/agenvoy/Agenvoy/blob/master/LICENSE)
- [Project website](https://agenvoy.com/)
- [README](https://github.com/agenvoy/Agenvoy/blob/master/README.md)
- [Releases](https://github.com/agenvoy/Agenvoy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agenvoy-agenvoy