Roo Code cannot be presented as a currently maintained developer assistant. Its maintainers’ first-party shutdown notice identifies May 15, 2026 as the end of the VS Code extension, cloud service and router, and the upstream repository was archived read-only.
What the evidence actually establishes
Historically Roo Code used modes for everyday code work, architecture planning, asking questions, debugging and custom workflows, with tools that could inspect and edit project files or reach MCP servers. These describe its former operating model. The sunset notice says existing services were supported until the deadline and points users toward Cline and a community fork called Zoo Code. A still-installable old build does not contradict end of maintenance; marketplace availability is not a security-update guarantee.
How a development team should use or migrate it
Begin a migration by identifying every workspace using Roo-specific rules, modes, environment variables and provider credentials. Export those settings to a controlled archive without leaking keys into Git. List every tool server and shell command that old tasks could invoke. Use a temporary development branch to reproduce three bounded tasks with a successor: a documentation-only question, a small code edit, and a test correction. Require a human to compare final diffs and record changes to model endpoint, prompt context and command approval behavior.
A realistic engineering example
A legacy repository may carry `.roorules` instructions, custom mode definitions and an old model API key in local configuration. Migrating only the extension icon leaves risk behind. Search for old package references, rotate or revoke tokens, record old MCP endpoints, and verify the destination editor no longer launches frozen components. If the same team starts using a community fork, compare a proposed patch before and after migration with identical seed code and acceptance tests; do not expect deterministic model output. Store the discontinued version only as a read-only artifact for troubleshooting provenance. Keeping a historical extension installed in a privileged development image solely for convenience is a poor long-term control.
Security, licensing and production limits
In an abandoned editor extension, new upstream model requirements or editor API changes can break the product without a patch. Community forks can restore maintenance but are distinct publishers with their own artifact signatures and governance. Before adopting a fork, verify its source repository, extension publisher ID, releases, dependency audits and whether configuration imports preserve the same safeguards. An unverified router-credit refund or retained user data should not be assumed after shutdown.
Who should choose it and what to compare
For a present-day install, favor maintained projects rather than relying on the frozen upstream archive. Cline provides a related integration path; Zoo Code maintains forked behavior but requires its own evaluation. Keep Roo Code in a historical archive with a dated discontinued marker, not in current rankings as an active subscription.
Decision checklist
- Which old credentials and rules must be migrated?
- Were all remote services disabled on May 15, 2026?
- Does the replacement retain a confirmation step for edits?
- Can the old extension be removed after migration tests?
Primary-source confirmation of the product cutoff
The maintainer’s shutdown notice and archived source repository establish the May 15, 2026 cutoff for Roo Code’s managed products. A community fork is a separate project and should not inherit the old extension publisher’s security, maintenance or billing claims.
Sources & Further Reading
- https://github.com/RooCodeInc/Roo-Code-Docs/blob/main/docs/sunset.md — official product, publisher or project material (checked October 25, 2026).
- https://github.com/RooCodeInc/Roo-Code — official product, publisher or project material (checked October 25, 2026).