Kilo Code opens Roo migration with --install-extension and AGENTS.md conversion
Kilo Code published a Roo Code migration path ahead of Roo’s May 15 archive, including one-command install, automated file renames, custom-agent conversion, and API key re-auth. Use the guide to map Roo modes, rules, MCP config, and checkpoints into Kilo’s agent and worktree model before the cutoff.

TL;DR
- kilocode's migration thread says Roo Code will archive on May 15, and Kilo is pitching a one-command move path instead of a cold restart.
- Installation is literally
code --install-extension kilocode.Kilo-Code, while kilocode's install note says you can keep Roo disabled as a fallback for about a week before uninstalling it. - The config move is mostly a rename pass: according to kilocode's file mapping,
.roorulesbecomesAGENTS.md,.roo/rulesbecomes.kilo/rules,.roomodesbecomes.kilocodemodes, and.roo/mcp.jsonbecomes.kilocode/mcp.json. - kilocode's custom mode note says Roo custom modes become Kilo custom agents, and the format changes from YAML-only to Markdown with YAML frontmatter.
- The one piece that does not port cleanly is auth, because kilocode's API key note says Roo stores provider keys in VS Code SecretStorage while Kilo keeps them in
~/.config/kilo/auth.json, so every provider needs a fresh sign-in.
The useful bits are all in the migration plumbing. You can open Kilo's migration guide, skim kilocode's feature mapping card for the feature-by-feature swaps, and use kilocode's rename table to see exactly which Roo project files get rewritten on first launch.
Install and fallback
The install path is as short as these migrations get: code --install-extension kilocode.Kilo-Code. According to kilocode's install note, the safer cutover path is to leave Roo installed but disabled for a week, then remove it once the Kilo setup sticks.
The timing matters because kilocode's announcement frames the guide as a response to Roo Code archiving on May 15, not as a generic sidegrade.
File mapping and agent conversion
Most of the project state ports over through renamed files:
.roorules→AGENTS.md.roo/rules→.kilo/rules.roomodes→.kilocodemodes.roo/mcp.json→.kilocode/mcp.json
The bigger conceptual swap is that Roo's old abstractions get normalized into Kilo's agent model. According to kilocode's feature mapping card, Orchestrator mode becomes native subagent delegation, Memory Bank becomes AGENTS.md, tool groups become glob-based permission rules, and in-repo Git checkpoints become detached worktree snapshots.
kilocode's custom mode note adds one format change that will matter for teams with hand-rolled modes: custom modes become custom agents, and the representation shifts from raw YAML to Markdown with YAML frontmatter. Kilo says its launch wizard handles that conversion automatically.
API keys do not transfer
The clean migration story stops at credentials. kilocode's API key warning says Roo stores provider auth in VS Code SecretStorage, while Kilo writes auth state to ~/.config/kilo/auth.json, so API keys do not come across with the rest of the project files.
kilocode's full guide post is the only place in the thread that calls this the "one real friction point," and it links out to the full written guide with the command list, mapping table, and worked custom-mode example.