Kody: a self-hosted home for an AI agent's memory, keys and code

The problem Kody addresses: an agent's state, scattered across hosts

Most assistant setups lose their context the moment you switch tools. Memory lives in one chat product, API keys live in a shell profile, and the small scripts the agent wrote for you live nowhere in particular. Kody's pitch, as the README puts it, is to be "your assistant's home": the memory, keys, code and automations an agent keeps, presented through MCP so that any compatible host can reach the same store. The scope section is blunt about what this is not. It is a fair source personal assistant platform, not a general-purpose agent harness. If your goal is to plug any model into any tool and let it improvise, Kody is aimed elsewhere. The intended user is someone who wants a single durable account with packages, jobs, secrets and memories attached, reachable from ChatGPT (named in the README as a likely primary host target) and from other MCP hosts where practical. The multi-user design matters here: each signed-in user gets an isolated assistant, and the README states that no account is privileged at runtime. That is a different shape from a single-tenant local MCP server that assumes one operator.

Four Workers, one origin, and where each request lands

The architecture diagram in the README is the clearest part of the documentation. kody.codes resolves to kody-production, which holds the Remix origin, the /mcp HTTP endpoint, OAuth, email and queues. From there it fans out to three sibling workers: kody-platform for MCP, mailbox, meter and repo-session Durable Objects; kody-runtime for package apps, the invoke API and a component called StorageRunner; and kody-jobs for cron plus a JobManager that calls back through something the README calls JobsHost. A second zone, kody.run, routes package-app traffic to kody-runtime. The request order in packages/worker/src/index.ts is stated plainly: OAuth requests are handled first, then MCP requests, then static assets, with non-asset requests falling through to the server handler and router. Client assets are bundled into packages/worker/public/ and served through the ASSETS binding. The state layer is split by purpose rather than convenience: D1 for the database, KV for session and OAuth, and Durable Objects on kody-platform for MCP state. That last choice is the one worth noting. MCP sessions are stateful, and putting them in Durable Objects means the platform worker owns coordination rather than the origin. The cost is that the origin is not self-contained; a local dev loop still has to bring up the platform and runtime workers.

A compact MCP surface with search and Code Mode execute

The design decision that separates Kody from most MCP servers is stated in the README without much hedging: the project favors a small MCP surface with search and Code Mode execute flows over a large static tool catalog. Instead of registering fifty named tools, the server exposes a search step to find what is available and an execute step that runs code against it. This is a real trade-off and not an obvious win. A static catalog is inspectable: a host can list every tool and a user can read the names. A search-then-execute surface asks the model to discover capability at runtime, which puts more weight on the search results and on whatever sandbox runs the execute payload. The README does not describe that sandbox in the material available here, and it does not say how search ranks results. Anyone evaluating Kody for a locked-down environment should treat that gap as the first thing to resolve, because the security boundary of a Code Mode design lives in the execute path, not in the tool list. The upside is that the surface stays stable as the underlying capabilities grow, which fits a project that ships a release most days.

Getting it running: two commands, one port, and a lot of docs

The quick start in the README is short. Run npm install, then npm run dev. The dev server comes up at localhost:3742 by default, and the CLI picks the next free port if that one is taken, printing the resolved URL. Wrangler handles the local Cloudflare Workers runtime and the D1 database automatically, so there is no separate database to start. Two pointers follow the commands. Full setup paths and environment variables live in docs/contributing/getting-started.md, and contributors or agents are told to start with AGENTS.md for repo-specific guidance. If you are trying to work out what the repository is for, the README sends you to docs/contributing/project-intent.md. That last document is the one I would read before the quick start, because the scope section of the README already signals that Kody has non-goals, and project-intent.md is where they are presumably spelled out. The README does not list the environment variables inline; it points at docs/contributing/environment-variables.md for adding new ones and docs/contributing/cloudflare-offerings.md for optional Cloudflare integrations. Note the distinction in the quick start between running Kody and scaffolding a new project: npx create-epicflare creates a fresh project from the epicflare template, which is not the same thing as running this repository.

Monorepo layout and the maintenance tax it implies

