企业官网建设流程全解析

如果你正在 Windows 上装 Codex 桌面版，一路点“下一步”走到最后，却在“继续完成 Windows 设置”这一步卡住，紧接着弹出一句“Windows 沙箱初始化失败”，先别急着重装系统，也别第一反应就是 Codex 安装包坏了。这句话其实不是 Codex 在骂人，而是 Windows 系统里的沙箱组件没能按时完成初始化。Codex 在 Windows 上需要一个隔离环境来安全执行代码，日常承担这个任务的就是 Windows 沙箱，所以它起不来，安装流程就会卡死在这个界面。这篇内容就围绕这一条报错展开，从硬件虚拟化、Windows 可选功能、Hyper-V 运行服务、日志排障几个层面，把排查顺序完整梳理一遍，最后还会附上我实际修过几台机器后踩出来的坑，希望能帮你少走弯路。

1. Codex 为什么会跟 Windows 沙箱绑在一起

1.1 Codex 的本地执行能力依赖隔离环境

Codex 桌面版不是普通聊天助手，它能读取项目文件、给出修改建议，甚至直接在本地运行命令、执行脚本。这种“AI 直接操作电脑”的能力是把双刃剑：效率高，但风险也大。AI 生成的命令不可能百分之百正确，万一它在你真实环境下误删了文件、改了配置、启动了不该启动的服务，后果可比一条聊天消息严重多了。

Windows 桌面版选用的隔离方案就是 Windows 沙箱。它本质上是一个轻量虚拟机，有独立的内核会话、独立的文件系统，你在这个环境里折腾得再厉害，关闭后所有改动都会被丢弃，宿主系统干干净净。用个生活化的类比：你不会让装修工人穿着沾满泥的鞋直接踩你的地板，你会让他们在门口铺一块临时地垫，干完活把地垫一卷扔了就行。沙箱就是 Codex 脚下的那块“临时地垫”。

理解了这层关系，再看“Windows 沙箱初始化失败”这句话就明白多了：Codex 只是在尝试铺地垫，地垫铺不上，进门干活自然无从谈起。

1.2 “继续完成 Windows 设置”这一步到底在做什么

标题里提到，报错前用户点击的是“继续完成 Windows 设置”。这是安装向导的收尾阶段，目标是初始化本地执行环境。Windows 沙箱的启动过程不是一句“开个虚拟机”那么简单，背后是一连串动作：创建虚拟机配置、启动虚拟机监控程序、加载引导内核、挂载虚拟磁盘、建立会话通道。这一串流程里任何一个环节出问题，最终对外呈现的可能就只是一句笼统的“初始化失败”。

所以这个阶段卡住，绝大多数情况下不是 Codex 本身的 bug，而是系统环境没满足沙箱的运行条件。你要做的也不是反复重装 Codex，而是先把 Windows 沙箱这个底层组件调理好。后面所有步骤都是围绕这个目标展开的。

1.3 沙箱启动的三层依赖：硬件虚拟化、Windows 功能、服务

Windows 沙箱虽然带了“沙箱”两个字，骨子里是一台 Hyper-V 架构的虚拟机。只要是虚拟机，就绕不开三层依赖：

第一层是硬件层。CPU 必须支持虚拟化指令集，并且要在 BIOS/UEFI 里明确开启。没有这层，虚拟机监控程序连加载的机会都没有。

第二层是系统功能层。Windows 里面有几个可选功能必须有，包括“虚拟机平台”“Windows 虚拟机监控程序平台”“Windows 沙箱”本体。功能完整，沙箱才有对应的组件可用。

第三层是运行服务层。即便功能装齐了，如果 Hyper-V 相关的服务没跑起来，或者虚拟化平台没有被系统引导加载，沙箱依然会启动失败。

这三层是层层向下的依赖关系。底层缺一个，上层就会报各种稀奇古怪的错，但最终都会汇总到同一句提示上。所以排查时必须按顺序来：先确认硬件虚拟化，再看系统功能是否装好，最后检查服务状态。跳着查，很容易陷入“功能明明装了我为什么还是失败”的死循环。

2. 排查前准备：先确认你那台机器到底缺哪一环

2.1 看硬件：虚拟化到底开没开

排查第一步，优先确认硬件虚拟化状态。原因很简单：如果 BIOS 里虚拟化没开，后面装再多组件都是白费功夫。

最快的查看方式是打开任务管理器，切到“性能”选项卡，选中“CPU”，右下角能看到“虚拟化”一栏，显示“已启用”才是正常的。这个方法最直观，但兼容性略差，有些老机器显示不出来。

更可靠的确认方式是命令行。按 Win+R，输入 cmd 回车，执行：

systeminfo | findstr /i "Hyper-V"

输出里会包含一段“Hyper-V 要求”，一共四行：

