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.

If you want a more portable setup, here's the practical path from GitHub Copilot → Kilo Code.

Kilo covers the same surfaces most teams use: VS Code, CLI, MCP, cloud agents, code reviews, project instructions, custom agents, and model routing. The difference is control. Copilot is deeply integrated into GitHub's own governance, billing, and cloud workflows. Kilo separates the tool layer from the model layer through Gateway, BYOK, and local-model options. That changes how you migrate and what you need to rewrite.

The short version

# 1. Install Kilo
code --install-extension kilocode.Kilo-Code --pre-release
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, some enterprise policy surfaces, Copilot content exclusion, PR summaries, and any automation built directly on Copilot cloud-agent lifecycle APIs.

This is bigger than an extension swap

Copilot now spans IDE chat and completions, agent mode, CLI, cloud agents, MCP, code review, plan management, usage metrics, and seat management. Installing a new plugin doesn't cover that.

What changes when you move

Copilot is a tightly integrated GitHub product. Kilo is a coding platform 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:

Your instructions become more portable. Copilot supports repository instructions, personal instructions, and path-scoped instruction files. Kilo's cleanest default is AGENTS.md plus Kilo-native config and custom agents. That's simpler to reason about, but you may need to redesign some path-specific logic instead of renaming files.

Your model and provider choices aren't tied to the host tool. Copilot offers model choice, but it stays inside GitHub's plan and policy layer. Kilo supports Gateway, BYOK, local models, and even an experimental bridge via the VS Code Language Model API.

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.

Some governance features need redesign, not translation. Copilot content exclusion, some policy controls, and metrics/seat-management surfaces do not have a neat one-file Kilo equivalent. Be explicit about that in your rollout.

Copilot to Kilo feature mapping

File and config mapping

Kilo product coverage for GitHub Copilot surfaces

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. Back up your Copilot repo artifacts

Look for these first:

.github/copilot-instructions.md
.github/instructions/**/*.instructions.md
.github/agents/**/*.agent.md
settings.json entries containing github.copilot
keybindings.json entries tied to Copilot commands
documented MCP server configs

Those are the files and settings most likely to encode real behaviour you will miss later.

3. Install Kilo in VS Code and Kilo CLI

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

kilo --version
kilo config check

The pre-release extension is the recommended channel. The CLI is installed separately.

4. Choose your authentication path

There are really 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.

That bridge is useful because it lets you move the workflow layer first while changing the inference layer later. But the feature is experimental, coverage may be incomplete, and cost control is limited. Treat it as a transition tactic, not your final architecture.

Auth commands:

kilo auth list
kilo auth login
kilo auth logout

5. 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 is the best place to preserve the durable parts of your team's conventions: coding standards, testing expectations, review rules, repo-specific caveats, and definitions of done.

6. Redesign path-specific instructions instead of renaming them

Copilot's applyTo-based .instructions.md files are real functionality. There's no direct file-format equivalent in Kilo.

That means the right guidance is:

• 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.

Say this plainly in user-facing instructions. Readers trust guides that admit where the mapping isn't one-to-one.

7. 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.

8. 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.

9. Recreate MCP servers

If you used MCP in Copilot, rebuild that in Kilo rather than assuming it will just appear.

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.

10. Disable Copilot inline suggestions if Kilo will own autocomplete

Copilot inline suggestions should be disabled if you want Kilo autocomplete to behave cleanly. Otherwise, users often conclude that the new tool is flaky when the real issue is duelling completion layers.

11. 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.

12. Move PR review and cloud workflows

For code review, the migration is fairly clean:

• hosted PR review → Kilo Code Reviews
• local review before push → /local-review.

For cloud agents, the conceptual match exists, but do not overstate API parity. Copilot cloud agent is GitHub-native and tightly issue/PR-shaped. Kilo Cloud Agent is built around repo integrations, secrets, startup commands, and chat-driven workspaces. That covers many teams, but it's not a drop-in replacement for a /agents lifecycle API.

Suggested validation checklist

Use this 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 governance notes

Copilot Business and Enterprise include strong governance surfaces: policies, content exclusion, metrics, seat management, and hosted cloud automation. That's part of Copilot's value. Kilo is not a one-click mirror of every one of those controls.

What Kilo offers instead is a different shape of control:

• flexible provider choice,
• Gateway and BYOK separation,
• local/self-hosted model support,
• plain-text project config,
• shared CLI/IDE core,
• explicit permission controls.

Neither approach is automatically better. The migration is about portability and lower concentration risk.

Team rollout plan

A sensible team rollout looks like this:

Rollback

• Keep Copilot active during the pilot.
• Do not cancel plans or revoke seats until the test matrix 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.

What does not have clean parity yet

• no documented one-click equivalent for Copilot content exclusion;
• no documented direct equivalent for Copilot hooks;
• no documented direct replacement for every Copilot Spaces, memory, or PR summary workflow;
• no documented public Kilo cloud-agent lifecycle API equivalent to Copilot's agent API surface.

Final note

Copilot is a broad, deeply integrated stack. Kilo can replace most day-to-day developer workflows, and can reduce lock-in if you actually use its portability: AGENTS.md, Kilo config, Gateway, BYOK, or local models. Some enterprise and admin surfaces need redesign, not translation.