概览
在 Windows 版 Codex 中执行命令时，我发现实际使用的不是系统自带的 Windows PowerShell 5.1，也不是另外安装的 PowerShell 7，而是一份位于 Codex 缓存目录中的 pwsh.exe，版本为 7.6.4。
排查后的结论是：这份 PowerShell 属于 Codex 的 codex-primary-runtime，由 Codex 桌面应用从 OpenAI 的静态资源域名独立下载和更新。它与 Git、Node.js、Python、Poppler 等依赖一起组成受控工作区运行时，可供 Windows 原生执行和沙箱环境使用。
OpenAI 官方明确说明了三件事：Windows 版 Codex 原生使用 PowerShell 和 Windows sandbox；配置中存在可管控的 bundled workspace-dependency runtime；更新日志还记录过为 Windows sandbox 授予 primary runtime 访问权限。不过，官方并未单独发布一篇文章解释为什么当前包内恰好是 PowerShell 7.6.4。关于版本固定和独立分发的目的，属于根据本机证据作出的工程推断。
证据范围与复核原则
本文记录的是 2026 年 8 月 16 日对一台 Windows 主机的取证快照：26.813.12317、PowerShell 7.6.4、缓存路径、归档哈希和目录数量都只描述当时检查到的运行时。Codex 可独立更新 primary runtime，因此不要把这些具体值当作所有版本或所有机器上的固定契约；在另一台机器或一次客户端更新后，应重新检查进程路径、应用日志、runtime.json 和数字签名。
问题是如何暴露的
最初的异常很简单：Codex 环境报告的 PowerShell 是 pwsh.exe 7.6.4，但机器上同时存在 Windows PowerShell 5.1 和另一份 PowerShell 7。先用下面的命令区分可执行文件来源：
Get-Command powershell.exe, pwsh.exe -All |
Select-Object Name, Source, Version
$PSVersionTable |
Format-List PSVersion, PSEdition, OS, Platform
在本次检查的主机上，最终确认了三套相互独立的 PowerShell：
| 实例 | 版本 | 典型位置 | 用途 |
|---|---|---|---|
| Windows PowerShell | 5.1 | %WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe | Windows 系统兼容层 |
| 用户安装的 PowerShell | 7.6.5 | Microsoft Store / WindowsApps | 日常终端使用 |
| Codex 内置 PowerShell | 7.6.4 | %USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime\...\pwsh.exe | 本次检查中供 Codex 工作区使用的运行时 |
这种共存本身是正常设计。Microsoft 文档说明，PowerShell 7 不会替换 Windows PowerShell 5.1，而是并行安装。Codex 的副本又处于独立缓存目录，因此也不会被用户安装的 PowerShell 7 覆盖。
追踪下载来源
下一步不是猜测 PATH，而是搜索 Codex 桌面应用日志中的运行时下载记录。日志位于类似下面的目录：
%LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs\
日志显示，Codex 在启动时先请求：
https://persistent.oaistatic.com/codex-primary-runtime/latest/win32-x64/LATEST.json
然后下载目标归档：
https://persistent.oaistatic.com/codex-primary-runtime/26.813.12317/
codex-primary-runtime-win32-x64-26.813.12317.tar.gz
记录中的触发原因为 startup_missing，结果为 installed。这说明 primary runtime 不是 Windows 自带组件，也不是从本机 PowerShell 安装继承而来，而是 Codex 自己管理的版本化依赖。
检查归档和校验值
下载文件虽然被浏览器保存成了 .tar.tar，但文件头是 Gzip 标记，实际内容仍是 .tar.gz。本次检查的归档大小和 SHA-256 为：
Size: 502,222,704 bytes
SHA256: 9DD748361D235AD97772C388454F242DC2100801C1B834E0F72B7D434073E229
可以用 PowerShell 复核：
Get-Item .\codex-primary-runtime-win32-x64-26.813.12317.tar.tar |
Select-Object Name, Length
Get-FileHash .\codex-primary-runtime-win32-x64-26.813.12317.tar.tar `
-Algorithm SHA256
Get-Content .\codex-primary-runtime-win32-x64-26.813.12317.tar.tar `
-AsByteStream -TotalCount 4
归档共包含约 2.4 万个条目，其中一千余个属于 PowerShell 目录。除 pwsh.exe 外，还包括 pwsh.deps.json、pwsh.runtimeconfig.json、PowerShell 模块、许可证和第三方声明。顶层依赖还包括 Git、Node.js、Python、Poppler、libheif 和 jxrlib。
运行时清单给出的答案
安装目录中的 runtime.json 是最直接的证据。其关键字段如下：
{
"artifactToolVersion": "2.8.43",
"bundleFormatVersion": 2,
"bundleVersion": "26.813.12317",
"nativeDependencies": [
"libheif",
"jxrlib",
"poppler",
"powershell",
"git"
],
"nodeVersion": "v24.19.0",
"pnpmVersion": "11.19.0",
"pythonVersion": "3.12.13",
"targetArch": "x64",
"targetPlatform": "win32"
}
这里的 powershell 与 Git、Python、Node.js 同级，足以说明 PowerShell 是 primary runtime 的显式原生依赖，而非仅由 PATH 偶然解析到的系统 pwsh。
验证二进制身份
最后检查实际安装的 pwsh.exe：
$pwsh = Join-Path $env:USERPROFILE `
'.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe'
Get-Item $pwsh |
Select-Object FullName, @{n='Version';e={$_.VersionInfo.ProductVersion}}
Get-AuthenticodeSignature $pwsh |
Select-Object Status, StatusMessage,
@{n='Signer';e={$_.SignerCertificate.Subject}}
本机结果为 PowerShell 7.6.4，文件元数据中的公司为 Microsoft Corporation，Authenticode 状态为 Valid，签名者也是 Microsoft Corporation。这说明 Codex 打包的是微软签名的 PowerShell 构建，而不是自行伪造名称的可执行文件。
为什么 Codex 要自己带一份 PowerShell 7
基于官方文档和本机证据，可以把原因分成“已证实”与“合理推断”。
已证实：
- Windows 版 Codex 需要在 PowerShell 中原生执行任务，并受 Windows sandbox 约束。
- Codex 存在一个独立、版本化、可由管理策略启停的 bundled workspace runtime。
- primary runtime 明确包含 PowerShell，Windows sandbox 也被授予访问该运行时的能力。
合理推断：
- 固定 PowerShell 版本能减少 Windows PowerShell 5.1、不同 PowerShell 7 版本、用户 profile 和
PATH差异造成的不确定性。 - 将 PowerShell、Git、Node.js、Python 和文档处理依赖打成同一运行时，可让插件和技能依赖一个可预测的工具链。
- 运行时包与 Codex 桌面应用采用不同版本号，说明它可以在不完全同步更新应用主体的情况下独立演进。
- 把可执行文件放入沙箱明确可访问的位置，比依赖系统上未知位置和权限的安装更容易建立稳定的权限边界。
这些推断与现有证据一致，但不应冒充 OpenAI 对产品设计动机的逐字声明。
对实际使用的影响
Codex 内置 PowerShell 不会卸载、替换或升级系统 PowerShell，也不会自动改变用户在普通终端中输入 pwsh 时使用的版本。应始终以进程路径确认当前实例，而不是只看版本号：
(Get-Process -Id $PID).Path
(Get-Command pwsh.exe).Source
如果脚本依赖特定模块、profile、执行策略或 .NET 行为，也应分别在目标 PowerShell 实例中验证。Windows PowerShell 5.1 基于 .NET Framework，PowerShell 7 基于现代 .NET；两者并行存在不等于行为完全一致。
最终结论
本次检查中的 PowerShell 7.6.4 不是系统误识别，也不是用户安装残留；它来自 OpenAI 分发的 codex-primary-runtime。官方资料能够证明原生 PowerShell、Windows sandbox、bundled runtime 和 primary runtime 访问之间的关系；本机下载日志、运行时清单、归档内容和微软签名则补齐了“这份 pwsh.exe 到底从哪里来”的证据链。具体运行时版本和路径会随 Codex 更新而变化，应以复核结果为准。
