Zoo Code: a VS Code agent fork of Roo Code, reviewed for adoption

What Zoo Code replaces, and who actually needs it

The problem Zoo Code targets is context switching. You read a spec in one window, edit in another, run tests in a terminal, and paste error output back into a chat box. Zoo Code collapses that loop into the editor: it reads files, writes diffs, runs commands, and answers questions about the codebase from inside VS Code. The README frames the audience as developers who want "Your AI-Powered Dev Team, Right in Your Editor", and the feature list backs the framing with MCP server support, custom modes, and multi-root path controls.

The project is explicit about its lineage. It continues development after "the Roo team wound down active Roo Code work to focus on Roomote". The core team describes itself as former Roo contributors. That matters for adoption: you are not evaluating a greenfield tool, you are evaluating a continuation with a migration guide at docs.zoocode.dev/roo-to-zoo-migration. If you never used Roo Code, the migration path is irrelevant and the feature set is what counts.

Modes, MCP servers, and the orchestration layer

The visible architecture is a VS Code extension plus a webview UI, built from a pnpm workspace with apps/, packages/, src/, and webview-ui/ directories at the top level. Modes are the organising abstraction. Code Mode handles edits and file operations, Architect Mode plans systems and migrations, Ask Mode answers questions, Debug Mode traces issues and adds logs, and Custom Modes let a team define its own. Each mode is effectively a different system prompt plus a different tool policy, which is why the README lists per-mode MCP restrictions as a feature.

Orchestration is where the fork claims ground over its parent. The README points to "safer delegation, parallel task coordination, reliable parent/child task recovery, and better isolation between subtasks and provider profiles". Read that as a statement about task lifecycle management: subtasks can fail or be interrupted, and the parent needs to recover state without bleeding one provider profile's credentials into another's context. The repository supports the claim with model-check scripts such as scripts/check-task-lifecycle.ts and scripts/check-task-store-concurrency.ts, which suggests these invariants are tested rather than asserted.

Two additions stand out. Semble is described as "fast, on-demand semantic code search with automatic setup and no separate indexing workflow", which removes the usual index-build step that semantic search tools impose. Destructive Command Guard "automatically block[s] dangerous commands while trusted work continues without repeated approval prompts". Both are trade-offs, not free wins: automatic command blocking means the guard's notion of dangerous has to match your build, and automatic semantic setup means you do not control when indexing work happens.

Installing Zoo Code as a VSIX in VS Code or Cursor

The README documents two routes for end users. The Marketplace listing is linked at the top of the README, and the local build path produces a VSIX. The build path is the one with concrete steps, so it is the one worth walking through.

Start by cloning the repository and installing dependencies with pnpm. The package.json pins the package manager to [email protected] and Node to 22.23.1, so a mismatched local Node will surface early.

git clone https://github.com/Zoo-Code-Org/Zoo-Code.git
cd Zoo-Code
pnpm install

The install script runs scripts/bootstrap.mjs as a preinstall hook, so expect that to execute before dependencies resolve. Once it finishes, you have two ways to run the extension. For active development, open the repo in VS Code and press F5 or use Run, then Start Debugging. A second VS Code window opens with the extension loaded, and the README states that webview changes appear immediately while core extension changes hot reload automatically.

For a normal install into your editor, use the automated VSIX script:

pnpm install:vsix [-y] [--editor=<command>]

According to the README, this asks which editor command to use (code, cursor, or code-insiders, defaulting to code), uninstalls any existing version, builds the VSIX, installs it, and prompts you to restart VS Code. The -y flag skips confirmations, and --editor=cursor or --editor=code-insiders selects the target. If you prefer to control the steps, build the package first and install it yourself:

pnpm vsix

The README says the resulting .vsix file lands in the bin/ directory. After restarting the editor, the first real use is to open a project, pick a mode from the mode selector, and ask a question about the codebase in Ask Mode before letting Code Mode write anything. That ordering keeps the first run read-only.

Where Zoo Code breaks down or is the wrong tool

