GitHub Copilot to Kilo Code migration guide

GitHub Copilot grew from "autocomplete in the editor" into a full stack: IDE chat, agent mode, CLI, MCP, PR review, and cloud agents. That also means a lot of your AI coding workflow ends up tied to one platform's defaults for policy, billing, telemetry, model routing, and hosted automation.

Kilo covers the same surfaces — VS Code, CLI, MCP, cloud agents, code reviews, project instructions, custom agents, and model routing — and gives you more control over how they're configured. Kilo separates the tool layer from the model layer through 500+ providers, BYOK, and local-model support, so you're not locked into one vendor's plan or policy layer.

This guide walks you through the migration step by step.

The short version

# 1. Install Kilo
code --install-extension kilocode.Kilo-Code
npm install -g @kilocode/cli

# 2. Authenticate
kilo auth login
kilo config check

# 3. Move project instructions
[ -f .github/copilot-instructions.md ] && cp .github/copilot-instructions.md AGENTS.md
mkdir -p .kilo/agent .kilo/rules .kilo/command

# 4. Disable Copilot inline suggestions if Kilo will own autocomplete

# 5. Recreate MCP, provider settings, and custom agents in Kilo

# 6. Test IDE chat, autocomplete, CLI, code review, and one cloud-agent task

What maps cleanly: chat, autocomplete, agentic editing, MCP, CLI, code reviews, cloud agents, custom agents, model selection.

What does not map one-to-one: path-scoped .instructions.md files with applyTo, Copilot content exclusion, PR summaries, and automation built directly on Copilot's cloud-agent lifecycle APIs.

What you gain

Kilo is built around a shared CLI engine that powers the editor, terminal, and cloud surfaces. It supports many providers and local models, and makes AGENTS.md and plain-text config central to the workflow.

In practice, that means:

Pick any model from 500+ providers, or bring your own key. Copilot offers model choice within GitHub's plan and policy layer. Kilo lets you configure providers independently — use Kilo Gateway, BYOK, local models, or even an experimental VS Code LM API bridge during migration.

Automated code reviews on every PR. Kilo Code Reviews run automatically when a PR is opened or updated. You pick the model, review style, and focus areas. /local-review catches issues before you push. Both work with GitHub out of the box.

Cloud agents for the tasks you don't want to run locally. Kilo Cloud Agent runs agentic tasks in the cloud with repo integrations, secrets, startup commands, and chat-driven workspaces.

Your instructions become portable. Copilot supports repository instructions, personal instructions, and path-scoped instruction files. Kilo's default is AGENTS.md plus Kilo-native config and custom agents. That's simpler to reason about, and it lives in your repo as plain text — portable across tools, readable by your whole team.

Your CLI and IDE share one config. Kilo's CLI and VS Code extension use the same engine and config, so the same workflow moves between terminal and editor.

Team management in Kilo Cloud. Usage tracking, seat management, and organization-level controls for model and provider availability — configured in one place.

Copilot to Kilo feature mapping

File and config mapping

Migration, step by step

Budget about 30 to 90 minutes for an individual developer, and longer for teams with PR automation, custom agents, or enterprise policy requirements.

1. Audit where Copilot is used

Before changing anything, figure out whether your team uses:

• IDE chat and completions
• agent mode
• Copilot CLI
• MCP
• code review
• cloud agent
• enterprise policies
• metrics or seat management.

Otherwise you end up covering only the editor when the real dependency is in PR review or CLI automation.

2. Install Kilo in VS Code and Kilo CLI

code --install-extension kilocode.Kilo-Code
npm install -g @kilocode/cli

kilo --version
kilo config check

The CLI is installed separately.

3. Choose your model provider path

There are two ways to migrate:

Clean break Use Kilo Gateway, BYOK, or local models from day one.

Bridge migration Keep Copilot installed in VS Code temporarily and have Kilo use the experimental VS Code LM API provider.

The bridge lets you move the workflow layer first while changing the inference layer later. The feature is experimental and coverage may be incomplete, so treat it as a transition tactic.

Auth commands:

kilo auth list
kilo auth login
kilo auth logout

4. Move repository instructions into AGENTS.md

This is the safest, lowest-risk migration move:

[ -f .github/copilot-instructions.md ] && cp .github/copilot-instructions.md AGENTS.md
mkdir -p .kilo/agent .kilo/rules .kilo/command

AGENTS.md is Kilo's cleanest project instruction file and works as a cross-tool standard. It's the best place to preserve your team's conventions: coding standards, testing expectations, review rules, repo-specific caveats, and definitions of done.

5. Redesign path-specific instructions

Copilot's applyTo-based .instructions.md files are real functionality. There's no direct file-format equivalent in Kilo, so rather than renaming files:

