如果你发现GitHub Copilot在后台悄无声息地占满了一个CPU核心——编辑器卡住不动、风扇呼呼转、笔记本烫得能煎蛋——那可不是什么“偶尔卡顿”，而是Copilot的后台服务陷入了死循环。这种情况并不罕见，尤其在远程开发或WSL环境下，处理起来其实有清晰的套路。

确认Copilot相关进程是否真正在吃CPU

首先得锁定嫌疑进程。打开终端，跑一条命令：ps aux | grep -i 'copilot|github'。重点搜罗那些关键词中包含 node 或 electron 的进程，尤其是命令行里带了 copilot 字样的。盯着%CPU列，如果某个进程长期在85%以上不下来，基本就是它了。

典型的异常进程长这样：.../node /home/user/.vscode-server/extensions/github.copilot-*/dist/agent.js。一旦看到这种模式，CPU占用异常高，那目标就锁定了。

检查Copilot扩展是否触发了safe_sleep.sh无限循环

这一步严格来说，只适用于那些自托管过Actions Runner，或者本地调试过Runner的用户。为什么提这个？因为Copilot扩展底层复用了Runner的一部分shell工具链，如果环境没做好隔离，问题就会传染。

在远程服务器或WSL环境下，执行 ps aux | grep 'safe_sleep.sh'。如果输出中间出现了 /bin/bash .../safe_sleep.sh 10，而且这个进程CPU占用接近99%，那就说明Copilot的后台心跳机制调用了有缺陷的老版本sleep脚本。

此问题主要出现在2024年6月之前发布的Runner v2.299.1及更早版本。Copilot扩展如果没有强制隔离运行环境，就会继承这个bug，导致心跳循环变成死循环。

终止异常进程并重置Copilot服务状态

动手清理分四步，每一步都不能省。

第一步：彻底清除所有Copilot相关的node进程。用这条命令：pkill -f 'copilot.*agent|github.*copilot'。

第二步：删除扩展缓存。这一步很多人会忽略，但恰恰是关键——rm -rf ~/.vscode-server/extensions/github.copilot-*。缓存里的旧代码是死循环的根源，不清掉就白忙活。

第三步：干掉可能残留的认证状态文件：rm -f ~/.config/github-copilot/hosts.json。这相当于强制Copilot重新走一遍登录流程。

第四步：重启VS Code远程连接。等扩展自动重装完成后，重新登录账户。

一个必须强调的坑：千万别图省事，只在VS Code界面里禁用再启用扩展。那样做，缓存和host token纹丝不动，死循环基本上会原样复现。只有命令行级别的清理才靠得住。