The README does not document a headless CLI. There is a "zoo code cli" phrasing in circulation, but the only entry points described are the VS Code extension, the F5 debug host, and the VSIX install scripts. If your workflow is CI-driven or you want an agent in a terminal outside an editor, this project does not present itself as the answer. A related gap: the README does not document rollback. The install:vsix script uninstalls any existing version before installing, which is convenient for upgrades and awkward if the new build misbehaves and you want the previous one back.

Destructive Command Guard is the other sharp edge. Blocking dangerous commands automatically is only safe if the blocklist matches your project. A build that legitimately runs something the guard classifies as destructive will stall until you intervene. The README does not publish the guard's rule set, so you cannot audit it before installing.

There is also a governance consideration. The project is a fork with a stated handover, and its own README says the team will "continue to make model updates, fix bugs, and release features". That is a commitment, not a track record. The last push was on 2026-08-29 and the most recent release in the repository is v3.80.1 on the same date, so the cadence looks current, but the independent history is short. Teams that need a tool with years of standalone releases should weigh that.

Zoo Code versus Cline, Kilo Code, and Claude Code

The closest comparison in the search data is Cline, and the difference is architectural rather than cosmetic. Cline is built around a plan-and-act loop with explicit approval for each step. Zoo Code adds a mode system on top of that pattern, so the same extension can behave as a planner, a coder, or a debugger depending on which mode is selected, and it adds an orchestration layer for parent and child tasks. If your work is a single linear task, the extra machinery is overhead. If your work is a migration with parallel subtasks, the orchestration is the reason to pick it.

Kilo Code sits in the same VS Code agent space and shares the general shape: modes, MCP support, multiple providers. The README does not offer a feature-by-feature comparison, so the honest statement is that both are editor-resident agents and the decision comes down to which provider list and which mode semantics fit your team.

Claude Code is the structural opposite. It is a terminal-first agent, not a VS Code extension, so the comparison is not about features but about where the agent lives. Zoo Code's advantage is the editor integration and the diff review surface; Claude Code's advantage is that it runs anywhere a shell runs. The README's own claim about "completion change review actions" is the part of Zoo Code that has no terminal equivalent.

OpenCode appears in the search data as another comparison point, and the same logic applies: if you want the agent inside VS Code with a webview UI, you are in Zoo Code's territory; if you want a separate process you drive from a shell, you are not.

Licence, upgrade cost, and what maintenance looks like

Zoo Code ships under Apache-2.0. For most teams that means you can use it internally, modify it, and redistribute it, provided you keep the licence and notices intact. Apache-2.0 also includes an explicit patent grant, which is a meaningful difference from permissive licences that are silent on patents. This is not legal advice; if you plan to redistribute a modified build, have counsel read the LICENSE file and the NOTICE requirements.

The practical upgrade cost is the VSIX rebuild. Because install:vsix uninstalls the existing extension first, every upgrade is a full replace rather than a side-by-side install. The repository uses changesets (.changeset/) and a CHANGELOG.md, and the release notes for v3.80.1 list concrete fixes: "restored subtask approvals, Vertex Gemini 3.7 empty tool output, terminal startup failures, background service errors, and theme legibility". That list is a fair proxy for what maintenance looks like: provider-specific breakage, terminal integration, and UI polish, shipped on a roughly weekly release cadence between v3.78.0 on 2026-08-15 and v3.80.1 on 2026-08-29.

Maintenance burden on your side is mostly provider configuration. The README advertises support for Claude, GPT, Gemini, Kimi, GLM, Grok, MiniMax and others, plus providers including Zoo Gateway, Moonshot, Kimi Code, Kenari, Friendli, and OpenCode Go. Model families move faster than extensions, so budget time for the occasional provider handoff when a model is deprecated. The repository's provider-handoff scheduler check script suggests the project treats that as a known failure mode.

Editorial conclusion

Adopt Zoo Code if you already live in VS Code, want modes plus MCP servers, and are comfortable installing a VSIX built from a pnpm monorepo. Do not adopt it if you need a headless CLI, since the README documents no such entry point, or if you want a project with a long independent track record rather than a fork that started in 2026. Before committing, verify three things: that your editor command resolves so pnpm install:vsix can target it, that your chosen model provider is listed among the supported families, and that Destructive Command Guard's defaults match the commands your build actually runs. The last push was on 2026-08-29, so check the CHANGELOG for what landed after the build you install.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes