配置 GitHub Copilot Chat 与 Codex 插件
前言
近期，笔者因项目需求要使用到 Linux 环境，但又不想在一台电脑上频繁切换 Linux 与 Windows 系统，于是将部分测试与自动化代码放到了 Windows 的 WSL 中运行。如今，在开发工具中灵活使用各类 AI 工具对代码进行编写与检查，已然成为了项目开发中的不可或缺的一环 —— 即使是在 WSL 环境下。然而，由于一些众所周知的原因，部分国外企业的 AI 产品无法直接在中国大陆使用，在开发工具中使用由这些企业开发的插件时更是如此。因此，从实用的角度出发，本文将讲述如何在目前世界上最流行的代码编辑器 Visual Studio Code 中正确配置来自 GitHub 的 GitHub Copilot Chat 插件与来自 OpenAI 的 Codex 插件，并使其能在 Windows 主机环境和 WSL 环境中都能良好工作。
注意：由于本文主要叙述插件正确配置，因此不会涉及 WSL 的安装与配置、GitHub 账户的注册、OpenAI 账户的注册和 ChatGPT Plus 的订阅开通等内容。如果想获得与本文一致的效果，您至少需要：
- 已正确安装并配置 WSL，并在 WSL 中安装至少一个可运行的 Linux 发行版；
- 一个可登录并能正常使用的 GitHub 账号；
- 一个开通了 ChatGPT Plus 订阅的 OpenAI 账户；
- 最新且完整的 Visual Studio Code。
本文中主机所使用的操作系统为 Windows 10 22H2（非 Windows 11），WSL 中安装的 Linux 发行版为 Ubuntu 22.04.5 LTS，运行在 WSL 2 模式下。
安装扩展
首先，在 Visual Studio Code 中安装如下两个插件：
- GitHub Copilot Chat (GitHub)
- Codex (OpenAI)
在安装好上述两个扩展之后，先不要着急登录，因为这两个插件可能需要科学上网的环境 —— 尤其是 Codex，明确表示封锁中国大陆地区。先重启 Visual Studio Code，使得插件被重新完整加载。
配置代理
在 Windows 主机上的 Visual Studio Code 中配置代理
重启完 Visual Studio Code 后，使用 Ctrl + , 快捷键进入编辑器设置。请确保设置的作用域是“用户”而不是“工作区”，这代表下面进行的设置会在整个 Visual Studio Code 中生效。在设置的搜索框中，输入 “Proxy” 进行筛选搜索：
细心的读者可能已经发现，笔者的 “Http: No Proxy” 设置和 “Http: Proxy” 设置并不是默认的空值。是的，请您将 “Http: No Proxy” 设置为：
127.0.0.1
localhost
::1
同时，将 “Http: Proxy” 设置为：
http://127.0.0.1:{your_local_proxy_port}
注意，{your_local_proxy_port} 应填写您当前使用的本地代理端口号。以 Clash Verge Rev 为例，Clash Verge Rev 默认使用 7897 作为本地代理端口号，因此 {your_local_proxy_port} 应填写 7897。若您使用的是旧版的 Clash Verge、Clash for Windows 或其它代理工具，请填写 7890 或具体的特定端口号。
保持代理网络的正常连接，接下来，就可以登录 GitHub Copilot Chat 和 Codex 插件了。GitHub Copilot Chat 使用 GitHub 登录，Codex 使用 OpenAI 的 ChatGPT 登录。
- GitHub Copilot Chat 登录：
- Codex 登录：
至此，我们已经可以在 Windows 上的工作区中愉快地使用 Copilot 补齐以及 Codex 智能体代理开发。
在 WSL 的 Visual Studio Code 中配置代理
首先，使用 Visual Studio Code 的远程功能，通过 Remote SSH 连接至 WSL：
同样，打开扩展列表，对“本地 - 已安装”列表中的 GitHub Copilot Chat 和 Codex 扩展分别点击“在 WSL: XXX 安装”。安装后，Visual Studio Code 可能要求您重启窗口以加载扩展：
有的读者可能会发现，GitHub Copilot Chat 或 Codex 会要求重新登录。其实这也是合理的 —— WSL 虽然是依附于 Windows 运行的一个子系统，但其正在运行的系统在逻辑上被归为一个独立 Linux 系统，并且在这个系统启动后，我们通过 Visual Studio Code 与 Remote SSH 远程连入了这个 Linux 系统。因此，从逻辑上来看，虽然 Visual Studio Code 仍运行在 Windows 上，但其中的插件以及编辑器的“作用范围”已经是在那一台“逻辑 Linux 主机”上了，自然，我们做的设置也应该针对那台“逻辑 Linux 主机”进行匹配，而不是当前的 Windows 主机。
了解到这一点后，我们就可以针对 WSL 中的系统进行正确的代理设置了。同样，首先使用 Ctrl + , 快捷键打开 Visual Studio Code 的设置。但这次请将选项卡调为“远程 [WSL: XXX]”，而不是“用户”：
同样，将 “Http: No Proxy” 设置为：
127.0.0.1
localhost
::1
但是，请先不要贸然填写 “Http: Proxy” 设置，让我们先确定一个基本的网络配置。
首先打开 “WSL Settings”（可以在开始菜单中搜索），选择导航栏中的“网络”，确保右侧的“网络模式”使用的是 NAT 模式：
那么问题来了，既然 WSL 中的系统用的是 NAT，并且显然网络是从 Windows 主机中转换而来，那么依据计算机网络学的基础知识，NAT 过程中势必会产生“内网 IP 地址”和“默认网关”。不难猜出，这里的“默认网关”应该就是 Windows 主机了，而“内网 IP 地址”就是 WSL 中系统所用的 IP。那么，假设要在该 WSL 的 Linux 系统中使用 Copilot Chat 和 Codex 这样明显需要和外部主机通信的插件应用，其流量自然会要通过这个“默认网关”，但这些插件在 Windows 主机上的时候就已经要使用代理才能运行，如何才能使得 WSL 里的 Linux 系统也“享受”到代理呢？
于是，聪明的你想到了，如果可以将代理地址直接填成这个“默认网关”，同时在 Windows 主机中开启全局代理，就能轻松解决这个问题了。那么，接下来要干的就是在 Windows 中打开全局代理。笔者此处以 Clash Verge Rev 为例，将代理模式设置为“全局”，让计算机中（绝大多数）流量都通过本地转发代理：
然后，在 WSL 的 Linux 系统中运行以下命令来获取“Linux 系统视角下的 Windows 主机 IP 地址”：
ip route show | grep -i default | awk '{ print $3}'
笔者此处获得的 IP 地址是 172.27.144.1。因此，我们就可以在 Visual Studio Code 的 “Http: Proxy” 处这样填写代理地址了：
http://{your_Windows_IP_address}:{your_Windows_local_proxy_port}
其中，{your_Windows_IP_address} 就是刚才获取的 Windows 主机 IP 地址，{your_Windows_local_proxy_port} 是 Windows 主机上的全局代理的本地转发端口（与上一小节的端口号相同）。以笔者为例，在 “Http: Proxy” 处填写：
http://172.27.144.1:7897
最后，往下翻设置卡片，找到 “Http: Use Local Proxy Configuration” 并取消勾选：
至此，我们就完成了所有的代理设置。重复上一小节的登录 GitHub Copilot Chat 和 Codex 的操作，即可完成文中所述的所有插件安装与配置。
使用 GitHub Copilot Chat 或 Codex 进行开发加速
笔者新建了一个简单的 CMake 项目，并使用 Codex 进行智能体代理开发：
看起来不错，在半分钟左右即完成了笔者所提出的要求：
最后编译、运行，也的确是出现了期望图像的窗口和效果。只是这个窗口控件实在是太难用了，和原生的 Windows/GNOME 桌面窗口完全没法比。
总结
本文主要针对 Visual Studio Code 中的 GitHub Copilot Chat 和 Codex 插件进行配置，使得这些插件既能正确运行在 (Windows) 主机上，又能在 WSL 开发环境中正常使用。总而言之，只要理清 Visual Studio Code 在 Windows 主机与 WSL 远程环境中的作用域差异，并分别完成正确的代理与插件配置，GitHub Copilot Chat 与 Codex 便能够在两种开发环境下稳定协同工作，从而显著提升跨平台项目的开发效率。如果各位读者有关于 GitHub Copilot Chat 和 Codex 插件配置的更多分享，欢迎在下方评论区留言，让我们一起进步！