Codex Windows 沙箱启动失败：一次由 WSL 迁移导致的 Git 权限问题排查
最近我把一个原本在 WSL Ubuntu 中开发的 Git 项目迁移到了 Windows，随后遇到了一个比较隐蔽的问题：
Codex 的 Windows 沙箱无法初始化，本地命令无法正常执行，连浏览器控制也一起失效。
最开始看起来很像是 Codex 或浏览器控制本身出了问题，但最后发现，真正的根因其实是：
从 WSL 迁移到 Windows 后，项目
.git目录的 Windows 所有权和 ACL 权限异常，导致 Codex Sandbox 无法重新配置目录权限。
这篇文章记录一下完整的定位过程和解决方法。
1. 故障现象
最早是在让 Codex 控制浏览器时遇到错误：
node_repl kernel exited unexpectedly
windows sandbox failed:
helper_unknown_error:
setup refresh had errors
重新初始化之后依旧失败：
trusted Node process exited unexpectedly
不仅浏览器控制不能使用，普通的 Codex 本地命令执行也受到影响。
这说明问题很可能并不在浏览器，而是在更底层的 Windows Sandbox 初始化阶段。
2. 从 Sandbox 日志找到真正错误
继续检查 Codex 的 Sandbox 日志：
C:\Users\<username>\.codex\.sandbox\
日志中出现了更关键的信息：
deny ACE failed
open deny ACL target for update
并且失败路径明确指向：
F:\work\mycode\.git
也就是说，Codex 在初始化 Windows Sandbox 时，尝试调整 Git 目录的 Windows ACL 权限，但无法修改 .git。
外层最终只显示了比较笼统的：
setup refresh had errors
真正的错误实际上发生在前面的 ACL 设置阶段。
3. 检查 .git 所有权
进一步检查项目目录：
Get-Acl F:\work\mycode
Get-Acl F:\work\mycode\.git
结果发现：
项目目录 Owner：
<Windows用户>
.git Owner：
CodexSandboxOffline
这明显不正常。
CodexSandboxOffline 本身并不是恶意账户，它是 Codex Windows Sandbox 使用的低权限本地账户之一。
问题在于：
项目属于当前 Windows 用户，而
.git却被另一个 Sandbox 用户持有。
这会同时影响 Windows ACL、Git 的仓库安全检查以及 Codex Sandbox 的权限刷新。
4. 为什么会发生
这个项目之前是在 WSL Ubuntu 中开发的，后来直接迁移到了 Windows 文件系统。
Linux 与 Windows 的权限体系完全不同：
Linux 主要使用：
uid / gid
rwx
Windows 则使用：
Owner
ACL
ACE
两者并不能简单一一对应。
在 WSL 与 Windows 文件系统之间复制或移动项目时，尤其是包含 .git 这样的特殊目录，有可能最终形成异常的 NTFS Owner 或 ACL。
之后 Codex Sandbox 再尝试给 .git 设置保护权限，就触发了：
.git 权限异常
↓
Codex 设置 deny ACE 失败
↓
Sandbox refresh 失败
↓
Node / command runtime 无法启动
↓
浏览器控制一起失效
所以浏览器只是被连带影响，并不是浏览器本身坏了。
5. 普通修改 Owner 也失败
一开始尝试直接修改所有者：
icacls ".git" /setowner "$me" /T /C
结果整个 .git 都返回：
拒绝访问
包括：
.git\config
.git\HEAD
.git\index
.git\objects
.git\refs
这说明当前 Windows 用户甚至已经没有足够权限修改 .git 的 Owner。
这种情况下不能继续用普通 PowerShell，需要管理员权限。
6. 最终解决方法
首先完全退出 Codex。
然后打开：
PowerShell / Windows Terminal → 以管理员身份运行
确认当前终端具有管理员权限：
([Security.Principal.WindowsPrincipal] `
[Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(
[Security.Principal.WindowsBuiltInRole]::Administrator
)
应该返回：
True
进入仓库目录：
cd F:\work\mycode
第一步：夺回 .git 所有权
takeown /F ".git" /A /R /D Y
这会让本机 Administrators 组先接管 .git 及其子目录。
第二步：恢复当前用户权限
获取当前 Windows 用户：
$me = whoami
然后给当前用户完全控制权限：
icacls ".git" /grant:r "${me}:(OI)(CI)F" /T /C
其中：
F = Full Control
OI = 文件继承
CI = 子目录继承
第三步：把 Owner 改回当前用户
icacls ".git" /setowner "$me" /T /C
最后验证：
(Get-Acl ".git").Owner
Owner 应该重新变成当前 Windows 用户。
再执行：
git status
确认 Git 仓库本身正常。
7. 修复结果
完成上述操作后重新启动 Codex。
结果：
- Windows Sandbox 恢复正常
- Codex 可以正常执行本地命令
- Browser / Computer Use 恢复
- 可以正常控制浏览器
- Git 仓库也恢复正常
因此最终可以确认：
故障并不是 Codex 浏览器控制问题，而是
.git目录异常的 NTFS Owner / ACL 导致整个 Codex Sandbox 初始化失败。
8. 不建议直接重置整个项目权限
排查过程中很容易想到执行：
icacls F:\work /reset /T
但不推荐这样做。
因为这会递归修改整个开发目录的 ACL，影响范围过大。
更安全的策略是：
先定位具体失败目录
↓
只处理 .git
↓
先 takeown
↓
恢复当前用户访问
↓
恢复 Owner
遵循最小修改原则，可以避免把原本正常的权限一起破坏。
9. WSL 项目迁移到 Windows 的建议
这次问题还有一个比较重要的经验：
不要直接把完整 Git 工作目录从 WSL 搬到 Windows。
特别是以下目录：
.git
.venv
node_modules
Docker Volume
PostgreSQL Data Directory
都不适合直接跨环境复制。
更推荐：
Git
WSL：
git add .
git commit
git push
Windows：
git clone ...
让 Windows 自己创建 .git。
Python
不要迁移：
.venv
在 Windows 重新创建：
python -m venv .venv
pip install -r requirements.txt
Node.js
不要复制：
node_modules
重新执行：
npm install
或者：
pnpm install
PostgreSQL
不要直接复制 PostgreSQL 数据目录。
使用：
pg_dump
pg_restore
进行迁移。
总结
这次问题表面上表现为：
Codex 无法执行命令
浏览器控制失败
Windows Sandbox 初始化失败
但真正的根因其实是：
WSL → Windows 项目迁移
↓
.git Owner / ACL 异常
↓
Codex Sandbox 无法更新 ACL
↓
setup refresh failed
最终通过管理员 PowerShell 执行：
takeown /F ".git" /A /R /D Y
$me = whoami
icacls ".git" /grant:r "${me}:(OI)(CI)F" /T /C
icacls ".git" /setowner "$me" /T /C
恢复 .git 的 Windows 权限后，整个 Codex Sandbox 和浏览器控制都恢复正常。
如果以后需要把开发环境从 WSL 切换到 Windows，最稳妥的原则其实很简单：
源代码可以迁移，但 Git 元数据、依赖环境和数据库数据尽量通过各自的标准方式重新生成或导入，而不是直接复制整个目录。