codex

OpenAI 的 Codex App 官方只面向带 Microsoft Store 的 Windows 10 和 11。Windows Server 系列，比如 Server 2022，默认不装应用商店，也没有配套的运行环境，商店入口压根不存在。 这篇记录一次手工安装的全过程。思路很简单：商店不肯上门，那就自己去店里把货搬回来。 为什么常规路走不通 在普通 Windows 上，商店负责下载、签名校验和部署，用户全程无感。Server 2022 把这一整套都裁掉了，安装入口跟着消失。 直接拿到 .Msix 安装包也不行。系统默认没有把它关联到任何处理器，双击只会弹出「选择打开方式」。商店框架缺席，双击安装这条腿就断了。 但断的只是入口。Server 2022 的内核里，Appx 部署功能还在，PowerShell 的 Add-AppxPackage 命令开箱即用。这给了我们一条后门。 核心思路 分两步： 用第三方解析工具代替商店，从微软的下载源里挖出原始的 .Msix 安装包。 用 PowerShell 内置的部署命令，把这个包装进系统。 不需要第三方运行库，不需要改系统策略，全程两步。 第一步：解析下载地址 打开 Online link generator for Microsoft Store，在搜索框里粘贴 Codex 的官方商店链接： https://apps.microsoft.com/detail/9plm9xgg6vks?referrer=psi&hl=en-US 注意是 9plm9xgg6vks 这个 ID 对应的完整链接。提交后页面会列出这个应用相关的全部安装包。 在列表里找文件名长这样的条目： OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0.Msix 三个要点： 架构：x64 对应绝大多数物理服务器和虚拟机，ARM 机器要选 arm64。 版本号：26.422.3464.0 是写这篇文章时的版本，商店更新之后数字会变，以你解析到的实际列表为准。 后缀：认准 .Msix，别拿成别的文件。 右键点文件名选「另存为」。如果浏览器点了没反应，就复制链接地址，开一个新窗口粘贴下载。 第二步：命令行部署 把下载好的安装包放到固定目录，比如 C:\codex\。然后以管理员身份打开 PowerShell，执行： Add-AppxPackage -Path "C:\codex\OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0.Msix" 命令跑完进度条，开始菜单里出现新图标 进度条走完，部署就结束了。没有任何额外确认弹窗。 第三步：启动 点开开始菜单，在「最近添加」或应用列表里能直接看到 Codex App，点图标正常运行。到这一步，安装就全部完成了。 几个容易踩的地方 版本号会过期。 商店每更新一次，文件名里的版本就换一串，不要照抄本文的完整文件名，解析结果里叫什么就用什么。 看清楚下载域名。 解析出的直链指向微软官方分发源，下载前扫一眼地址栏确认。 这是按用户安装。 Add-AppxPackage 只对当前用户生效，别的账户要用，要么各自执行一遍，要么改走 DISM 预置的路线。 报依赖错误先补依赖。 如果部署时报依赖包缺失，回解析列表里找到对应架构的依赖包，先装依赖再装主体。 小结 这套方法的本质是绕过商店框架，直接利用 Windows 内置的 Appx 部署能力：解析工具负责找到原始包，Add-AppxPackage 负责装进去。对需要在服务器环境里用 Codex 做开发辅助或测试的人来说，两步就能解决，不用为了一个商店去动系统。

一、遇到的问题 今天终于把 Codex 在 Windows 下的中文乱码问题彻底解决了，记录一下整个过程。 先说现象：Codex 在 Windows 下执行命令时，所有中文输出全是乱码——方块字、问号、稀奇古怪的符号，完全无法阅读。比如让它列个带中文文件名的目录，返回的东西根本没法看；让它输出一段中文提示信息，终端里显示的是一坨天书。 一开始以为是 Codex 本身的 bug，折腾了很久才发现问题出在 Windows 的终端编码体系上。 二、乱码根因分析 2.1 核心矛盾 问题不在 Codex，而在 Windows 终端默认的编码机制与 Codex 使用的编码不一致： Codex（基于 Node.js） 默认使用 UTF-8 编码输出。 Windows 默认终端（CMD / PowerShell 5.1） 使用的是 历史代码页（中文系统常见 936 / GBK）。 这个差异导致了一条"烂链路"： Codex（UTF-8）→ Windows Console（GBK / 936）→ VS Code 终端 → 中文乱码 两边编码不一致，UTF-8 的多字节中文字符被按 GBK 单字节/双字节方式解析，结果自然是一团乱码。 2.2 为什么 Linux / macOS 没这个问题？ Linux 和 macOS 全链路默认 UTF-8： locale = UTF-8终端   = UTF-8Shell = UTF-8CLI   = UTF-8 无需任何额外配置，全链路天然一致。而 Windows 的 CLI 层一直背负着历史包袱——GUI 层用 Unicode，终端层用历史代码页，两者割裂至今。 2.3 CMD / PowerShell 5.1 / PowerShell 7 的真实差异 工具定位编码cmd.exeDOS 时代遗产，兼容层强依赖代码页（默认 GBK）PowerShell 5.1系统管理遗产，基于 .NET Framework继承旧控制台编码PowerShell 7（pwsh）现代开发者终端，基于 .NET（跨平台）可控 UTF-8 结论很清晰：需要切换到 PowerShell 7（pwsh），并显式声明 UTF-8 编码。 三、解决方案 Step 1：下载并安装 MSI 版 PowerShell 7 重要：不要用 Microsoft Store 版（Appx），Codex 沙箱环境中 Store 版可能触发权限问题（CreateProcessAsUserW failed: 5）。必须使用 MSI 安装版。 下载链接（x64）： https://github.com/PowerShell/PowerShell/releases/download/v7.6.2/PowerShell-7.6.2-win-x64.msi 双击运行，一路默认安装即可。安装时会自动将 C:\Program Files\PowerShell\7 加入 PATH。 验证安装： pwsh --version 预期输出类似： PowerShell 7.6.2 Step 2：卸载 Store / Appx 版 PowerShell 如果之前安装过 Store 版 PowerShell 7，需要卸载掉，避免路径冲突。 先关闭所有占用 PowerShell 进程的软件（Codex、VS Code、IDEA 等），然后执行： # 确认是否存在 Store 版Get-AppxPackage Microsoft.PowerShell 如果有输出，说明存在 Store 版，执行卸载： Get-AppxPackage Microsoft.PowerShell | Remove-AppxPackage 再次确认已卸载： Get-AppxPackage Microsoft.PowerShell 预期输出： 无任何输出（表示已卸载干净）。 Step 3：调整 PATH 顺序 确保 MSI 版 pwsh 的路径在 PATH 中排在 WindowsApps 前面。打开系统环境变量，在用户 PATH 中确认以下顺序： C:\Program Files\PowerShell\7 ← MSI 版（排前面）C:\Users\<用户名>\AppData\Local\Microsoft\WindowsApps ← WindowsApps（排后面） 这样执行 pwsh 时会优先使用 MSI 版。 验证解析顺序：…