求助codex的终端报错初始化失败
- 内容介绍
- 文章标签
- 相关推荐
[求助] PowerShell 和cmd 在 codex cli和codex WindowsAPP 中启动崩溃：TypeInitializerException (Win32Exception 126)
问题概述
今天突然遇到一个奇怪的问题：Windows 原生终端（Windows Terminal）可以正常打开 PowerShell，但在 (Codex) 的集成终端中启动 PowerShell 时直接崩溃，报错 System.TypeInitializationException，内部异常为 Win32Exception (126): 找不到指定的模块。
这个问题是今天突然发生的，昨天之前一直正常
环境信息
- 操作系统: Windows 11 25h2
- 出错软件: codex cli codex插件 codex APP
- 受影响组件: 集成终端 (Integrated Terminal) → (C:WindowsSystem32WindowsPowerShellv1.0powershell.exe)
- 正常组件: Windows Terminal (WT) 中的 PowerShell (疑似使用的是 PS 7 或绕过了某些检查)
- 发生时间: 2026-03-09 (今天)
错误日志详情
在 codex终端中看到的完整报错堆栈如下：
Process terminated. The type initializer for ‘System.Management.Automation.Runspaces.InitialSessionState’ threw an exception.
at System.Environment.FailFast(…)
…
at Microsoft.PowerShell.ManagedPSEntry.Main(System.String)
System.TypeInitializationException: The type initializer for ‘System.Management.Automation.Runspaces.InitialSessionState’ threw an exception.
—> System.ComponentModel.Win32Exception (126): 找不到指定的模块。
at System.Management.Automation.Internal.SecuritySupport.GetSaferPolicy(String path, SafeHandle handle)
at System.Management.Automation.Security.SystemPolicy.TestSaferPolicy(String testPathScript, String testPathModule)
at System.Management.Automation.Security.SystemPolicy.GetAppLockerPolicy(String path, SafeHandle handle)
at System.Management.Automation.Security.SystemPolicy.GetLockdownPolicy(String path, SafeHandle handle, Nullable1 canExecuteResult)
at System.Management.Automation.Security.SystemPolicy.GetSystemLockdownPolicy()
at System.Management.Automation.Runspaces.InitialSessionState..cctor()
— End of inner exception stack trace —
at System.Management.Automation.Runspaces.InitialSessionState.CreateDefault2()
at Microsoft.PowerShell.UnmanagedPSEntry.Start(String args, Int32 argc)
关键分析
从堆栈跟踪来看，问题出在 System.Management.Automation.Security.SystemPolicy 类初始化时：
- 错误代码 126: 明确表示 LoadLibrary 失败，即找不到指定的 DLL 模块。
- 调用链: GetSaferPolicy → GetAppLockerPolicy。这表明 PowerShell 5.1 在启动时试图加载 AppLocker 或 软件限制策略 相关的底层系统 DLL（通常是 apphelp.dll 或其依赖项），但失败了。
- 现象差异:
- VS Code 默认调用系统自带的 PowerShell 5.1，它严格依赖系统完整性检查。
- Windows Terminal 可能默认配置为了 PowerShell 7 (pwsh)，或者其启动参数绕过了这个特定的安全策略检查点，因此表现正常。
我已尝试的排查步骤
在发帖前，我已经尝试了以下操作，但问题依旧：
- 重启电脑: 无效。
- 检查 codex设置: 确认终端配置文件正常，但修改成git bash也没有用，git bash也会失败，未修改过奇怪参数。
- (如果你已经运行过 SFC，可以加上这条): 尝试运行 sfc /scannow，结果显示系统正常，无需修复
求助大家
这种情况通常是什么原因导致的？
任何思路或解决方案都感激不尽！谢谢！
网友解答：--【壹】--：
非常感谢~
之前一直报uv，py，fnm等等错误，原来是这样！
--【贰】--：
这是谷歌回答的原因：这是一个非常经典且典型的“父子进程环境继承”问题。你的排查思路非常清晰，定位也很准确。
既然你在 Windows Terminal 中能正常运行，且 sfc /scannow 也没有报错，同时 CMD 和 Git Bash 在 Codex 中也同样失败，这基本上排除了 PowerShell 自身损坏的可能性。
核心原因剖析
错误代码 Win32Exception (126) 的本质是 ERROR_MOD_NOT_FOUND（找不到指定的模块/DLL）。 当 PowerShell 5.1 启动时，它会调用底层的 Windows API（如 srpapi.dll 或 wldp.dll）来检查 AppLocker 和软件限制策略。
为什么只在 Codex 的集成终端里找不到？原因通常有以下三个：
-
环境变量 (
PATH) 被 Codex 破坏：这是最常见的原因。如果 Codex 在启动或初始化终端进程时，错误地覆盖或截断了系统的PATH环境变量，导致子进程（PowerShell/CMD）的搜索路径中丢失了C:\Windows\System32，那么在执行LoadLibrary加载系统自带的 DLL 时就会报 126 错误。 -
杀毒软件 / EDR 拦截：部分安全软件对“开发工具/IDE（如 Codex）派生命令行进程”有严格的监控。它可能允许 Windows Terminal 启动 PS，但静默拦截了 Codex 派生的子进程加载特定的安全策略 DLL。
-
Codex 自身的版本 Bug：你提到这是今天突然发生的，如果是 Codex 刚刚进行了自动更新，其底层的终端模拟器（通常基于 Node-pty 之类的组件）在分配伪控制台（ConPTY）或传递进程环境块（PEB）时可能存在缺陷。
针对性排查与解决方案
你可以按照以下顺序进行修复或排查：
1. 验证并规避：强制使用 PowerShell 7 (最快恢复工作的方法)
既然 Windows Terminal 可能使用的是 PowerShell 7 (pwsh.exe) 并且正常工作，你可以直接在 Codex 的设置中，将默认集成终端的路径硬编码为 PS7 的路径。PS7 的架构与 PS5.1 不同，它对系统底层策略的依赖链更少，通常能绕过这个 Bug。
-
操作：在 Codex 的终端配置文件（通常类似
settings.json）中，将终端路径修改为："C:\\Program Files\\PowerShell\\7\\pwsh.exe" -
注意：请确保你确实安装了 PowerShell 7。
2. 隔离测试：从纯净环境启动 Codex (排查 PATH 问题)
为了验证是不是环境变量引起的，我们可以尝试从一个已知正常的终端“传递”健康的环境变量给 Codex。
-
打开正常的 Windows Terminal (CMD 或 PowerShell 都可以)。
-
在终端中直接通过命令行启动 Codex APP（找到 Codex 的可执行文件路径，例如：
C:\Users\YourName\AppData\Local\Programs\codex\codex.exe，直接回车运行）。 -
在新打开的 Codex 中，再次尝试打开集成终端。
- 结果分析：如果这样打开的 Codex 终端恢复正常，说明是你系统的用户环境变量中存在格式错误（比如某个路径包含了非法的不可见字符，或者路径过长），导致 Codex 读取或传递时发生截断，丢失了
System32路径。
3. 检查安全软件拦截日志
如果你安装了火绒、360、迈克菲（McAfee）或公司级的 EDR 软件（如 CrowdStrike, 奇安信等）：
-
打开它们的“防护日志”或“隔离区”。
-
查看今天是否有针对
powershell.exe、cmd.exe或codex.exe的拦截记录，特别是涉及 DLL 注入或模块加载的记录。如果有，将 Codex 添加到白名单。
4. 终极定位：使用 Process Monitor (ProcMon)
如果上述方法都不奏效，我们可以直接抓取缺失的到底是哪个模块。
-
下载微软官方工具 Sysinternals Process Monitor。
-
打开 ProcMon，设置过滤器 (Filter)：
-
Process Nameispowershell.exethen Include -
ResultisNAME NOT FOUNDthen Include
-
-
开始捕获 (Ctrl+E)，然后在 Codex 中触发一次报错。
-
停止捕获。你会在日志中清晰地看到 PowerShell 在崩溃前，试图从哪些目录加载哪个
.dll失败了。
--【叁】--：
此贴终结,已找到解决方案,是在点击
1526ccf382ac51cc4a2f019f8631af95988×276 7.96 KB
新版codex app的这个apply按钮后,配置文件新增了
d6e5b63c740a9640dfe07b4b02358dc01149×1022 101 KB
inherit字段,然后改成了core,我把这个配置删除,也就恢复了all的字段,终端就一切正常了
希望能帮到大家
--【肆】--：
找到就行了
--【伍】--：
感谢佬解答,我已找到解决方案,我在查看codex配置文件后去文档翻阅,我发现了Windows codex app自动添加的一个配置文件参数导致了这个问题,我放在帖子的一级回答下
[求助] PowerShell 和cmd 在 codex cli和codex WindowsAPP 中启动崩溃：TypeInitializerException (Win32Exception 126)
问题概述
今天突然遇到一个奇怪的问题：Windows 原生终端（Windows Terminal）可以正常打开 PowerShell，但在 (Codex) 的集成终端中启动 PowerShell 时直接崩溃，报错 System.TypeInitializationException，内部异常为 Win32Exception (126): 找不到指定的模块。
这个问题是今天突然发生的，昨天之前一直正常
环境信息
- 操作系统: Windows 11 25h2
- 出错软件: codex cli codex插件 codex APP
- 受影响组件: 集成终端 (Integrated Terminal) → (C:WindowsSystem32WindowsPowerShellv1.0powershell.exe)
- 正常组件: Windows Terminal (WT) 中的 PowerShell (疑似使用的是 PS 7 或绕过了某些检查)
- 发生时间: 2026-03-09 (今天)
错误日志详情
在 codex终端中看到的完整报错堆栈如下：
Process terminated. The type initializer for ‘System.Management.Automation.Runspaces.InitialSessionState’ threw an exception.
at System.Environment.FailFast(…)
…
at Microsoft.PowerShell.ManagedPSEntry.Main(System.String)
System.TypeInitializationException: The type initializer for ‘System.Management.Automation.Runspaces.InitialSessionState’ threw an exception.
—> System.ComponentModel.Win32Exception (126): 找不到指定的模块。
at System.Management.Automation.Internal.SecuritySupport.GetSaferPolicy(String path, SafeHandle handle)
at System.Management.Automation.Security.SystemPolicy.TestSaferPolicy(String testPathScript, String testPathModule)
at System.Management.Automation.Security.SystemPolicy.GetAppLockerPolicy(String path, SafeHandle handle)
at System.Management.Automation.Security.SystemPolicy.GetLockdownPolicy(String path, SafeHandle handle, Nullable1 canExecuteResult)
at System.Management.Automation.Security.SystemPolicy.GetSystemLockdownPolicy()
at System.Management.Automation.Runspaces.InitialSessionState..cctor()
— End of inner exception stack trace —
at System.Management.Automation.Runspaces.InitialSessionState.CreateDefault2()
at Microsoft.PowerShell.UnmanagedPSEntry.Start(String args, Int32 argc)
关键分析
从堆栈跟踪来看，问题出在 System.Management.Automation.Security.SystemPolicy 类初始化时：
- 错误代码 126: 明确表示 LoadLibrary 失败，即找不到指定的 DLL 模块。
- 调用链: GetSaferPolicy → GetAppLockerPolicy。这表明 PowerShell 5.1 在启动时试图加载 AppLocker 或 软件限制策略 相关的底层系统 DLL（通常是 apphelp.dll 或其依赖项），但失败了。
- 现象差异:
- VS Code 默认调用系统自带的 PowerShell 5.1，它严格依赖系统完整性检查。
- Windows Terminal 可能默认配置为了 PowerShell 7 (pwsh)，或者其启动参数绕过了这个特定的安全策略检查点，因此表现正常。
我已尝试的排查步骤
在发帖前，我已经尝试了以下操作，但问题依旧：
- 重启电脑: 无效。
- 检查 codex设置: 确认终端配置文件正常，但修改成git bash也没有用，git bash也会失败，未修改过奇怪参数。
- (如果你已经运行过 SFC，可以加上这条): 尝试运行 sfc /scannow，结果显示系统正常，无需修复
求助大家
这种情况通常是什么原因导致的？
任何思路或解决方案都感激不尽！谢谢！
网友解答：--【壹】--：
非常感谢~
之前一直报uv，py，fnm等等错误，原来是这样！
--【贰】--：
这是谷歌回答的原因：这是一个非常经典且典型的“父子进程环境继承”问题。你的排查思路非常清晰，定位也很准确。
既然你在 Windows Terminal 中能正常运行，且 sfc /scannow 也没有报错，同时 CMD 和 Git Bash 在 Codex 中也同样失败，这基本上排除了 PowerShell 自身损坏的可能性。
核心原因剖析
错误代码 Win32Exception (126) 的本质是 ERROR_MOD_NOT_FOUND（找不到指定的模块/DLL）。 当 PowerShell 5.1 启动时，它会调用底层的 Windows API（如 srpapi.dll 或 wldp.dll）来检查 AppLocker 和软件限制策略。
为什么只在 Codex 的集成终端里找不到？原因通常有以下三个：
-
环境变量 (
PATH) 被 Codex 破坏：这是最常见的原因。如果 Codex 在启动或初始化终端进程时，错误地覆盖或截断了系统的PATH环境变量，导致子进程（PowerShell/CMD）的搜索路径中丢失了C:\Windows\System32，那么在执行LoadLibrary加载系统自带的 DLL 时就会报 126 错误。 -
杀毒软件 / EDR 拦截：部分安全软件对“开发工具/IDE（如 Codex）派生命令行进程”有严格的监控。它可能允许 Windows Terminal 启动 PS，但静默拦截了 Codex 派生的子进程加载特定的安全策略 DLL。
-
Codex 自身的版本 Bug：你提到这是今天突然发生的，如果是 Codex 刚刚进行了自动更新，其底层的终端模拟器（通常基于 Node-pty 之类的组件）在分配伪控制台（ConPTY）或传递进程环境块（PEB）时可能存在缺陷。
针对性排查与解决方案
你可以按照以下顺序进行修复或排查：
1. 验证并规避：强制使用 PowerShell 7 (最快恢复工作的方法)
既然 Windows Terminal 可能使用的是 PowerShell 7 (pwsh.exe) 并且正常工作，你可以直接在 Codex 的设置中，将默认集成终端的路径硬编码为 PS7 的路径。PS7 的架构与 PS5.1 不同，它对系统底层策略的依赖链更少，通常能绕过这个 Bug。
-
操作：在 Codex 的终端配置文件（通常类似
settings.json）中，将终端路径修改为："C:\\Program Files\\PowerShell\\7\\pwsh.exe" -
注意：请确保你确实安装了 PowerShell 7。
2. 隔离测试：从纯净环境启动 Codex (排查 PATH 问题)
为了验证是不是环境变量引起的，我们可以尝试从一个已知正常的终端“传递”健康的环境变量给 Codex。
-
打开正常的 Windows Terminal (CMD 或 PowerShell 都可以)。
-
在终端中直接通过命令行启动 Codex APP（找到 Codex 的可执行文件路径，例如：
C:\Users\YourName\AppData\Local\Programs\codex\codex.exe，直接回车运行）。 -
在新打开的 Codex 中，再次尝试打开集成终端。
- 结果分析：如果这样打开的 Codex 终端恢复正常，说明是你系统的用户环境变量中存在格式错误（比如某个路径包含了非法的不可见字符，或者路径过长），导致 Codex 读取或传递时发生截断，丢失了
System32路径。
3. 检查安全软件拦截日志
如果你安装了火绒、360、迈克菲（McAfee）或公司级的 EDR 软件（如 CrowdStrike, 奇安信等）：
-
打开它们的“防护日志”或“隔离区”。
-
查看今天是否有针对
powershell.exe、cmd.exe或codex.exe的拦截记录，特别是涉及 DLL 注入或模块加载的记录。如果有，将 Codex 添加到白名单。
4. 终极定位：使用 Process Monitor (ProcMon)
如果上述方法都不奏效，我们可以直接抓取缺失的到底是哪个模块。
-
下载微软官方工具 Sysinternals Process Monitor。
-
打开 ProcMon，设置过滤器 (Filter)：
-
Process Nameispowershell.exethen Include -
ResultisNAME NOT FOUNDthen Include
-
-
开始捕获 (Ctrl+E)，然后在 Codex 中触发一次报错。
-
停止捕获。你会在日志中清晰地看到 PowerShell 在崩溃前，试图从哪些目录加载哪个
.dll失败了。
--【叁】--：
此贴终结,已找到解决方案,是在点击
1526ccf382ac51cc4a2f019f8631af95988×276 7.96 KB
新版codex app的这个apply按钮后,配置文件新增了
d6e5b63c740a9640dfe07b4b02358dc01149×1022 101 KB
inherit字段,然后改成了core,我把这个配置删除,也就恢复了all的字段,终端就一切正常了
希望能帮到大家
--【肆】--：
找到就行了
--【伍】--：
感谢佬解答,我已找到解决方案,我在查看codex配置文件后去文档翻阅,我发现了Windows codex app自动添加的一个配置文件参数导致了这个问题,我放在帖子的一级回答下