如果你最近在 Windows 桌面版 Codex 上撞见一个很拧巴的弹窗——点击“继续完成 Windows 设置”，紧接着冒出“Windows 沙箱初始化失败”，先别急着把它跟系统“八字不合”划等号。这个问题我前前后后帮几个朋友排查过，表面上是沙箱启动不了，实际上牵扯到虚拟化开关、Windows 功能组件、系统服务和组策略整整四层配置。这篇文章按我实际操作中的顺序，把排障思路和修复流程完整写出来，刚上手 Codex 的新手可以把它当清单逐项核对，老手也能当一次查漏补缺。
先说个结论：绝大多数情况下，问题出在 Windows 沙箱赖以运行的那套底层组件没就位，而不是 Codex 客户端本身坏了。只要你愿意花十几分钟跟着过一遍，大概率能把自己从“报错循环”里捞出来。
1. 先搞清楚“沙箱初始化失败”到底卡在哪一环
1.1 Codex 桌面版为什么离不开沙箱
Codex 这类 AI 编程助手跟普通聊天工具有个本质区别：它不只是“说”，它还会真的去执行命令、写文件、跑代码。让 AI 直接在宿主系统里乱跑，风险谁都说不清——哪怕只是调一个接口、跑一条安装命令，也可能把环境变量、注册表、磁盘文件折腾得面目全非。
Windows 沙箱在这里的意义就相当于一个一次性手套。它是一个基于 Hyper-V 的轻量级隔离环境，启动后给你一个临时的纯净 Windows 系统，跑完就关，里面做的任何操作都不会落到真实系统上。Codex 桌面版在初始化设置阶段会尝试拉起沙箱做一次“烟雾测试”，验证当前机器能不能安全地承载后续的代码执行任务。这一步失败，客户端就不允许你继续往下走，因为它判断后面所有代码任务都无法被隔离，风险不可控。
所以当你看到“Windows 沙箱初始化失败”时，第一反应不应是“Codex 有 bug”，而是“这台机器的沙箱环境本身有问题”。这个思路决定了后面排查的大方向：绕开 Codex，先看 Windows 沙箱能不能单独跑起来。
1.2 初始化失败的五类常见触发源
顺着“沙箱起不来”这个链路去拆，失败原因其实高度集中在几个点上，我按出现的概率排个序：
- 虚拟化没开启：Windows 沙箱本质是虚拟机，CPU 的硬件虚拟化开关没打开，一切都白搭。
- 系统功能组件缺失或未启用：比如“Windows 沙箱”“虚拟机平台”这些可选功能没勾选，或者勾选后系统没重启。
- 核心服务被禁用或启动失败：
vmcompute（Hyper-V 主机计算服务）和vmms（Hyper-V 虚拟机管理服务）是沙箱的生命线，一旦被系统优化工具或安全软件禁用，沙箱必然启动失败。 - 组策略或系统版本限制：家庭版系统根本没有 Windows 沙箱功能；某些企业环境下组策略也会强行关掉沙箱入口。
- 资源或环境异常：内存不足、C 盘空间不够、甚至你本身是在虚拟机里跑的 Windows，这些都会让沙箱初始化在最后一步翻车。
把这几类原因放在心里，接下来的检查就有了一条清晰的主线。
2. 环境自查：从 BIOS 到 Windows 功能的完整核对
2.1 第一步：确认 CPU 虚拟化已开启
这一步看似基础，但真的翻车率极高。尤其是很多人买的是品牌机，BIOS 里的虚拟化开关默认是关闭的。打开“任务管理器”切到“性能”选项卡，点击“CPU”，看右下角有没有“虚拟化：已启用”字段，十分钟内就能确认。
如果显示“已禁用”，就得进 BIOS 或 UEFI 设置界面。Intel 平台找Intel Virtualization Technology或VT-x，AMD 平台找SVM Mode或Secure Virtual Machine，改成 Enabled 后保存退出。值得注意的是笔记本和品牌台式机这一步入口五花八门——有的在“Advanced”菜单下，有的藏在“Security”→“Virtualization”里，有的主板甚至叫SVM Support，找不到就搜主板型号加“虚拟化”关键词，别凭感觉乱翻。
还有个容易被忽略的场景：如果你这台 Windows 本身装在 VMware、VirtualBox 或云服务器里，光在客户机里看虚拟化是没用的，必须在宿主机层面开启“嵌套虚拟化”。VMware 里对应的是勾选“虚拟化 Intel VT-x/AMD-V”，Hyper-V 或 KVM 也有类似选项。嵌套虚拟化没开，Windows 沙箱照样起不来，而且你在系统里怎么折腾都没用。
2.2 第二步：核对 Windows 版本与功能组件
确认虚拟化开启后，接着确认系统版本。Windows 沙箱只在专业版、企业版、教育版里提供，家庭版直接没有这个功能。你可以在“设置 → 系统 → 系统信息”里看版本，如果显示“Windows 11 家庭版”或“Windows 10 家庭版”，那基本不用往下排查了——系统里根本没有沙箱可选，要么升级系统版本，要么用后面的替代方案兜底。
对于专业版用户，打开“控制面板 → 程序 → 启用或关闭 Windows 功能”，在弹出的列表里找三个关键项：
- Windows 沙箱
- 虚拟机平台
- Hyper-V（通常包含在“Hyper-V”根节点下）
如果“Windows 沙箱”这一项找到了但没勾选，勾上后点击确定，系统会要求重启。这一步没有什么技巧，但请注意：重启后必须确认功能确实启用成功，而不是光看着勾选框变成黑色就以为完事了。命令行下可以这样验证：
Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform如果输出的State都是Enabled，说明功能层没问题。这里补充一点，Containers-DisposableClientVM是 Windows 沙箱在系统内部的“真实功能名”，GUI 里显示的名字叫“Windows 沙箱”，两者是一回事。很多教程让你直接敲一行命令启用它，效果等同于 GUI 打勾。
2.3 第三步：检查 Sandbox 相关服务状态
功能齐了，服务层也不能掉链子。以管理员身份打开 PowerShell，执行：
Get-Service vmcompute, vmms正常情况下两个服务的Status都应该是Running，StartType是Automatic。我遇到过一台机器，vmcompute的启动类型直接被人改成了Disabled，查了半天发现是之前装“系统优化工具”时被顺手关掉的。遇到这种情况，手动拉起来并恢复开机自启：
Set-Service vmcompute -StartupType Automatic Start-Service vmcompute Set-Service vmms -StartupType Automatic Start-Service vmms顺手提一句：vmms服务在没装完整 Hyper-V 管理工具时也可能缺席。如果 Get-Service 报找不到服务，先去“启用或关闭 Windows 功能”里把 Hyper-V 节点整个勾上再重启机器，然后再回来看服务列表。
另外，内存和磁盘也不要忽视。Windows 沙箱启动时会动态创建虚拟磁盘文件，默认在 C 盘，所以 C 盘剩余空间建议至少留出 10GB 以上；物理内存低于 8GB 的机器，最好关掉浏览器和微信再试，这个虽然是偏门的坑，但我在低配本上确实碰到过。
3. 实操修复：从启用功能到命令行修复的完整流水线
3.1 用 PowerShell 一次性启用所需功能
如果你不想在 GUI 里一个个找勾选框，或者系统功能列表里的选项呈灰色不可点，可以直接用管理员权限的 PowerShell 跑下面这套组合命令：
Enable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -All -NoRestart Enable-WindowsOptionalFeature -Online -FeatureName "Containers-DisposableClientVM" -All -NoRestart Enable-WindowsOptionalFeature -Online -FeatureName "Microsoft-Hyper-V-All" -All -NoRestart注意-NoRestart只是告诉系统先别强制重启，三条命令跑完后，务必手动重启一次。很多人只执行其中一条，漏掉VirtualMachinePlatform，因为 Windows 沙箱表面上依赖的是“Windows 沙箱”功能，底层却离不开虚拟机平台。这就好比你要开一间隔离病房，光有病房门牌不够，整个病房楼的基础设施得先通电、通水、通气。
重启之后，建议先单独测试一下 Windows 沙箱，不要直接去点 Codex。按 Win 键输入“Windows Sandbox”并回车，如果能正常弹出一个带桌面环境的窗口，说明沙箱本体已经通了，这时候再回头打开 Codex 继续初始化，基本上不会再卡在“Windows 沙箱初始化失败”。如果单独跑沙箱也报错，那就说明问题更深一层，往 3.2 和 3.3 走。
3.2 用 DISM 和 SFC 修复系统组件损坏
功能启用成功、服务也在跑，但沙箱依旧启动失败，这种情况下我强烈怀疑系统组件已经损坏。尤其是 Windows 更新打过补丁之后，vmcompute依赖的虚拟化栈文件如果被更新搞坏，就会出现这种“配置全对但就是跑不起来”的诡异状态。
用管理员身份的 PowerShell 依次跑两条命令：
DISM /Online /Cleanup-Image /RestoreHealth sfc /scannowDISM先从系统更新服务里把损坏的映像文件修复掉，sfc再扫描系统文件的完整性并替换错误版本。整个过程可能需要十几分钟，期间不要关窗口、不要强行断电。跑完后重启，再测沙箱。
我自己踩过的一个真实案例是：系统里装过某个旧版开发工具，它往C:\Windows\System32里塞了一个和沙箱冲突的 DLL 文件，导致所有功能、服务、组策略全部正常的情况下沙箱依然在初始化阶段崩溃。当时就是靠sfc /scannow把这个被替换的系统文件恢复回来才解决。所以说，这条命令不是什么“安慰剂”，在虚拟化相关的疑难杂症里，它真的能救命。
3.3 组策略与安全软件干扰排查
如果系统组件也修了，沙箱还是起不来，下一个要盯的就是组策略和第三方安全软件。
按Win + R输入gpedit.msc，进入“计算机配置 → 管理模板 → Windows 组件 → Windows 沙箱”，检查右侧有没有“允许 Windows 沙箱”这一项。如果状态被设置成“已禁用”，改成“未配置”或“已启用”。这个开关在一些企业定制系统或安全收紧过的系统里特别常见，个人系统一般不会主动改这里，但也不排除某些“优化工具”动了手。
安全软件这一层就比较微妙了。现在很多杀毒软件不光是扫病毒，还会监控可疑的系统服务行为，vmcompute.exe在启动时如果被安全软件拦截或者拖慢，沙箱初始化就会在超时后报失败。我的排查方式是：临时退出所有安全软件，或者把以下进程/服务加入信任名单：
C:\Windows\System32\vmcompute.exeC:\Windows\System32\vmms.exe- Windows Sandbox 的可执行程序：
C:\Windows\System32\WindowsSandbox.exe
加入信任名单后再重新启动沙箱。如果确认是安全软件导致的问题，就不要抱着“都关了就行”的心态，直接长期把上述进程设为信任，否则每次初始化都得先关杀毒，工作起来会非常痛苦。
另外提一下 Windows 安全中心的“内存完整性”功能（基于虚拟化的安全 VBS 的一部分）。这个功能跟沙箱在某些系统版本上存在兼容性摩擦，如果你开启了“内核隔离 → 内存完整性”，并且沙箱反复失败，可以临时关掉它再测试。注意这只是一个排除项，不要一上来就关，毕竟它本身是保护系统安全的重要机制。
4. 日志取证：让错误信息告诉你真实答案
4.1 用事件查看器定位沙箱启动失败的原因
到了这一步如果问题还没解决，就不能再靠“猜”了。Windows 沙箱启动失败这件事，系统会往事件日志里写非常详细的记录，关键是看你有没有找到正确的入口。
按Win + R输入eventvwr.msc，打开事件查看器，展开“应用程序和服务日志 → Microsoft → Windows”，找到Sandbox目录下的Operational日志。这里记录的才是 Windows 沙箱自己的启动、初始化、失败全过程。常规的“应用程序”日志里基本看不到沙箱的详细信息，所以要直接来这层翻。
以我处理过的几台机器为例，沙箱初始化失败时这条日志里通常会留下两种典型错误：
- 包含
Virtualization is disabled或0x80070000的，说明虚拟化或 Hyper-V 层存在问题； - 包含
WSInit或vmcompute超时字样的，说明服务响应不及时或权限异常。
配合查看“应用程序和服务日志 → Microsoft → Windows → Hyper-V-VMMS → Admin”，可以查vmms服务启动虚拟机时具体卡在了哪一步。两边的日志结合起来看，比任何教程都能更准确告诉你机器到底哪里出了问题。
4.2 用日志判断是配置问题还是权限问题
日志有时候会直接把问题定位到“权限”。常见的一种场景是系统里存在多个用户账户，沙箱服务运行在 SYSTEM 账户下，但沙箱内部要挂载用户配置文件时访问不到，于是初始化失败。这时候日志里往往会出现Access is denied字样。
如果你在日志中看到这类权限错误，可以考虑检查 Windows 沙箱相关目录的文件所有权。路径是：
%SystemRoot%\Sandbox正常情况下这个目录会自动创建并继承虚拟化服务所需的权限，如果被某些清理工具手动删除或改过权限，沙箱就会初始化失败。把管理员权限的 PowerShell 打开，手动重建一个干净目录并赋予 SYSTEM 和 Administrators 完全控制权即可。遇到这种问题的时候，日志的价值就体现出来了——不看日志，你根本不会联想到一个空目录也能让沙箱崩溃。
5. 常见问题与排查技巧实录
5.1 常见故障速查表
排障经验积累下来，我整理了一个极简速查表，适合你对照着快速定位：
| 现象 | 最可能原因 | 优先处置方案 |
|---|---|---|
| 提示虚拟化未启用 | BIOS 中 VT-x/SVM 关闭 | 进 BIOS 开启虚拟化开关 |
| 功能列表里找不到“Windows 沙箱” | 系统为家庭版 | 升级系统版本，或用替代方案 |
| 勾选功能后重启仍提示失败 | 服务vmcompute被禁用 | 手动设置服务为自动并启动 |
| 单跑沙箱立即报错退出 | 系统组件损坏 | 依次执行 DISM 和 SFC |
| 沙箱窗口闪一下就消失 | 安全软件拦截或权限异常 | 添加信任名单，检查 Sandbox 目录权限 |
| 内存充足但沙箱始终起不来 | 嵌套虚拟化未开启 | 检查是否在 VM 环境下运行 Windows |
这张表不能覆盖所有情况，但能覆盖我实际见过的大多数案例。真到了整张表都填完还没解决的地步，我建议你直接去翻事件日志，不要再盲试了。
5.2 重启后依然失败的奇怪案例
我在这里专门讲一个比较刁钻的场景，因为它最容易让人浪费时间：功能全开、服务全跑、日志里没有任何报错，但沙箱就是初始化失败。后来我发现在一台机器上，原因是 Windows 更新遗留了旧版本 Hyper-V 管理程序，导致系统里存在“两个虚拟机监控程序”的冲突。
这种情况下的表现非常迷惑：msinfo32里显示“已检测到虚拟机监控程序”，好像一切正常，但沙箱就是跑不起来。你只能靠bcdedit或者系统配置工具查看当前引导项是否加载了旧的 Hyper-V 启动条目。如果确认有多个 hypervisor 加载项，可以进“系统配置（msconfig） → 引导”里排查，将冲突的引导项清理后重启。这个问题不常见，一旦碰上，最容易让人误判成“硬件不支持”而放弃，所以单独拿出来说一句。
5.3 短期内无法修复时的替代路线
如果底层环境确实改不动——比如公司电脑 BIOS 锁死了虚拟化，或者你用的就是家庭版系统——那也别让 Codex 白白躺在那里。换个思路，不让它直接依赖 Windows 沙箱，而是让代码在一个容器化环境里运行。
现在 Codex 桌面版和命令行版本，都支持配置外部执行环境。比较稳妥的做法是装一个 Linux 容器环境（比如 Docker Desktop）或启用 WSL2，然后让 Codex 的执行环境指向容器而非 Windows 沙箱。这样既绕开了 Windows 沙箱的初始化限制，又保住了代码隔离的安全性。
我自己在帮朋友处理一台没法开虚拟化的办公本时，就用 Docker 容器作为兜底方案跑通了 Codex 的基本功能。虽然启动速度不如原生沙箱流畅，容器通信也有一点配置成本，但总比卡在“继续完成 Windows 设置”这一步强得多。
6. 最后分享一点个人排障心得
按我自己的经验，遇到“Windows 沙箱初始化失败”这类问题，最重要的不是急着去找高级技巧，而是把链路上的每一步都验证一遍：BIOS 虚拟化开没开、系统版本支不支持、功能组件启没启用、服务跑没跑、日志里写了什么。几乎 90% 的问题都能在前四步解决。
尤其要记住一个简单的逻辑：Codex 本身不是沙箱的制造者，它只是沙箱的使用者。所以在 Codex 里排障，不如跳出 Codex 单独把 Windows Sandbox 跑一遍。只要沙箱能独立打开，Codex 这边的初始化大概率会顺利通过。如果沙箱依然报错，那就扎到事件日志里，看系统的原话，少一点凭空猜测，多一点实际记录。
还有个小技巧是修完任何一层都记得重启一次，然后再测。虚拟化相关的组件变化，很多都要重启后才能完整生效，跳过重启直接测试，结果往往会误导你走许多弯路。把这几个要点把握住，Windows 沙箱初始化失败这个问题，基本就是一次性的“系统体检”而已。
