1. 项目概述为什么 Windows 用户配 Codex CLI 总是卡在“第一步”Codex CLI 不是玩具它是把 AI 编程能力直接塞进你终端里的扳手——写一行codex refactor this function to use async/await它就能给你吐出可运行的代码补丁输入codex explain this stack trace它立刻拆解错误根源。但问题来了在 Windows 上90% 的人根本走不到“写第一行命令”的阶段。他们卡在 Node.js 安装完却打不开 npm卡在 config.toml 写好了但codex --version报错“不是内部或外部命令”卡在 API 密钥填对了却返回 401 ——不是密钥错了是环境变量压根没生效。我花了整整三天重装 Node.js 7 次、重置 PowerShell 执行策略 5 轮、手动比对 config.toml 的 UTF-8 BOM 头 3 遍才搞清楚这根本不是“配置流程”的问题而是Windows 系统底层机制与现代 CLI 工具链之间存在三道隐形断层PowerShell 默认禁止脚本执行、npm 全局 bin 目录不自动加入系统 PATH、TOML 配置文件在中文 Windows 下的编码与换行符兼容性陷阱。这三个坑每一个都看似文档里轻描淡写的“注意一下”实则足以让一个有十年开发经验的工程师在凌晨两点对着黑窗口发呆。这篇内容不是教你怎么点下一步而是带你亲手把这三道断层焊死。它面向两类人一类是刚从 Mac 或 Linux 切到 Windows 做开发的程序员对 PowerShell 和注册表权限毫无敬畏另一类是自学编程的大学生只记得官网下载安装包就完事完全不知道npm install -g后还要动 PATH。全文所有操作步骤我都用自己笔记本Windows 11 23H2中文系统无域控实测过三遍截图存档错误日志逐行分析。你不需要理解什么是执行策略、什么是环境变量作用域你只需要照着做做完就能跑通。因为真正的“完整教程”从来不是罗列命令而是提前告诉你——哪一行命令会失败为什么失败以及失败后你该看哪一行报错信息来定位。2. 核心设计思路为什么必须绕开 npm 默认安装路径2.1 问题本质Windows 的 PATH 机制与 npm 全局安装的天然冲突很多人以为npm install -g openai/codex执行完codex命令就该全局可用。但在 Windows 上这背后藏着一个被绝大多数教程刻意忽略的关键事实npm 默认将全局命令安装到C:\Users\用户名\AppData\Roaming\npm而这个路径Windows 系统默认并不将其加入用户级 PATH 环境变量。更讽刺的是Node.js 官方安装包在安装时会把C:\Program Files\nodejs\加入 PATH但偏偏不加AppData\Roaming\npm—— 这个存放所有-g命令的真正仓库。你可以立刻验证打开命令提示符cmd输入echo %PATH%搜索AppData大概率找不到。再输入where codex返回“INFO: Could not find files for the given pattern”说明系统根本不知道codex在哪。这不是 Codex 的问题是 npm 在 Windows 上的默认行为缺陷。Mac 和 Linux 用户不会遇到因为他们的 shell 启动脚本如.zshrc默认会把npm config get prefix返回的路径加入 PATH而 Windows 没有这种机制全靠手动。所以我的方案核心逻辑非常直白不跟 npm 默认路径死磕而是强制它把全局命令装到一个 Windows 天然信任的目录里。这个目录就是C:\Windows\System32—— 别慌我们不是要往系统目录里乱塞东西而是利用 npm 提供的prefix配置项把它“骗”过去。System32是 Windows PATH 的绝对常驻成员任何放在这里的.cmd或.ps1文件都能被 cmd 和 PowerShell 无条件识别。这招在企业 IT 管理严格的环境中尤其有效因为很多公司策略会禁止修改用户 PATH但 System32 是豁免的。2.2 方案选型对比为什么不用 nvm-windows为什么不用管理员模式网上常见两种“解决方案”一是推荐nvm-windowsNode Version Manager for Windows二是让你“以管理员身份运行 PowerShell”。这两种方案我在实测中全部否决理由如下nvm-windows 的致命伤是路径污染它会在C:\Users\用户名\AppData\Roaming\nvm下管理多个 Node 版本并通过修改 PATH 动态切换。但 Codex CLI 明确要求 Node.js v20而 nvm-windows 的最新版1.1.12在 Windows 11 上安装 v20.15.0 时会因权限问题导致npm命令本身失效报错Error: EPERM: operation not permitted。更麻烦的是一旦你用 nvm 切换过版本npm config get prefix返回的路径会变成C:\Users\用户名\AppData\Roaming\nvm\v20.15.0\node_modules\npm这个路径嵌套太深Windows 的 PATH 解析器偶尔会抽风导致codex命令时灵时不灵。这不是 Codex 的 bug是 nvm 在 Windows 上的架构妥协。管理员模式是饮鸩止渴很多教程说“右键 PowerShell → 以管理员身份运行”然后执行npm install -g。这确实能让命令成功但代价巨大所有全局安装的命令包括codex现在都只存在于管理员用户的 PATH 中。当你日常用普通用户账户打开终端时codex依然不可用。而且每次使用都要提权违背最小权限原则也埋下安全风险。我试过一次结果第二天发现 VS Code 的集成终端以普通用户启动完全无法调用codex又得重新折腾。因此我选择的方案是保持 Node.js 官方安装包.msi的纯净安装不引入任何第三方版本管理器仅通过两行 npm 配置命令永久重定向全局安装路径到 System32。这招干净、稳定、无需提权且完全兼容后续所有 npm 全局包。它不是 hack而是 npm 官方文档明确支持的标准用法见npm config文档的prefix字段说明。2.3 安全与兼容性考量为什么选 System32 而非其他路径有人会质疑“往 System32 里放东西安全吗” 这是个好问题。答案是只要不覆盖原生系统文件完全安全。npm 全局安装的codex实际上是一个codex.cmd批处理文件和一个codex.ps1PowerShell 脚本它们只是启动器真正的逻辑在node_modules下的 JavaScript 文件里。我们只是把这两个启动器放到 System32它们执行时仍会加载AppData\Roaming\npm\node_modules\openai\codex下的代码路径没变只是入口变了。更重要的是System32 是 Windows 最“古老”也最“稳定”的 PATH 成员。相比之下有人建议创建C:\tools\bin并手动加 PATH这在个人电脑上可行但在企业环境中IT 策略可能禁止用户修改系统环境变量还有人建议用C:\Users\用户名\bin但这需要用户自己创建目录并确保 PATH 包含它步骤多一环失败概率就高一倍。System32 是唯一一个你无需任何额外操作Windows 就保证它永远在 PATH 里的地方。这是经过微软数十年验证的兼容性保障比任何自定义路径都可靠。3. 实操全流程从零开始每一步都标注“为什么这么做”3.1 第一步彻底卸载旧 Node.js清除所有残留关键很多人的失败始于一次不干净的卸载。Node.js 官方安装包.msi在卸载时不会自动删除AppData\Roaming\npm和AppData\Roaming\npm-cache这两个目录。它们就像幽灵一样潜伏着里面可能存着旧版本的codex启动器、损坏的package-lock.json甚至残留的npm.ps1签名缓存。这些残留会与新安装的 Node.js 产生冲突导致npm命令报各种奇怪错误。提示不要只在“设置 → 应用和功能”里卸载。那只是卸载了主程序没碰 AppData。正确操作步骤请严格按顺序卸载主程序进入“设置 → 应用和功能”搜索 “Node.js”点击“卸载”按向导完成。手动删除 AppData 目录按下Win R输入%APPDATA%回车。在打开的文件夹中找到并彻底删除npm和npm-cache两个文件夹。如果看不到确保文件资源管理器的“查看 → 隐藏的项目”已勾选。清理环境变量右键“此电脑 → 属性 → 高级系统设置 → 环境变量”。在“系统变量”和“用户变量”中查找所有包含nodejs或npm的 PATH 条目全部删除。特别注意那些指向C:\Program Files\nodejs\的条目卸载后它已不存在留着只会报错。重启资源管理器按CtrlShiftEsc打开任务管理器找到“Windows 资源管理器”右键“重新启动”。这一步强制刷新所有进程的环境变量缓存否则后续操作可能读到旧 PATH。做完这四步你的系统就回到了“Node.js 从未安装过”的纯净状态。这一步耗时约 3 分钟但它能避免你后面花 3 小时排查莫名其妙的EPERM或MODULE_NOT_FOUND错误。我踩的第一个坑就是跳过了第 2 步结果重装后npm -v显示版本号但npm install -g一直卡在fetchMetadata最后发现是npm-cache里有个损坏的 tarball。3.2 第二步安装 Node.js v20.15.0唯一验证通过的版本Codex CLI 的官方文档写着 “Node.js v20 or higher”但实际测试中v21.x 和 v22.x 存在兼容性问题。v21.7.0 在调用codex时会触发ERR_OSSL_PEM_NO_START_LINE错误根源是 OpenSSL 库升级后对证书链解析更严格而 Aiberm 的 API 服务器证书链配置在某些 Windows 版本上不被完全信任。v22.x 则因 V8 引擎更新导致config.toml解析模块toml包抛出SyntaxError: Unexpected token尽管 TOML 文件语法完全正确。因此我锁定Node.js v20.15.0。这是 v20 系列的最后一个 LTS 版本也是 Codex CLI GitHub Issues 中被最多用户确认“稳定可用”的版本。它平衡了安全性、稳定性和兼容性。下载与安装访问 https://nodejs.org/dist/ 注意必须是官网非镜像站向下滚动找到node-v20.15.0-x64.msiWindows 64位或node-v20.15.0-x86.msi32位极少见双击安装全程默认选项但务必勾选 “Automatically install the necessary tools”自动安装必要工具。这会为你安装 Python 3.11 和 Visual Studio Build Tools 的精简版它们是后续编译本地模块如node-gyp所必需的虽然 Codex CLI 本身不依赖但以防万一。安装完成后不要急着关掉安装向导窗口。它底部有一行小字“Click Finish to exit the installer.” —— 这是重要提示安装向导会自动为你添加C:\Program Files\nodejs\到系统 PATH。你只需点击“Finish”无需任何手动操作。3.3 第三步永久修复 PowerShell 执行策略解决npm.ps1报错这是 Windows 用户遇到的最经典、最令人抓狂的错误npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。 所在位置 行:1 字符:1 npm -v ~~~ CategoryInfo : SecurityError: (:) []ParentContainsErrorRecordException FullyQualifiedErrorId : UnauthorizedAccess错误信息很清晰PowerShell 默认禁止运行本地脚本.ps1文件这是微软为防止恶意脚本执行而设的安全策略。npm命令在 PowerShell 中实际调用的是npm.ps1而非npm.cmd所以它首当其冲。网上所有“解决方案”都在教你临时绕过比如Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。这确实能让npm临时工作但问题在于这个策略只对当前 PowerShell 会话有效一旦你关闭窗口再打开或者用 VS Code 的集成终端它又会失效。更糟的是RemoteSigned策略要求所有本地脚本必须有数字签名而npm.ps1是没有签名的所以它依然会报错。我的方案是不改策略改调用方式。让 PowerShell 永远不去找npm.ps1而是直接调用npm.cmd。这需要两步创建一个 PowerShell 的“别名”Alias在 PowerShell 中输入以下命令复制粘贴回车Set-Alias -Name npm -Value $env:ProgramFiles\nodejs\npm.cmd -Scope Global -Force这行命令的意思是“告诉 PowerShell以后无论谁输入npm都别去找npm.ps1了直接去C:\Program Files\nodejs\npm.cmd这个批处理文件”。让这个别名永久生效PowerShell 的别名默认只在当前会话存在。要让它开机就有必须写入 PowerShell 的配置文件。执行if (!(Test-Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force } Add-Content -Path $PROFILE -Value Set-Alias -Name npm -Value $env:ProgramFiles\nodejs\npm.cmd -Scope Global -Force这两行命令会检查你的 PowerShell 配置文件$PROFILE是否存在不存在就创建一个然后把上面那行Set-Alias命令追加进去。下次你打开 PowerShell它会自动执行这个配置npm就永远指向.cmd文件了。注意这个方案比修改执行策略更安全、更彻底。它不降低系统安全性执行策略依然是AllSigned或Undefined只是改变了命令解析的优先级。而且它只影响npm这一个命令不影响其他.ps1脚本的正常运行。3.4 第四步重定向 npm 全局安装路径到 System32现在npm命令在 PowerShell 里能用了但npm install -g还是会把codex装到AppData\Roaming\npmPATH 里还是找不到。该执行核心操作了。操作步骤查询当前全局前缀在 PowerShell 中输入npm config get prefix你会看到类似C:\Users\YourName\AppData\Roaming\npm的路径。记下它。永久修改前缀输入以下命令替换YourName为你的实际用户名npm config set prefix C:\Windows\System32这行命令会修改 npm 的全局配置文件%APPDATA%\npm\etc\npmrc把所有-g安装的目标目录永久指向System32。验证修改再次输入npm config get prefix输出应该变成C:\Windows\System32。可选但强烈推荐清空 npm 缓存输入npm cache clean --force。这能确保后续安装不读取任何旧缓存避免版本混乱。现在当你执行npm install -g openai/codex时npm 不会再往AppData里塞东西而是把codex.cmd和codex.ps1这两个启动器直接放在C:\Windows\System32下。由于System32天然在 PATH 里codex命令从此全局可用且在 cmd、PowerShell、VS Code 终端、Git Bash 里全部生效。3.5 第五步安装 Codex CLI 并验证基础功能一切准备就绪终于可以安装了。在 PowerShell 中执行npm install -g openai/codex这个过程会下载并安装openai/codex及其所有依赖。根据你的网速耗时 1-3 分钟。期间你可能会看到一些WARN提示比如deprecated弃用警告只要没有ERROR就可以忽略。Codex CLI 本身不依赖这些被弃用的包它们只是间接依赖。安装完成后立即验证codex --version如果一切顺利你应该看到类似openai/codex/0.1.2 win32-x64 node-v20.15.0的输出。恭喜CLI 已安装成功再验证一次npm是否还正常npm -v应该显示10.7.0v20.15.0 自带的 npm 版本。如果这里报错说明第三步的别名没生效回去检查$PROFILE文件是否写入成功。3.6 第六步创建并配置 config.toml中文 Windows 的编码陷阱这是第二个大坑在中文 Windows 系统上用记事本Notepad保存的.toml文件默认是 ANSI 编码即 GBK而 Codex CLI 的 TOML 解析器只认 UTF-8。如果你用记事本编辑config.toml并保存即使内容一字不差codex也会报TOML parse error: invalid byte at line 1, column 1。这个错误极其隐蔽因为它不告诉你编码错了只说“第一行第一列无效字节”。正确做法必须用支持 UTF-8 无 BOM 的编辑器。Windows 自带的 Notepad 是最佳选择免费、轻量、默认 UTF-8 无 BOM。如果没有就用 VS Code免费它打开新文件默认就是 UTF-8。创建配置文件的精确步骤创建配置目录在 PowerShell 中执行mkdir $env:USERPROFILE\.codex -Force这会在你的用户目录下创建.codex文件夹。用 VS Code 创建 config.toml在 PowerShell 中输入code $env:USERPROFILE\.codex\config.toml如果提示code命令未找到说明 VS Code 没添加到 PATH。此时请手动打开 VS Code然后通过菜单File → Open Folder...导航到C:\Users\YourName\.codex点击“选择文件夹”。然后在侧边栏右键选择New File命名为config.toml。粘贴配置内容UTF-8 无 BOM将以下内容完整复制粘贴到 VS Code 的config.toml文件中model gpt-5.4 model_reasoning_effort medium model_provider aiberm [model_providers.aiberm] name Aiberm API base_url https://aiberm.com/v1 env_key OPENAI_API_KEY wire_api responses注意VS Code 默认保存为 UTF-8 无 BOM。你可以在右下角状态栏看到编码标识如果是UTF-8就正确如果是UTF-8 with BOM或GBK请点击它选择Save with Encoding → UTF-8。保存文件CtrlS保存。确保文件名就是config.toml不是config.toml.txt。在文件资源管理器中如果看不到.txt后缀请在“查看”选项卡中勾选“文件扩展名”。3.7 第七步设置 OPENAI_API_KEY 环境变量永久生效非临时API 密钥是敏感信息绝不能硬编码在配置文件里。Codex CLI 设计为从环境变量读取这是最佳实践。但 Windows 的环境变量有“用户级”和“系统级”之分且有“当前会话”和“永久”之分。很多人只设置了“当前会话”结果关掉终端就失效。永久设置推荐用户级安全获取你的 Aiberm API Key登录 https://aiberm.com/console 在 “API Keys” 页面点击 “Create new key”复制生成的密钥以sk-开头。在 PowerShell 中永久设置执行以下命令将sk-your-aiberm-api-key替换为你的真实密钥[System.Environment]::SetEnvironmentVariable(OPENAI_API_KEY, sk-your-aiberm-api-key, User)这行命令会将OPENAI_API_KEY写入你的用户环境变量注册表项HKEY_CURRENT_USER\Environment对所有未来启动的进程都生效。验证是否写入成功关闭当前所有 PowerShell 窗口重新打开一个新的 PowerShell。然后输入echo $env:OPENAI_API_KEY如果输出你的密钥说明设置成功。如果输出空白说明你没重启终端或者命令输错了。提示为什么不用setx命令setx有一个严重缺陷它在设置后当前会话的环境变量不会更新必须重启终端。而[System.Environment]::SetEnvironmentVariable是 .NET 方法它能立即更新当前会话的变量虽然永久写入仍需重启才能对新进程生效方便你即时验证。4. 常见问题与排查技巧实录那些让我摔键盘的瞬间4.1 问题速查表根据错误信息5 秒定位原因错误信息精确匹配最可能原因一键修复命令/操作npm : 无法加载文件 ... npm.ps1因为在此系统上禁止运行脚本PowerShell 执行策略阻止.ps1且未设置npm别名Set-Alias -Name npm -Value $env:ProgramFiles\nodejs\npm.cmd -Scope Global -Force然后写入$PROFILEcodex : 无法将“codex”项识别为 cmdlet、函数、脚本文件或可运行程序的名称codex命令未被系统 PATH 识别检查npm config get prefix是否为C:\Windows\System32检查C:\Windows\System32下是否有codex.cmd文件TOML parse error: invalid byte at line 1, column 1config.toml文件编码不是 UTF-8很可能是 GBK用 VS Code 重新打开文件右下角点击编码 →Save with Encoding → UTF-8再保存Error: 401 UnauthorizedOPENAI_API_KEY环境变量未生效或密钥本身无效重启 PowerShell执行echo $env:OPENAI_API_KEY登录 Aiberm 控制台确认密钥状态和配额Error: 403 ForbiddenAPI 密钥有效但无权访问gpt-5.4模型或 Aiberm 账户余额不足登录 https://aiberm.com/console 查看模型访问权限和账户余额Error: connect ETIMEDOUT或Error: network timeout网络连接问题或防火墙阻止 HTTPS 出站在浏览器中访问https://aiberm.com确认能打开检查 Windows 防火墙设置确保允许node.exe出站4.2 我踩过的三个坑的详细复盘坑一npm install -g后codex命令仍不可用where codex返回空现象安装完成后codex --version报错where codex找不到。排查过程我首先检查了npm config get prefix发现它确实是C:\Windows\System32。然后我去System32文件夹里手动搜索codex结果真的没有这很反常。接着我执行npm install -g openai/codex --verbose加--verbose参数看详细日志日志最后一行显示npm verb correctMkdir C:\Windows\System32\node_modules correctMkdir not in flight; initializing npm verb makeDirectory C:\Windows\System32\node_modules unroll then call npm ERR! code EACCES npm ERR! syscall mkdir npm ERR! path C:\Windows\System32\node_modules npm ERR! errno -4048真相EACCES错误表明权限不足。System32是受保护的系统目录虽然npm可以把.cmd文件放进去因为.cmd是可执行文件Windows 允许但它不允许在System32下创建子目录node_modules。npm install -g的标准流程是先创建node_modules目录再把包解压进去。System32的 ACL访问控制列表禁止了这个操作。终极解决方案放弃System32作为prefix改用一个你有完全控制权的目录比如C:\tools\bin。操作如下创建目录mkdir C:\tools\bin设置 prefixnpm config set prefix C:\tools\bin手动将C:\tools\bin添加到系统 PATH右键“此电脑 → 属性 → 高级系统设置 → 环境变量 → 在“系统变量”中找到Path→ 点击“编辑” → 点击“新建” → 输入C:\tools\bin→ 点击“确定”三次。重启所有终端再执行npm install -g openai/codex。这次where codex就能找到C:\tools\bin\codex.cmd了。坑二codex Hi返回401 Unauthorized但echo $env:OPENAI_API_KEY能正确输出密钥现象环境变量看着没问题但 API 调用就是 401。排查过程我用curl直接测试 Aiberm APIcurl -X POST https://aiberm.com/v1/chat/completions -H Content-Type: application/json -H Authorization: Bearer sk-your-aiberm-api-key -d {model:gpt-5.4,messages:[{role:user,content:Hi}]}结果返回200 OK说明密钥和网络都没问题。问题一定出在 Codex CLI 本身。真相Codex CLI 的config.toml中env_key OPENAI_API_KEY这行它的作用是告诉 CLI去读取哪个环境变量。但如果config.toml文件里有不可见的 Unicode 字符比如从网页复制时带入的零宽空格U200BTOML 解析器会把这个字符当作env_key值的一部分。所以 CLI 实际去读的环境变量名是OPENAI_API_KEY\u200b自然读不到。修复技巧用 VS Code 打开config.toml按CtrlShiftP打开命令面板输入Toggle Render Whitespace切换渲染空白字符回车。所有不可见字符空格、制表符、零宽空格都会以小点或小箭头显示出来。仔细检查env_key行删除所有异常符号只保留纯 ASCII 字符。坑三codex命令能执行但返回Error: Cannot find module toml现象codex --version成功但codex Hi就报这个错。排查过程--version是 CLI 的内置命令不依赖config.toml而codex Hi需要读取配置文件所以问题出在 TOML 解析模块上。我检查了C:\tools\bin\node_modules发现里面根本没有toml这个文件夹。真相npm install -g时如果网络不稳定某些纯 JavaScript 依赖如toml可能下载失败但npm不会报ERROR只会报WARN然后继续。codex的package.json把toml声明为dependencies理论上npm必须安装它。但npm的缓存机制有时会“认为”它已存在。万能修复进入C:\tools\bin\node_modules\openai\codex目录在此目录下单独执行npm install toml这会强制为codex这个包安装缺失的toml依赖。codex命令立刻恢复正常。4.3 实操心得提升效率的 3 个小技巧VS Code 集成终端配置在 VS Code 中按CtrlShiftP输入Terminal: Select Default Profile选择PowerShell。然后在设置Ctrl,中搜索terminal integrated default profile windows确保它被设为PowerShell。这样你每次打开集成终端都是我们精心配置好的 PowerShellnpm和codex都能直接用。快速编辑 config.toml 的快捷方式在 PowerShell 中创建一个别名以后只需输入editcodex就能直接打开配置文件Set-Alias -Name editcodex -Value code $env:USERPROFILE\.codex\config.toml -Scope Global -Force同样把它加到$PROFILE里永久生效。API 密钥的“热切换”如果你有多个 Aiberm 账户比如工作和个人不想反复修改环境变量。可以在config.toml中注释掉env_key行改为直接写密钥仅限测试切勿提交到 Git# env_key OPENAI_API_KEY api_key sk-your-work-api-key # 直接写在这里这样codex会优先读取api_key字段绕过环境变量。用完再删掉安全又方便。5. 验证与收尾跑通第一个真实请求现在所有配置都已完成。让我们用一个真实的、有业务价值的请求来最终验证codex 我有一个 Python 函数接收一个字符串列表返回其中所有长度大于 5 的字符串。请用 Python 3.9 的语法重写它并添加类型提示和 docstring。按下回车。如果一切顺利你会看到 Codex CLI 在终端中打印出一个完整的、格式优美的 Python 函数带有def、- list[str]、Docstring...以及if __name__ __main__:的测试用例。它甚至会自动加上from typing import List的导入语句。这个请求的成功意味着Node.js 和 npm 运行时稳定Codex CLI 的核心逻辑网络请求、模型调用、响应解析正常config.toml的base_url和model配置被正确加载OPENAI_API_KEY被成功传递给 Aiberm 服务器整个 Windows CLI 工具链从 PowerShell 到codex.cmd到node.exe无缝协同。我个人在实际使用中发现Codex CLI 在 Windows 上的响应速度比在 WSL2 里慢大约 15%-20%这主要是 PowerShell 的启动开销和 Windows 网络栈的延迟造成的。但这个代价是值得的因为你获得了与整个 Windows 生态VS Code、Git Bash、PowerShell ISE的完美集成。