• 虚拟机监控程序模式：是否已检测到虚拟机监控程序，如果显示“已检测到”，说明当前系统已经有虚拟化平台在跑。
• 固件中已启用虚拟化：这一项直接反映 BIOS 里的开关状态，显示“是”才正常。
• 二级地址转换：也就是 SLAT 技术，Intel 的 EPT 或 AMD 的 NPT。大部分近十年的 CPU 都支持，显示“是”即可。
• 数据执行保护：硬件级防溢出能力，一般默认开启。

如果这四项中有任何一项是“否”，尤其是“固件中已启用虚拟化：否”，基本可以确定问题出在 BIOS 层，直接跳到后面的方案 A。如果四项全对，继续往下查功能组件。

2.2 看系统功能：沙箱组件是不是真的装了

硬件没问题，接下来看 Windows 功能有没有装齐。这里需要检查三个可选功能：虚拟机平台、Windows 虚拟机监控程序平台、Windows 沙箱。

用管理员身份打开命令提示符，分别执行：

dism /online /get-featureinfo /featurename:VirtualMachinePlatform dism /online /get-featureinfo /featurename:HypervisorPlatform dism /online /get-featureinfo /featurename:Containers-DisposableClientVM

三个命令的结尾都会显示 State 这一项，期望值是 Enabled。如果看到 Disabled，说明对应功能没启用，那问题就找到了。

嫌三条命令麻烦，也可以直接用 PowerShell 一次性查：

Get-WindowsOptionalFeature -Online | Where-Object { $_.FeatureName -match "VirtualMachinePlatform|HypervisorPlatform|Containers-DisposableClientVM" } | Select-Object FeatureName, State

这里必须提一个非常容易忽视的前提：Windows 沙箱目前只支持专业版、企业版和教育版。如果你用的是家庭版，即便照着教程去启用功能，也可能会发现找不到 Containers-DisposableClientVM 这一项。这不是你操作错了，而是版本限制。遇到这个情况，要么考虑升级系统版本，要么等 Codex 未来支持其它执行后端。

2.3 看服务：Hyper-V 宿主计算服务是否活着

硬件也正常、功能也装齐了，那就看服务。Windows 沙箱运行起来是一台临时 Hyper-V 虚拟机，这类虚拟机的生命周期由“Hyper-V Host Compute Service”负责，它有一个更常见的服务名：vmcompute。另外还建议顺手看一眼“Hyper-V Virtual Machine Management Service”，服务名 vmms。

用管理员 PowerShell 检查：

Get-Service vmcompute, vmms

正常情况下，vmcompute 应该处于 Running 状态，vmms 大多数情况下也会被拉起来。如果显示 Stopped，可以先手动启动试一下：

Start-Service vmcompute, vmms

启动失败的话，背后的原因就多了，可能需要结合后面的事件日志来查。如果服务能启动，但一重启又变回 Stopped，那通常是依赖组件出了问题，也要继续往下看。

2.4 快速判断清单

排查到这里，你可以对照下面这张表，快速判断自己卡在哪一层：

这张表是我排查类似问题的固定顺序，能覆盖八到九成的失败场景。剩下少数情况，再进事件日志里挖细节。

3. 一步步修复 Windows 沙箱初始化失败

3.1 方案 A：进 BIOS 开启虚拟化

如果前面的检查发现“固件中已启用虚拟化：否”，那就得重启进 BIOS 了。不同品牌的主板按键不完全一样，台式机常见的是 Del 键，笔记本不少品牌用的是 F2，也有些是 F10 或 Esc，开机时盯着屏幕下方的提示操作就行。

进入 BIOS/UEFI 界面后，找包含以下关键词的菜单项：

• Intel 平台：Intel Virtualization Technology 或 VT-x
• AMD 平台：SVM Mode 或 AMD-V
• 部分主板还会额外提供 VT-d 或 IOMMU 选项，建议一并开启，这关系到设备直通能力，沙箱运行时也会更稳定

这些选项一般藏在高级设置里，英文菜单通常叫 Advanced、CPU Configuration、Processor Settings 之类，不同厂商位置差异很大，但用页面内的搜索功能找关键词通常很快。

改完设置保存退出，系统会重启。这一步完成后，回到 Windows 里再用 systeminfo 验证一下，确认“固件中已启用虚拟化”变成“是”。有些情况下改完 BIOS 仍然显示未启用，那就要考虑升级 BIOS 固件，或者检查是不是被安全软件给“保护”掉了，后一种情况在部分品牌预装机上出现过，可以先在 Windows 安全中心里临时关掉相关核心隔离功能再验证。

3.2 方案 B：用 DISM 把三个组件一次补齐

