Last updated: August 2026 · Shutdown date: May 15, 2026
Roo Code shut down on May 15, 2026. The VS Code extension, Roo Code Cloud, and Roo Code Router were all archived. The team pivoted to Roomote, a cloud-based agent that operates outside the IDE entirely.
If you are a Roo Code user looking for what to do with your .roorules and .roo/rules/ configuration, this guide covers where that config goes, which tools can use it, and your migration options.
On April 21, 2026, Roo Code CEO Matt Rubens announced the shutdown. The project had reached 3 million installs — a significant milestone — but the team decided to go all-in on a different model of AI-assisted development: cloud agents that take tasks end-to-end without requiring the developer to stay in the loop inside an editor.
Roo Code's own official recommendation for extension users:
"If you want a model-agnostic open-source extension, we recommend Cline. They've incorporated much of what we built and are excited to welcome Roo Code users."
Cline's response was public acknowledgment and welcome: the Cline team noted that Roo Code "contributed to our community more than any other fork."
Kilo Code — a Roo fork — published an official migration guide the same week and went GA on April 2.
Timeline:
The archived extension continues to function — the binary does not self-destruct. But no bug fixes, no model compatibility updates, and no new features are coming. In a space where model APIs change monthly, a frozen extension has a short useful life.
Roo Code had a layered rules system with four file locations, loaded in order from highest to lowest priority:
Global rules — ~/.roo/rules/ directory
Applied across all your projects on the machine. Files inside are read recursively and appended alphabetically to the system prompt.
Workspace rules — .roo/rules/ directory in your project root (preferred) or .roorules file (fallback)
Project-specific rules committed to the repository. The directory method was preferred over the single-file method. If .roo/rules/ existed but was empty, Roo Code fell back to .roorules.
Mode-specific rules — .roo/rules-{modeSlug}/ directory or .roorules-{modeSlug} file
Rules that applied only when a specific mode was active. For example, .roo/rules-code/ applied only in Code mode, .roo/rules-architect/ only in Architect mode.
Custom mode files — .roomodes (JSON or YAML)
Defined custom modes with their own role definitions, tool access, and rule file paths.
All levels were merged at runtime. Mode-specific rules loaded before general rules within each scope.
Update, August 2026: This section originally listed Continue.dev as a third migration option. Continue.dev was itself acquired by Cursor and discontinued in June 2026 — see what happened. It has been removed as a recommendation. Cline and Kilo Code remain the two actively-maintained paths.
Cline is the upstream project that Roo Code originally forked from. It is Apache 2.0-licensed, model-agnostic, and actively maintained. Roo Code users migrating to Cline have the highest philosophical continuity — many of the patterns Roo introduced (diff-based edits, MCP support, plan/act mode) have been incorporated into Cline.
Rules migration: .roorules → .clinerules
The mapping is direct. Rename .roorules to .clinerules. The content format is the same markdown — Cline reads it into the system prompt exactly as Roo Code did.
For directory-based rules (.roo/rules/), consolidate the files into a single .clinerules file, or split them into Cline's .cline/rules/ directory with per-file YAML frontmatter if you want the same kind of scoping Roo's mode-specific rules provided. The substance of the rules transfers without modification — build commands, coding standards, forbidden patterns, definition of done.
For the configuration guide, see Cline Rules.
What you lose: Custom modes with distinct role definitions. Cline has Plan/Act mode but not the full Architect/Code/Debug/Orchestrator mode split that Roo Code had. If your workflow depended heavily on mode-specific rules with different tool access, you will need to flatten them into a single rules file (or several glob-scoped files) or replicate the behavior through system prompt instructions.
What you gain: Active development, model compatibility updates, Checkpoints for session-level rollback, an MCP marketplace, and the largest open-source VS Code AI extension community.
Kilo Code started as a Roo Code fork and shares real git history with it. The Kilo team rebuilt the extension on OpenCode server and went GA on April 2, 2026. They published an official Roo-to-Kilo migration guide the same week Roo announced its shutdown.
The new Kilo architecture changed four things that Roo Code users will feel:
read/edit/browser/command/mcp groups no longer exist as such. Kilo uses a different permissions model.kilo.jsonc replaces custom mode config. Project configuration now lives in kilo.jsonc, shared across CLI, VS Code, and Cloud Agents.The Kilo migration is closer to a one-click affair than the Cline migration if your workflow was standard. Your .roorules content carries over; the structural configuration (modes, tool groups) requires remapping.
Best for: Roo Code users who want to stay as close as possible to the original Roo Code feature set, especially Orchestrator mode and the multi-agent architecture.
| Roo Code | Cline equivalent | Kilo Code equivalent |
|---|---|---|
.roorules |
.clinerules |
rules section in kilo.jsonc |
.roo/rules/ directory |
.clinerules (merged) or .cline/rules/ |
kilo.jsonc rules |
.roo/rules-code/ |
glob-scoped .cline/rules/ file |
mode config in kilo.jsonc |
.roomodes |
not directly equivalent | kilo.jsonc agents |
~/.roo/rules/ global |
global Custom Instructions | global Kilo config |
The content inside your rule files — build commands, coding standards, architecture notes, forbidden patterns — transfers to either of these tools without modification. The structure changes; the substance does not.
Roomote is the Roo Code team's next product, not a drop-in replacement for the extension. It is a cloud agent that takes a prompt and executes tasks end-to-end — integrating with Slack, GitHub, and Linear — without requiring you to stay in an IDE.
If you used Roo Code primarily as an in-editor assistant and want to continue that workflow, Roomote is not the answer. It is a different paradigm: async task delegation rather than synchronous pair programming, and pricing has since surfaced at a level ($899/month per parallel instance) oriented toward enterprise teams rather than individual developers.
If you are interested in exactly that shift — delegating tasks to an agent while you do something else — see the GitHub Copilot Coding Agent guide for comparison with a more established cloud agent approach.
.roorules, .roo/rules/, .roomodes, and any global ~/.roo/rules/ files to a safe location.roorules to .clinerules for Cline, or follow the Kilo migration guide for Kilo Code.clinerules / .cline/rules/ configuration reference