• move universal rules into AGENTS.md
• move task-specific reusable prompts into .kilo/command/*.md
• move role-specific behaviour into .kilo/agent/*.md
• use .kilo/rules/*.md for additional structured instruction files referenced by config.

6. Convert custom Copilot agents into Kilo agents

A minimal Kilo custom agent looks like this:

---
description: Read-only code reviewer
mode: primary
permission:
  edit: deny
  bash:
    "git diff*": "allow"
    "git log*": "allow"
    "*": "deny"
---

You are a code reviewer. Review diffs for correctness, maintainability,
security, and test coverage. Do not edit files directly.

This gives you the same practical effect as a read-only Copilot review persona, but in Kilo's agent format.

7. Write a starter kilo.jsonc

Start conservative. You can loosen permissions later.

{
  "$schema": "https://app.kilo.ai/config.json",
  "model": "kilo-auto/balanced",
  "permission": {
    "*": "ask",
    "bash": {
      "*": "ask",
      "git status*": "allow",
      "git diff*": "allow",
      "npm test*": "allow",
      "git push*": "deny",
      "rm *": "deny"
    },
    "edit": {
      "*": "ask",
      ".env*": "deny"
    }
  },
  "instructions": ["AGENTS.md", ".kilo/rules/*.md"]
}

Validate it:

kilo config check

Kilo's permission system is flexible, but stay deliberate with it. Broad auto-approval is a governance decision, not a convenience tweak.

8. Recreate MCP servers

If you used MCP in Copilot, you'll need to port those configs into Kilo — they won't migrate automatically.

Kilo supports MCP in both the extension and CLI, including OAuth-capable servers, with explicit tool permission management.

Validation test:

• one local MCP server or remote MCP server connects,
• the expected tools are visible,
• permissions behave as expected,
• one real task succeeds using MCP.

9. Disable Copilot inline suggestions

Disable Copilot inline suggestions if Kilo will own autocomplete. Dual completion layers cause conflicts that make both tools look flaky.

10. Migrate CLI workflows

Install and test the Kilo CLI before porting scripts.

kilo
kilo run "Implement input validation for the signup form" --auto
kilo session list
kilo export <session-id> --sanitize

These are the core replacements for interactive Copilot CLI use, scripted tasks, and session handling.

If your team uses copilot -p or embedded Copilot CLI calls in scripts, replace those with kilo run or direct Kilo Gateway API usage depending on whether you want an agentic workflow or a raw model call.

11. Set up code reviews and cloud workflows

For code review:

• hosted PR review → Kilo Code Reviews (GitHub setup). Runs automatically when a PR is opened or updated. You pick the model, review style (strict, balanced, or lenient), and focus areas (security, performance, bugs, style, tests, documentation). Findings post as inline comments on the PR.
• local review before push → /local-review. Reviews your uncommitted changes inside VS Code or JetBrains before they reach the repo. Catches bugs, security issues, and style problems while you can still fix them in one commit.

For cloud agents, Kilo Cloud Agent runs agentic tasks in the cloud with repo integrations, secrets, startup commands, and chat-driven workspaces. Copilot's cloud agent is more tightly coupled to GitHub issues and PRs. If your workflows depend on Copilot's /agents lifecycle API specifically, expect a redesign rather than a port.

Validation checklist

Run these before removing Copilot from the daily workflow:

• [ ] one autocomplete task in a common file
• [ ] one IDE chat task using repo instructions
• [ ] one agentic multi-file edit
• [ ] one MCP-assisted task
• [ ] one CLI session
• [ ] one kilo run task
• [ ] one custom-agent invocation
• [ ] one /local-review
• [ ] one hosted PR review
• [ ] one Cloud Agent task in a non-critical repo
• [ ] one secrets-handling test
• [ ] one permission-denied test for a blocked action

Security and team controls

Copilot Business and Enterprise include governance surfaces like policies, content exclusion, metrics, and seat management. Kilo approaches these differently:

• 500+ models across many providers, with BYOK support
• organization-level controls for model and provider availability
• enterprise settings management
• usage and seat management in Kilo Cloud
• local and self-hosted model support
• plain-text project config
• shared CLI/IDE core
• explicit permission controls

Kilo provides more flexibility and portability, whereas Copilot currently offers more governance controls. The tradeoff depends on what your team values most.

Team rollout plan

Rollback

• Keep Copilot active during the pilot.
• Don't cancel plans or revoke seats until the validation checklist passes.
• Keep .github/copilot-instructions.md, .github/instructions/**, and .github/agents/** until the Kilo equivalents are validated.
• Export Kilo sessions during the pilot using kilo export.
• Only cut over default workflows after at least one short burn-in period.

Final note

Copilot is a broad, deeply integrated stack. Kilo can replace most day-to-day developer workflows and gives you more control over how they run — which models you use, where your instructions live, and how your team manages access.

Once you've migrated, here's what you get: one config that works across your editor and CLI, 500+ models you can swap without re-tooling, code reviews that run automatically on every PR, cloud agents for the tasks you don't want to run locally, and project instructions that live in your repo as plain text — portable across tools, readable by your whole team.

The migration takes an afternoon. The portability lasts as long as you use it.

Next steps: Install Kilo Code to get started, or compare pricing plans to find the right tier for your team.