硬件层确认没问题后，如果功能状态是 Disabled 或者干脆缺失，就用 DISM 把它们装上。以管理员身份打开 PowerShell，依次执行：

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism /online /enable-feature /featurename:HypervisorPlatform /all /norestart dism /online /enable-feature /featurename:Containers-DisposableClientVM /all /norestart

这里解释一下两个参数：/all 表示把依赖项一并启用，避免出现只装了主功能、缺依赖的情况；/norestart 表示每装完一个不要立刻重启，等三条命令都执行完再手动重启一次，省得来回折腾。

三条命令都显示操作成功之后，重启电脑。注意，这里必须重启，千万不要以为命令执行完功能就已经生效了，很多功能开关需要重启才能落到系统内核里，这是新手最容易踩的坑。

如果 DISM 报错，比较常见的错误码是 0x800F0950 或 0x800F081F，这种一般是 Windows 更新服务被关闭，或者系统映像文件有问题。前者先打开 Windows Update 相关服务再重试；后者可以先用 DISM 检查系统映像完整性：

dism /online /cleanup-image /restorehealth

跑完再回头启用功能。

3.3 方案 C：修正 hypervisorlaunchtype 启动类型

有些情况下，功能和服务都正常，但沙箱还是起不来，那就得查一下系统的虚拟机监控程序会不会随开机启动。这跟 Windows 的启动配置有关，cached 在引导配置数据里，控制项叫 hypervisorlaunchtype。

用管理员命令提示符执行：

bcdedit /enum {current}

在输出里找到 hypervisorlaunchtype 这一行，期望值是 Auto。如果看到的是 Off，那说明虚拟机监控程序被关闭了，沙箱自然无法启动。这种情况多见于装过 Hyper-V 又卸载、或使用过某些“系统优化工具”的机器上。

修复方式很简单，直接改回来：

bcdedit /set hypervisorlaunchtype auto

执行完后重启。想验证是否生效，可以再执行一次 bcdedit /enum {current}，确认已经变成 Auto。

3.4 方案 D：从事件日志里挖真正的错误码

当三层依赖全部检查过、该修的都修了，沙箱仍然报“初始化失败”，那就不能凭感觉瞎猜了，应该去事件查看器里看系统到底记录了什么。

Windows 沙箱相关日志主要集中在事件查看器的“应用程序和服务日志”下：Microsoft > Windows > Hyper-V-Compute > Admin，Hyper-V-VMMS 下的 Admin 日志也值得看。用 PowerShell 也可以快速过滤最近的错误事件：

Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-Compute/Admin" -MaxEvents 20 | Where-Object LevelDisplayName -eq "错误"

重点看错误级别的事件，里面往往包含 Error Code。这里列几个常见的：

事件日志是很多人在排查时容易跳过的环节，但恰恰是它最能直接给出方向，比反复重启试错高效得多。

3.5 方案 E：排查干扰项（第三方虚拟化、内存完整性、组策略）

如果日志里也没有明确线索，就要考虑是不是有什么程序在“抢地盘”。Windows 沙箱依赖 Hyper-V 架构，而市面上不少第三方虚拟化工具、以及一些带内核级防护的安全软件，也会尝试操作同一套虚拟化资源。冲突起来，沙箱就会莫名其妙地起不来。

常见干扰项包括 VMware、VirtualBox、各类安卓模拟器，以及部分杀毒软件自带的虚拟化防护模块。排查时先退出这些软件再试沙箱，如果恢复正常，再逐个加回来定位是谁在捣乱。另外，Windows 安全中心里有一个“内存完整性”功能，属于基于虚拟化的安全检查，在某些机型上它和沙箱同时开启会引发冲突。遇到正常手段都试完还搞不定的情况，可以临时关闭内存完整性再测试，路径是“Windows 安全中心 > 设备安全性 > 内核隔离设置”。

还有一个容易被忽略的点是组策略。运行 gpedit.msc，进入“计算机配置 > 管理模板 > Windows 组件 > Windows 沙箱”，右侧有一项“允许 Windows 沙箱”，需要确保是“已启用”或“未配置”。部分机器上该策略被手动禁用，沙箱会被直接拒之门外。

4. 修完之后：让 Codex 真正跑起来

4.1 先手动验证沙箱，再回 Codex

系统层面的修复都做完之后，不要急着点开 Codex，先手动验证一次 Windows 沙箱是否已经正常。这一步能把问题明确归位：是系统没修好，还是 Codex 自己的初始化流程卡住。

点击开始菜单，搜索“Windows 沙盒”或“Windows Sandbox”，右键选择“以管理员身份运行”。正常情况下会弹出一个独立的窗口，里面是干净的桌面和一个默认的浏览器图标，这个窗口出现，基本可以判断沙箱已经能正常创建。如果这个窗口就没弹出来，说明系统层面还有问题，需要回到第 3 部分继续排查。