Kody is an Nx monorepo with npm workspaces. Shared modules sit in packages/shared under the @kody-internal/shared name. The origin app is packages/worker, with siblings at packages/platform-worker, packages/runtime-worker and packages/jobs-worker, plus mock Workers under packages/mock-servers/*. The README notes that the repo follows several epicflare starter conventions, which is a useful signal: if you have seen an epicflare project before, parts of the layout will be familiar, and if you have not, you are learning two sets of conventions at once. The release cadence is the part to weigh honestly. The repository shows releases on three consecutive days in September 2026, each tagged with a date, and the last push to main is timestamped the same day as the newest release. A project that cuts a dated release daily is not promising stability between versions; it is promising that fixes arrive quickly. For a personal assistant you host yourself, that is a reasonable trade, but it means you should expect to redeploy often and should not treat any single tag as a long-term support line. The README does not describe a migration or upgrade procedure, and no changelog content is included in the material, so the practical cost of moving between dated releases cannot be judged from what is here.

Licence and the NOASSERTION label

The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not match the licence file to a known identifier. The README calls Kody a fair source personal assistant platform, and the contributing section mentions that outside pull requests require a signed inbound Contributor License Agreement, with the text truncated in the material available. Those two facts together describe a project that is source-available on its own terms rather than under a standard open source licence, but the exact terms are not visible here. I am not going to guess at them and this is not legal advice. If you plan to run Kody for a team, or to modify it and redistribute it, read the licence file in the repository and the full CLA text before you commit. The CLA requirement is worth flagging for a second reason: it shapes who can contribute and on what basis, and a project that requires a signed inbound agreement typically retains the option to relicense. That is a normal arrangement, but it is a different proposition from a permissively licensed library you can fork without paperwork.

Where Kody is the wrong choice, and what to use instead

Two cases stand out. The first is anyone who wants an assistant without operating infrastructure. Kody is a Worker fleet with D1, KV, Durable Objects and a cron worker; the quick start is two commands, but production is a multi-worker deployment with OAuth, email and queues, and the README points at docs/contributing/architecture/index.md for the production topology. If you do not already run Cloudflare Workers, the setup cost is real. The second case is a team that needs a fixed, auditable tool list. The compact search-and-execute surface is a deliberate choice, and if your review process requires enumerating every action an agent can take, that choice works against you. For that second case, the natural alternative is a plain MCP server that registers one tool per capability, such as the reference filesystem or Git servers that ship with explicit tool names. The difference is not quality; it is where discovery happens. A static catalog moves discovery to install time, so a reviewer can read the list. Kody moves it to runtime, so the model searches and then executes, and the surface stays small as capabilities grow. If your environment can accept runtime discovery and you want the state layer, Kody's model is the more scalable one. If it cannot, a named-tool server is the safer shape, and you give up the shared memory, secrets and job store that Kody exists to provide.

Who should adopt Kody, and what to check first

Adopt Kody if you already deploy to Cloudflare Workers, you want one MCP endpoint that carries memory, secrets, packages and scheduled jobs for a signed-in user, and you are comfortable running a platform that releases most days. The multi-user isolation described in the README, where each account gets its own packages, jobs, secrets and memories, is the feature that makes it usable beyond a single operator. Do not adopt it if you need a frozen tool catalog for review, if you want a managed service with no Workers to operate, or if you cannot accept a source-available licence whose exact terms are not stated in the repository metadata. Before you install anything, read docs/contributing/project-intent.md to see the non-goals in the project's own words, open the licence file behind the NOASSERTION label, and trace what packages/jobs-worker does on a cron tick, since that worker calls back into the platform and is the part of the topology the README describes least. If those three checks come back clean for your environment, the two-command dev loop at localhost:3742 is a low-cost way to see whether the search-and-execute MCP surface fits how your host actually calls tools.

Editorial conclusion

Kody is for engineers who already run Cloudflare Workers and want one MCP endpoint that carries an agent's memory, secrets, packages and cron jobs across hosts. It is not for anyone who wants a hosted assistant with no infrastructure to operate, or who needs a stable tool catalog, since the README describes the MCP surface as intentionally compact and Remix 3 is still beta. Before adopting, read docs/contributing/project-intent.md for the stated non-goals, check the licence terms behind the NOASSERTION label, and confirm what packages/jobs-worker does under your own cron schedule.

Official sources

1. Issues
2. kentcdodds/kody on GitHub
3. Project website
4. README
5. Releases