Migrating the GitHub Copilot runtime to Rust, using Copilot
GitHub rewrote the Copilot agent runtime from TypeScript into more than 800,000 lines of production Rust, mostly written by agents across 128 incremental pull requests.
Marked important, but published more than 30 days ago, so it moved down to this band.
On this page12 sections
The editors' notes below — why it matters, the context, the learning path — are written in Chinese.
Record
The signal
#The GitHub Copilot CLI , GitHub Copilot app , and GitHub Copilot SDK are all backed by the Copilot agent runtime, an agentic harness that can be embedded into applications and services. It was originally written in TypeScript on Node.js and the V8 JavaScript engine for what is now the GitHub Copilot cloud agent (CCA), and the runtime stayed on that stack as the runtime and its capabilities grew rapidly. That has now changed. Using the GitHub Copilot app and the Copilot CLI, we completely rewrote the runtime into more than 800,000 lines of production Rust. AI agents wrote most of the code, spanning 128 pull requests that landed in main and shipped incrementally rather than waiting for a single cutover at the end. The few inevitable regressions were discovered and fixed quickly along the way, while the performance of the runtime improved by orders of magnitude. A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months, all while the rest of the team continued to greatly expand the runtime’s capabilities and reach. Why we needed to port The Copilot agent runtime isn’t just the engine behind the Copilot CLI. It backs a growing set of Microsoft, GitHub, and ecosystem solutions, for each of which AI support is, architecturally, a shell around the same runtime plus whatever customizations that solution needs. This includes not only the GitHub Copilot CLI and the GitHub Copilot app, but also the latest releases of VS Code, Visual Studio, CCA, Copilot Code Review (…
Why now
Why it matters
#一次过去负担不起的重写，被一名开发者带着智能体在几个月内做完，而且没有停下正常开发。更可迁移的是它失败时的样子：几乎所有回归都来自端到端测试不够，于是结论是把判卷标准保护起来——实现者不能同时改测试、改快照、放宽基线。这和本轮另外两条信号是同一个问题的工程答案：被检查的一方不能同时掌握检查。
Background
Technical context
#旧架构里 SDK 叠在命令行之上，每个客户端都要拉起一个带 Node 与 V8 的子进程并通过 JSON-RPC 跨进程调用，每个客户端至少约 100 MB 工作集。迁移采用由叶到根的顺序，每个 PR 用薄垫片把旧实现替换为调用 Rust 并原子删除旧代码，所有既有端到端测试在每一步都针对新代码运行。会话记录中阅读与搜索类工具调用约为编辑类的 10 倍。
Audience
Who should care
#Next
Learning path
#- 先记住「保护判卷标准」那一条：实现者不能同时改测试、改快照、放宽基线
- 读《完成判定与验收信号》：端到端测试在这里就是唯一可信的完成判定
- 对照你自己的仓库：谁能在同一个 PR 里既改实现又改测试？
- 与 Rootly 废掉小 PR 规则一条并读：两者都在回答智能体产出变大之后审查该看什么
Network
Where it sits in the network
#How this signal connects to neighbouring technologies, skills and background knowledge. Follow any link to keep exploring.
Further thought
Follow-up questions
#- 在你的代码库里，改实现的一方能不能在同一个提交里改测试或快照？
- 如果让智能体做一次大迁移，你现在的端到端测试够不够当判卷标准？
- Rust 版本上线后的回归率与 TypeScript 时期相比如何，GitHub 会不会公布？
Publication record
Featured in
#The briefings that carried this signal, newest first; the last row is the weekly review of its week. The tag is the section it ran in.
技术简报 - 2026-09-19
Immediate attentionWeekly review · Sep 14 – Sep 20
Worth tracking
Sources