手动验证的意义在于：链路上的不确定性越少越好。如果你跳过去直接开 Codex，一旦失败，你都不知道是底层环境的问题还是应用层的问题，排查范围一下就扩大了。

4.2 重新执行 Codex 的设置步骤

确认沙箱窗口能正常弹出之后，重启一遍 Codex 安装向导或者直接打开 Codex 桌面版，再次点击“继续完成 Windows 设置”。这次正常情况下应该能顺利往下走，后续会要求登录账号、授权本地执行等。

有一个细节值得提一下：Codex 窗口尽可能用“以管理员身份运行”打开。沙箱初始化过程需要一定的系统级权限，如果当前用户是标准账户或者系统 UAC 设置比较严格，授权环节可能会卡住。管理员方式运行后如果权限提示消失，就说明之前是被权限给拦住了。

4.3 沙箱正常但 Codex 仍报错的处理思路

有一种比较折磨人的情况：手动启动 Windows 沙箱完全正常，但回到 Codex 里仍然提示“初始化失败”。走到这一步，系统层面的嫌疑基本可以排除，重点要转到 Codex 自身。

先找 Codex 的日志文件。它一般位于用户目录下的应用数据文件夹，路径类似 %LOCALAPPDATA%\OpenAI\Codex\logs，里面会有会话记录和错误堆栈，重点看最近一次点击“继续完成 Windows 设置”时间点附近的日志。这类日志一般不会直接告诉你“沙箱失败”，但会留下调用沙箱时的参数、返回值、超时信息，这些才是定位问题的关键。

如果日志里看不出问题，再检查磁盘剩余空间和内存占用。沙箱运行时不仅需要系统给虚拟机预留内存，还需要临时生成差分虚拟磁盘，如果 C 盘剩余空间太少，或者内存使用率已经非常高，初始化同样可能失败。这种场景下，清理磁盘、关闭几个大内存应用，再重试，往往就好了。

5. 常见问题与避坑记录

5.1 问题速查表

把平时高频出现的问题汇总一下，方便快速定位：

表格里没有覆盖到所有极端情况，但应对日常八九成的问题足够。

5.2 我实际踩过的几个坑

第一个坑：功能装完不重启直接继续。我遇到过不止一次有朋友发截图问，DISM 已经提示成功了，Codex 还是报初始化失败。问了一句“重启了吗”，对面沉默了。功能启用和真正加载到内核之间还差一次重启，这个顺序不能省，也不能觉得“我已经重启过一次了”就忽略，要看功能状态确认后再判断。

第二个坑：BIOS 里明明开了虚拟化，Windows 里却显示没开。这种一般出现在老主板上，或者 UEFI 设置里存在多个开关，开错了层级。另外，个别安全软件会拦截虚拟化指令，导致系统里检测不到。常规做法是先退出安全软件、升级 BIOS，再重新检查。

第三个坑：杀毒软件静默拦截服务启动。vmcompute 服务启动时，部分安全软件会弹窗询问是否允许，如果没注意点了“不允许”，服务就永远处于 Stopped 状态。查这类问题时要顺手去安全软件的主防日志里看一眼，别只顾着系统的服务面板。

第四个坑：Windows 家庭版硬要开沙箱。功能列表里没有 Containers-DisposableClientVM，强制用命令行无从谈起。如果你的机器是家庭版，又想用 Codex 桌面版的本地执行能力，比较理性的选择是升级到专业版，或者换用不依赖沙箱的执行模式。

5.3 沙箱修好之后的稳定性建议

修好只是第一步，后续如果想稳定使用 Codex 桌面版，有几个细节值得注意。

内存是沙箱最敏感的资源，建议整机内存至少 8GB，喜欢开一堆浏览器标签的朋友直接 16GB 起步。沙箱默认会申请一部分内存，内存紧张时初始化失败的报错会反复出现。

另外，保持系统更新是长期稳定运行的基础。Windows Update 会持续修复 Hyper-V 和沙箱相关的内核级 bug，关闭更新可能一时省事，但后续各种兼容性问题都会找上门。

如果经常跑比较大的项目，可以考虑给沙箱单独写一个配置文件，限制内存大小、指定是否映射宿主机目录。这是进阶玩法，但对经常用 Codex 跑真实项目的人来说，能有效避免沙箱资源占用过高导致宿主机变卡。

我个人实际处理的这类问题里，九成都是硬件虚拟化没开或功能组件不完整造成的，真正遇到系统文件损坏、恶软干扰的少之又少。所以按着清单顺序走一遍，绝大多数人不需要重装系统就能解决。如果修完之后 Codex 后续在新的项目里越来越吃资源，再回头检查沙箱配置、清理虚拟磁盘缓存，这里就不再展开细说了。希望这套排查路径对你有用。