Agenvoy: a single Go binary that writes its own sandboxed tools and shares them over MCP
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.
At a glance
- What is it?
- Agenvoy is a self-hosted agent harness that runs a local daemon, a browser dashboard on 127.0.0.1:17989, and an MCP server so Claude Code, Codex and other clients can reuse the same tool library. The interesting part is tool synthesis under sandbox review; the awkward part is that the README never explains how that sandbox is built.
- Who is it for?
- Adopt Agenvoy if you want a local daemon that turns recurring work into scheduled jobs and shares generated tools with Claude Code or Codex over MCP, and if you are comfortable reading Go source to confirm how tool generation is sandboxed. Do not adopt it if you need a hosted service, a documented plugin API, or a guarantee that a generated tool is safe before it runs.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Agenvoy targets: chat answers versus finished work
The README frames the problem in one line: a chat can give you an answer, work needs a result. Agenvoy is positioned as the layer that closes that gap on your own machine. The stated audience is narrow and practical: people who want research, file work and recurring reporting turned into reusable automation; developers who want a self-hosted agent with local data control and sandbox guardrails; teams that want Claude Code, Codex and other agents to share tools instead of rebuilding them; and technical operators who need private access to a local agent through Web, Telegram or Discord. That last group matters because the daemon is described as connecting outward to Telegram and Discord rather than opening inbound ports on the host. If you already run an agent framework and your complaint is that each client reimplements the same fetch-and-parse tool, Agenvoy is aimed squarely at you. If your complaint is that your agent cannot reason well, this project does not claim to fix that; it routes models and supplies tools.
How the harness is put together: daemon, dashboard, MCP server
The architecture visible in the material is a local daemon plus several front ends. The dashboard ships inside the binary and is served at http://127.0.0.1:17989 once the daemon starts, and the README states it is served by your own machine. Command output streams to both the TUI and the Web dashboard, so the terminal and browser views are two surfaces over the same session state. On the client side, Agenvoy is also an MCP server: Claude Code, Codex, OpenCode and other agents connect and use the sandboxed tools, and the README says new tools are auto-built when none exist. The repository topics list both mcp-client and mcp-server, so the project sits on both sides of that protocol. Model routing is described as per-task, with image generation, STT, TTS and stdio or HTTP MCP servers configurable, and the topic list names OpenAI, Gemini, Grok, Mistral, DeepSeek, Cloudflare AI, NVIDIA NIM and OpenRouter as providers. What the README does not give is a request path diagram or a description of how the scheduler, memory and tool registry interact at runtime. That is a documentation gap, not a design flaw, but it means the only way to confirm the data flow is to read the Go source.
Tool generation and repair: the claim that needs the most scrutiny
The headline capability is that Agenvoy creates, tests and keeps a new tool when no suitable one exists, ready to reuse next time. The demo material names two generated examples, fetch_weather and fetch_crypto_price, under doc/demo/, and the README describes a three-part sequence in which Claude Code creates a weather tool, Codex reuses it and creates a crypto tool, and Agenvoy tests both. That is the most concrete evidence in the supplied material that the shared-library claim is real rather than aspirational. What is missing is the mechanism. The README uses the phrase sandbox guardrails and says sensitive paths and restricted actions still require confirmation, but it does not state whether generated tools run in a container, a restricted subprocess, a syscall filter, or something else. Nor does it say what happens when a generated tool fails its test. The description says the harness repairs its own tools, but the repair loop is not described in the README text available here. Before you let a generated tool touch a working directory, that gap is the thing to close by reading the source, not by trusting the summary.
Getting it running: dashboard, daemon and the MCP config line
The README gives one concrete address and one concrete claim about setup. Start the daemon, then open http://127.0.0.1:17989 in a browser to manage sessions, tools, schedules and memory. For the MCP side, the README promises one line of config to connect Claude Code, Codex or OpenCode to the shared tool library, but the cleaned README text does not include that line. Treat this as something to retrieve from the repository rather than guess at. The same applies to configuration keys: the README names the categories that are configurable, including per-task model routing, image generation, STT, TTS, and stdio or HTTP MCP servers, plus OAuth, but it does not print key names in the material available here. Schedules are created conversationally: the README shows a request like reporting a stock price every morning at 8am, after which the agent asks where to push results, what format you want and when to run, then creates the schedule. That is a usable entry point. Everything past it, including the daemon start command itself, has to come from the repository files.
Where Agenvoy is the wrong choice
Three cases stand out. First, if you want a managed service, this is not one. It is a binary you run, with a dashboard bound to 127.0.0.1 and a daemon that connects outward to messaging platforms. You own the host, the updates and the failure modes. Second, if you need a stable plugin API with versioned contracts, the material describes tools that are generated on demand, and generated code is not a contract. A tool that works today can be regenerated or repaired into different behaviour, and the README does not describe a pinning or review step before a generated tool becomes available to every connected agent. Third, if your work is mostly reasoning over text you already have, the tool-generation and scheduling machinery is overhead. The scheduler asks clarifying questions and creates recurring jobs; that is useful for reporting pipelines and unnecessary for a one-off question. There is also a licensing boundary worth naming: AGPL-3.0 is a strong copyleft licence, and if you expose a modified Agenvoy over a network, the licence's network-use provision is the clause your legal reviewer will want to read. That is a pointer, not legal advice.
Alternatives and the actual difference in approach
The obvious comparison is with the agent clients Agenvoy plugs into. Claude Code and Codex are the primary interfaces developers already use, and Agenvoy does not replace them; it registers as an MCP server so they can call its tools. The difference is where the tool lives. In a plain client setup, a tool you write for Claude Code stays in that client's configuration and Codex does not see it. In Agenvoy's model, the tool is created once, tested by the harness, and served over MCP to every connected client, which is what the weather-then-crypto demo is meant to show. The other comparison is with general agent frameworks that expect you to write your own tool definitions and sandboxing. Agenvoy's position is that it supplies both, plus a scheduler and local file search, in one binary. The trade-off is control: a framework where you write the tools gives you a reviewable artifact per tool, while a harness that generates them gives you speed and a smaller amount of code you personally wrote. Which one you want depends on whether you would rather review a tool or trust a test.
Maintenance, release cadence and licence cost
The repository shows three releases in four days: v1.0.2 on 2026-09-07, v1.0.3 on 2026-09-08, and v1.0.4 on 2026-09-09, with the last push on 2026-09-10. That is a fast patch cadence on a 1.0 line, which cuts both ways. You get fixes quickly, and you also get a moving target if you pin to a specific build for reproducibility. The single-binary distribution keeps upgrade cost low in one respect: there is no runtime to install alongside it, no Python environment to reconcile, and the dashboard is embedded. The cost that does not go away is the AGPL-3.0 obligation. Running Agenvoy privately on your own machine is the ordinary case the README describes, with the dashboard on loopback and the daemon dialling out. Modifying it and letting other people interact with it over a network is the case where the licence's source-availability requirement becomes relevant. For internal, unmodified use the practical burden is small; for a hosted derivative it is not. Confirm your own situation with counsel rather than with a README.
What to verify before you install it
Start with the sandbox. Find the code path that executes a generated tool and confirm what isolation it uses, because the README's claim that sensitive paths and restricted actions require confirmation is only as good as that implementation. Next, locate the MCP client configuration line the README refers to, since one line of config is the entire integration story for Claude Code and Codex and it is not printed in the text available here. Then check the configuration surface for model routing and the stdio or HTTP MCP server entries, and confirm which providers are actually wired up rather than merely listed as topics. Finally, decide how you feel about generated tools entering a shared library that every connected agent can call. If you want a per-tool review gate before that happens, check whether the project offers one; if it does not, that is the boundary of what you are adopting.
Editorial conclusion
Adopt Agenvoy if you want a local daemon that turns recurring work into scheduled jobs and shares generated tools with Claude Code or Codex over MCP, and if you are comfortable reading Go source to confirm how tool generation is sandboxed. Do not adopt it if you need a hosted service, a documented plugin API, or a guarantee that a generated tool is safe before it runs. Before committing, verify three things in the repository: the sandbox mechanism behind tool testing, the exact MCP client config line, and whether AGPL-3.0 section 13 network-source obligations apply to how you expose the daemon.
Community notes