codex-windows-fast-patch

Codex Windows Fast Patch

当用户提到 Codex Desktop 升级后 Fast Mode / Plugins / Goal 补丁消失，要求在 Windows 上重新为 Codex 打补丁，要求确认是否确实发送了 Fast Mode，要求恢复或注册本地插件市场，要求在 Codex Desktop 中启用 Chrome 浏览器使用或 Windows Computer Use，或要求在保留第三方/API 密钥模型访问的同时启用或修复手机远程控制时，使用此技能。以下情况也使用此技能：自定义提供商或 /v1/models 已公开新模型，但 Desktop 仍将其隐藏；GPT-5.6 Sol/Terra/Luna 未出现在模型选择器中；由于 Statsig 的 available_models 筛选移除了必需的模型组合，紧凑的蓝紫色 Power 滑块退回到旧版 Model / Reasoning / Speed 菜单；或者由于第三方提供商无法加载 ChatGPT 账户用户设置，"Ultra in model picker slider" 设置可见但处于禁用状态。以下情况同样适用：语言/区域设置在重启后恢复原状；可用性门控隐藏了浏览器或插件条目；Computer Control 设置页面显示 "Any App" / "任意应用" 处于禁用状态，原因是组织限制或当前区域不可用；Computer Use 任务报告原生管道、捆绑插件缓存、辅助程序路径、包导入或运行时初始化错误；Computer Use 对话中 cua.getApp / cua.listApps 不见了，但 cua.getState() 和原生管道仍正常工作，且每次 Desktop 重启后都会再次出现此问题；Computer Use 调用失败并显示 Native app bindings are unavailable for windows.，或在应用内浏览器标签页上超时，但 cua.computer.list_windows() 仍正常工作；手机远程控制二维码配对一直转圈或失败；配对后由手机发起的轮次请求了错误的模型 API 端点；Desktop 新建聊天/线程失败并显示 missing field inputSchema；切换 model_provider / API 账户后本地对话消失；恢复的对话可见，但由于缺少当前工作目录而无法继续；或者用户明确要求配置捆绑的自定义 model_instructions_file 提示词资源。

平台兼容性

此技能仅适用于 Windows。它依赖 Windows Store/MSIX 软件包布局、PowerShell、Get-AppxPackage、makeappx.exe、signtool.exe、Windows 用户环境变量以及 Windows Computer Use 辅助程序路径。

不要在 macOS 上运行此技能。适配 macOS 需要为 Codex .app 捆绑包、ASAR 提取与重新打包、macOS 代码签名或隔离属性处理、shell 脚本以及 macOS 专用的 Computer Use 可用性另行制定工作流。

技能根目录

本文档中的每条命令都将技能目录称为 $SkillRoot。运行任何其他操作前，请在每个会话中先解析一次。此技能不关心加载它的 harness，因此探测命令会匹配任何遵循 ~/<agent-home>/skills/<skill-name> 布局的 Agent 主目录：

$SkillRoot = $env:CODEX_WIN_FAST_PATCH_SKILL_ROOT
if (-not $SkillRoot) {
  $SkillRoot = (Get-ChildItem -Force -Path "$env:USERPROFILE\.*\skills\codex-windows-fast-patch\SKILL.md" -ErrorAction SilentlyContinue |
                Select-Object -First 1).Directory.FullName
}
if (-not $SkillRoot) {
  throw 'skill root not found; set CODEX_WIN_FAST_PATCH_SKILL_ROOT to the directory that holds this SKILL.md'
}

如果 Agent 已知加载此 SKILL.md 的目录，请直接将该路径赋值，而不要进行探测。如果多个 harness 都安装了此技能，请设置 CODEX_WIN_FAST_PATCH_SKILL_ROOT 来明确选择一个；否则，探测会使用第一个匹配项。

自更新前检查

技能目录是一个 git 工作树，因此更新操作是 git pull。先运行快速检查；如果没有变化，就跳过其余步骤：

git -C "$SkillRoot" fetch --quiet origin
git -C "$SkillRoot" rev-list --count 'HEAD..@{u}'

保留 'HEAD..@{u}' 的单引号。PowerShell 会将未加引号的 @{u} 解析为哈希表字面量，在 git 运行前就报错。这里的 HEAD..origin/HEAD 效果相同，且不需要加引号。

计数为 0 表示技能已是最新版本：跳过更新并开始任务。若计数非零，则先查看实际变更内容，再拉取更新，然后重新加载此 SKILL.md：

git -C "$SkillRoot" log --oneline 'HEAD..@{u}'
git -C "$SkillRoot" pull --ff-only

如果 @{u} 报告未配置上游，请明确指定跟踪引用，例如 HEAD..origin/main。

规则：

• 绝不要因更新而阻塞修复。当 fetch 因网络不可用、无法访问 GitHub 或代理宕机而失败时，请继续使用已安装的版本，并在结论中说明跳过了更新。
• 本地编辑由 git 保留，不会被静默丢弃。拉取前，使用 git -C "$SkillRoot" status --short 和 git -C "$SkillRoot" diff 检查。对更新未涉及文件的未提交编辑会在 git pull --ff-only 后原样保留。对更新也会修改的文件所做的未提交编辑会导致 git 拒绝拉取、指出阻塞文件，并将编辑保留在磁盘上；可使用 git stash、git pull --ff-only、git stash pop 恢复，并注意当本地编辑与上游变更涉及相同行时，stash pop 可能留下冲突标记。本地提交会导致分支分叉，--ff-only 因而拒绝拉取；git pull --rebase 会将这些提交重放到更新之上。绝不要使用 git reset --hard 或 git checkout -- . 强行完成拉取，因为本地辅助配置文件和修复保护措施都保存在这些编辑中。
• Fork 只是不同的远程仓库。git -C "$SkillRoot" remote set-url origin <fork-url> 可固定更新源，无需涉及额外的配置文件。
• 使用 git 回滚。运行 git -C "$SkillRoot" log --oneline -10，然后执行 git -C "$SkillRoot" checkout <sha>，即可返回任意较早版本。
• 补丁步骤失败时，请在得出结论前再次检查更新。辅助配置文件缺失、模式不再匹配或 Desktop 版本无法识别，恰好都可能是上游已包含修复的情况；因此即使任务开始时已检查过，也应在此时重复执行 fetch 和日志检查。
• 如果 $SkillRoot 没有 .git 目录，则此副本是通过复制文件或 harness 插件机制安装的，无法自行更新。请报告这一情况，继续使用已安装的版本，并建议通过 git clone 重新安装，以便今后更新。

如果常规工作流无法说明某项限制、插件门控、Computer Use 故障、browser_use 故障或 Fast Mode 故障，请在编辑脚本或重新应用补丁前阅读 references/restriction-debug-cases.md。 对于浏览器 AX 的 Decompression failed，请使用该参考文档中的 AX 资源案例。对于缺失的 CUA 子进程代理变量，请先使用其中的只读进程探测，再选择启用 -OnlyNodeReplProxyEnv 或 -OnlyComputerUseSurfaceAndProxyEnv 修复；仅仅缺少根进程代理设置并不足以证明需要修改软件包。 如果任务涉及手机远程控制、二维码配对、移动端设置、隔离的远程 OAuth、远程控制 WebSocket 或配对后的 API 端点诊断，请在编辑脚本或重新应用补丁前阅读 references/remote-control-debug-cases.md。

配置备份规则

在执行任何可能修改、重新生成或覆盖 $env:USERPROFILE\.codex\config.toml 的操作前，为当前任务中的现有文件创建一份带时间戳的备份。无论 Agent 使用内置脚本、手动编写 TOML、运行其他辅助程序、注册市场、更改 MCP 服务，还是修复 Computer Use，都适用此规则。

内置脚本会在每次运行时、首次写入前，为现有的 config.toml 备份一次。如果不使用这些脚本，请在操作文件前明确创建备份：

$config = Join-Path $env:USERPROFILE '.codex\config.toml'
if (Test-Path -LiteralPath $config -PathType Leaf) {
  $backupDir = Join-Path (Split-Path -Parent $config) 'backups\config'
  New-Item -ItemType Directory -Force -Path $backupDir | Out-Null
  $backup = Join-Path $backupDir ('config.toml.' + (Get-Date -Format 'yyyyMMdd-HHmmss-fff') + '.manual.bak')
  Copy-Item -LiteralPath $config -Destination $backup -Force
  Write-Host "config.toml backup before overwrite: $backup"
}

如果现有配置备份失败，请勿继续写入配置。共享 TOML 写入器在值包含撇号或控制字符时会使用基本字符串；连续两个撇号不是有效的 TOML 转义方式。如果有 tomllib，请在替换配置前验证候选内容，并在完整修复后再次验证。即使 $OutputEncoding 不带 BOM，Windows PowerShell 5.1 仍可能在原生 stdin 前加上 UTF-8 BOM；请使用 utf-8-sig 解码验证器输入，以免错误地拒绝有效内容。这种传输处理不会改变无 BOM 文件写入器的行为，也不会改变对格式错误 TOML 的拒绝方式。缺少解析器是工具限制，并不代表配置无效。

工作流选择

在选择完整的 MSIX 重新打包路径前，请先判断当前故障属于 Desktop 捆绑包门槛问题，还是本地插件／运行时修复问题。不要仅凭含糊的“Chrome／Computer Use 不可用”报告，就认定有足够证据运行完整的重新修补流程。

• 对于 Fast Mode 请求／界面故障、Desktop 选择器中不显示新模型、紧凑型 Power 滑块回退到旧版选择器，或自定义提供商下 Ultra 设置被禁用，请使用 Model Experience 工作流。这些症状都涉及同一服务层级／模型选择器区域。先运行 scripts\patch_codex_fast_mode_windows_msix.ps1 -OnlyModelExperience -DryRun；它会分别检查 Fast 请求门控、Fast 界面门控、模型可见性筛选器、Electron Power 滑块 harborEnabled 门控和 Ultra 设置持久化，然后在一次 MSIX 重新打包中仅修复有问题的部分。Ultra 回退方案会保留正常的 ChatGPT 账户 API 路径，并且仅在无法加载 ChatGPT 用户设置时使用本地 show-ultra-in-model-picker-slider 配置。-OnlyCustomModels 仍是兼容性别名。只有只读检查证实缓存条目缺失时，才将缺失的模型元数据合并到 models_cache.json；请先备份缓存。同一区域还涵盖以下情况：当官方目录为 gpt-5.6-sol 添加第二个 ultrafast 层级，而自定义 model_catalog_json 早于该层级时，模型选择器只提供 Fast 速度层级。这属于配置层目录回填，而非 ASAR 修复——请参阅 references/restriction-debug-cases.md 中的缺失 Ultrafast 层级案例。
• 对于语言环境、插件界面门控、browser_use Desktop 门控、Goal 门控、ASAR 完整性、设置／界面可用性门控，或需要在修复这些功能的同时修复 Model Experience 时，请使用完整重新修补工作流。
• Store 更新后进行完整重新修补前，请比较当前用户和 Get-AppxPackage -AllUsers 的结果。修补程序会选择版本最高的有效当前用户或 SYSTEM-Staged 程序包，以及正在运行的进程候选项；仅当所有用户查询不可用时，才会使用 WindowsApps 目录候选项。这样可以避免较旧的用户安装程序包遮蔽较新的 SYSTEM-Staged 版本，同时不会选择仅向其他用户注册的程序包。继续前请检查 selected Codex app 日志。仅在需要明确覆盖源时才使用 -AppPath。
• 如果证据表明问题出在本地插件／运行时，请先使用 Computer Use Only 工作流：例如 codex plugin list 市场错误、缺少 .agents\plugins\marketplace.json、openai-bundled 插件文件缺失或不完整、bundled_plugins_marketplace_resolve_failed、捆绑插件文件出现 EBUSY、原生管道不可用、missing-helper-path、Chrome 原生消息主机路径过时、捆绑插件缓存漂移、Chrome／浏览器缓存链接漂移、SKY_CUA_NATIVE_PIPE 配置过时、@oai/sky 导入错误，或 setupComputerUseRuntime 导入失败。此类问题不需要卸载／重新安装 MSIX，除非后续检查也证实某个 Desktop 门控仍处于关闭状态。
• 如果 Store 更新导致已配置的 MCP 出问题，原因是其 command 指向已删除的 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<old-runtime-id> 目录，请使用 references/restriction-debug-cases.md 中已退役的 CUA Node MCP 案例。这是针对性的 config.toml 修复，不能作为大范围重新修补 MSIX 的依据，也不代表可以安装其他 MCP 服务。
• 如果应用／窗口枚举正常，但 Windows 10 上截图因 SetIsBorderRequired failed／0x80004002 或 FrameArrived timed out 而失败，请将其视为原生 CUA 截图助手兼容性故障，而非缓存路径或 Desktop 门控问题。捕获失败后可能继而出现 coordinate input geometry is unavailable；请先修复并验证截图捕获，再重新测试坐标输入。阅读 references/win10-computer-use-screenshot-backend.md，然后仅在只读状态报告的哈希与其明确支持的原始或已修补哈希完全一致时，才使用 scripts\patch-computer-use-helper-win10.ps1。遇到未知哈希时必须重新分析，并保持不变。
• 如果 sky.list_windows() 成功，但后续独立调用 sky.get_window_state() 或 sky.activate_window() 失败并显示 node_repl exec context not found，请阅读 references/restriction-debug-cases.md 中的跨调用审批案例。对于文档明确记载的 @oai/sky 0.6.2 助手传输机制，持久助手的审批回调可能会继承上一次 JavaScript 调用的 AsyncLocalStorage 存储。install-computer-use-local.ps1 -VerifyOnly 会应用受哈希保护的请求上下文补丁；-StrictVerifyOnly 只进行验证。修复后重置当前 JavaScript 内核，然后在后续独立调用中通过实际截图证明修复有效。
• 仅当自定义 model_provider 下 MCP 工具或 Computer Use 不可用时，使用 Custom Provider Tool Exposure 分诊：Agent 报告的 MCP 工具名称为零，但同一台机器和配置在 -c model_provider=openai 下会显示所有 MCP 工具。在操作 Desktop 前，通过本地日志反向代理捕获真实的提供商请求正文，并检查 /models 响应格式：如果网关返回 OpenAI 列出模型的格式（{"data":[...]}），目录解码会失败（missing field \models`），并回退到 supports_search_tool: false的模型元数据，使线缆格式固定为namespace 条目；在观察到的调用链中，namespace和tool_search格式均未生效，尽管 HTTP 状态为 200——这一结果本身无法区分是网关过滤，还是上游或模型端忽略了这些格式。除非通过受控原始请求探测或网关入站／出站对比证明，否则应将丢弃请求的环节（网关过滤还是模型端拒绝这些格式）视为未经验证；绝不可将模型口头报告的工具情况作为证据。文档所述的 MSIX 重新修补和 Computer Use 本地修复均无法解决此类故障——请参阅references/restriction-debug-cases.md` 中的自定义提供商调用链案例。
• 如果 cua.getState() 正常，但 Object.keys(cua) 中没有 computer／getApp／listApps／listWindows，而 install-computer-use-local.ps1 -StrictVerifyOnly 通过，请使用 CUA surface lock 案例。先检查插件布局：基于脚本的 unified-computer-use/scripts/launch.mjs 可以使用 repair-cua-surface-lock.ps1；仅含描述符的 26.908+ 插件没有此类目标，必须在 DryRun 成功后使用 Desktop -OnlyComputerUseSurface ASAR 工作流。编辑物化后的 .mcp.json 只是临时解决办法，因为 Desktop reconcile 可能会重写它。请参阅 references/restriction-debug-cases.md 中的两个 surface 案例。
• 仅当已安装的 @oai/cua 运行时在 surface 暴露后确实抛出 Native app bindings are unavailable for windows. 时，才使用 Windows app-binding 案例。记录在案的旧版运行时有此限制；@oai/cua 0.2.5 则提供 Windows cua.listWindows() 和 cua.getApp({ windowId })。选择旧版修复方案前，请检查已安装的运行时及其注入文档，并在新的对话中验证原生截图捕获。
• 如果提供商切换器重写 config.toml，导致 codex mcp list 中的 cua_repl 消失，请使用 config-rewriter 案例：从备份恢复缺失的 [plugins."unified-computer-use@openai-bundled"] 表，同时保留当前提供商设置。恢复功能键前，请使用正在运行的 CLI 执行 codex features list 来评估这些键。在 CLI 0.155.0-alpha.16.4 上，computer_use 已稳定并默认启用，js_repl 已移除，而且无需显式配置 computer_use 条目、并将 js_repl = false 时，原生 CUA 也能正常工作；这些值本身并非缺陷。请参阅 references/restriction-debug-cases.md 中的历史 config-rewriter 案例。
• 当用户需要移动设备配对／控制、Connections 页面隐藏手机设置卡片、二维码对话框一直转圈、远程控制设置跳转到 ChatGPT 身份验证、允许对话框失败、手机提示 Codex 环境版本已过期，或手机创建的回合到达 Desktop 后却向错误的 API 端点发送模型请求时，请使用 Phone Remote Control 工作流。
• 当 Codex Desktop 无法创建新对话或本地任务，且最新的 Desktop 日志显示 method=thread/start 并包含短语 missing field inputSchema 时，请使用 Missing inputSchema 决策工作流。不要假设这总是 MCP 问题。先对比 CLI／app-server 冒烟测试与 Desktop 日志，并检查 Desktop 是否发送了非空的应用动态工具。如果故障随某个可疑 MCP 服务出现，请隔离 MCP。如果 CLI 线程启动成功，而 Desktop 界面失败，并且提取的 ASAR 中 webview\assets\app-server-dynamic-tools-*.js 返回带命名空间封装的 dynamicTools 对象，请使用 Dynamic Tools Schema 工作流。除非另有独立证据指向 Phone Remote Control 或 Computer Use，否则不要针对这一症状运行相关修复。
• 当用户更改 model_provider、API 账户或提供商配置后，官方 Desktop 侧边栏中的旧对话消失，但本地仍有 sessions、archived_sessions 或 state_5.sqlite 数据时，请使用 Provider History Sync 工作流。当对话重新出现，但打开／继续对话时因缺少历史 cwd 而出现 当前工作目录缺失、current working directory missing 或 invalid codex request，也请使用此工作流。这是数据层修复；不需要第三方恢复工具，不会修补 ASAR，也不得修改 config.toml。
• 当最新的 Desktop 日志显示的描述符少于当前程序包市场中的描述符，或显示 not_in_bundled_marketplace_plugin_names 移除了用户已安装的插件时，请使用针对性的捆绑市场修复。描述符存在意味着插件可用，并不授权安装或启用 sites、latex、deep-research 或 visualize 等可选插件。这不应触发大范围重新修补或 Phone Remote Control 工作流。请先检查完整的缺失描述符判断条件和平台支持情况。记录在案的 26.825.6671.0 仅支持 macOS 的统一 CUA 和通过账户身份验证的 user-writing 缺失情况均属预期行为；请保留这些边界。受支持的 26.1007 Code Review 和统一 CUA 发现判断条件，则使用 references/restriction-debug-cases.md 中较新的可选条目案例，并设置 installWhenMissing:false。未知账户判断条件仍不受支持。
• 如果用户在同一次修复中同时要求 Phone Remote Control 和普通 Desktop 功能，请先修补 Phone Remote Control，再验证 Fast Mode／browser／Chrome／Computer Use。如果远程控制的 MSIX 安装影响 Computer Use 或 Chrome 原生主机状态，请立即运行 Computer Use Only 工作流，并再次运行 -StrictVerifyOnly。
• 不要因出现新的 resources\codex.exe PE 文件，就推断 app.asar 已消失或 Computer Use 需要二进制修补。请先检查当前程序包资源。如果 app.asar 仍存在，且症状是插件／运行时导入或缓存故障，请先运行 scripts\install-computer-use-local.ps1，再考虑 MSIX 或二进制更改。
• 每次仅修复 Computer Use 后，都必须运行 scripts\install-computer-use-local.ps1 -StrictVerifyOnly。旧版布局通过条件为 client import ok 加 helper transport ok；仅含描述符的布局在导入官方 sky 导出并调用 list_windows 后，以 runtime import ok 为通过条件。对于已识别的跨调用请求上下文配置，严格验证还必须报告完全匹配的已修补助手传输哈希。这些检查仍不能替代后续 JavaScript 调用中的实际截图。
• 除非用户提出要求，否则不要将 Phone Remote Control 纳入默认的完整重新修补流程。它是可选工作流，因为可能需要隔离的远程控制 OAuth、ASAR 更改、原生 app-server 替换二进制文件、SQLite 注册清理，以及配对后的 API 端点诊断。
• 如果证据不明确，请先采用影响最小的处理路径：运行只读分诊；然后，对于本地插件问题，运行 scripts\install-computer-use-local.ps1 -VerifyOnly；仅在必要时重启 Codex Desktop；只有当日志或提取的 ASAR 检查仍显示某个门控处于关闭状态时，才升级到 MSIX 修复。 常规的 scripts\repatch-codex-windows.ps1 预检会识别一种由软件包限制导致的 Computer Use 情况：installed app.asar does not preserve external NODE_REPL_TRUSTED_CODE_PATHS across Desktop config regeneration。这意味着必须先重新修补已安装的应用，外部 D: 市场／缓存根目录才能在 Desktop 配置重新生成后保留。仅针对这条确切消息，包装脚本会记录回退情况，并继续进行 MSIX 演练运行或安装；其他 Computer Use 故障仍会中止工作流。安装后，包装脚本会执行常规的 Computer Use 刷新和严格验证。演练运行期间，仅当识别到这种情况时才会跳过演练后的本地验证，因为当前已安装的软件包仍有意保持未修补状态。

当 Chrome 会话／标签命令或 cua.getState() 的浏览器部分在明确使用非 OpenAI 身份验证的自定义提供程序时报告 Codex auth token is unavailable，请阅读 references/restriction-debug-cases.md 中的 Chrome 自定义提供程序请求标头案例。受支持的本地服务叠加层会保持 Agent 请求标头开启；它不会伪造登录、修改提供程序／身份验证文件、禁用其他策略或修改受信任的浏览器客户端字节。本地安装程序会在缓存刷新后重新应用受哈希校验保护的叠加层。修复和严格验证都会检查浏览器／Chrome 插件副本，以及当前 cua_node 运行时的 @oai/browser-desktop/service，并分别与各自已安装软件包的源文件进行比对。对于未知的官方源哈希，程序会明确仅跳过此叠加层，不会声称已修复身份验证错误；如果当前运行时服务缺失，或受支持源下的文件未知、版本混杂或不完整，则会在写入任何叠加层之前失败。应用后，只需重置当前 JavaScript 内核，并验证 Chrome 的实际导航和输入；遇到此错误时不要重新安装 Desktop。

用于会重启 Desktop 的修复的外部执行器

MSIX 部署必须采用就地更新，绝不能先卸载再安装。所有三个修补程序都会递增软件包修订号，并使用 scripts/lib/msix-safe-install.ps1。部署前，它会检查清单、发布者、体系结构、签名、版本、打包服务所需的管理员权限以及安装程序的进程祖先关系。权限错误或同版本错误必须中止操作，不得关闭或移除仍可正常工作的应用。不要为了绕过更新失败而恢复 Remove-AppxPackage 回退方案。

从 Desktop 启动的 Start-Process 仍可能属于 Desktop 的作业／进程树，并随 Desktop 一起终止。在放行安装之前，请验证外部执行器的进程祖先关系和用户会话。声明了 windows.service、packagedServices 或 localSystemServices 的软件包需要提升权限的执行器；有效签名并不能证明拥有部署权限。在关闭任何应用之前，请取得正常的 Windows UAC 同意，并验证提升后的令牌。在实际启动和运行时验收通过之前，请保留一个单独签名的恢复软件包，其中包含原始程序文件，且其修订号高于预期更新。常规修补程序入口点不会自动创建此恢复软件包；外部执行器准备好该软件包并提供实际启动验证后，可使用 Invoke-RecoverableMsixInstall。请参阅 references/restriction-debug-cases.md 中的部署失败案例。

当前 Codex Desktop 对话可以发起、诊断、准备并协调自身修复。实际部署若会关闭或更新 Desktop，则必须由独立安装程序执行，且须已验证其进程祖先关系和用户会话能够在 Desktop 关闭后继续运行。这是安装程序生命周期要求，并不要求用户离开当前对话。外部 Windows PowerShell 或 VS Code Codex 扩展也可以作为有效的启动入口。 在发布安装前，请说明哪些请求的修复需要重新安装客户端，并告知用户窗口可能会关闭，从而中断对话。备份状态，并保存交接信息，其中应包含已验证的制品和备份路径、安装程序 PID／状态文件位置，以及尚未完成的验收步骤。告知用户安装完成后重新打开 Codex，并在原修复对话中发送“continue”。恢复对话后，先检查现有安装程序和已保存的结果：如果仍在运行，则等待；如果失败，则诊断；如果安装成功，则继续验收和清理。不要仅仅因为对话中断，就启动重复的安装程序或重复已完成的部署。报告安装错误，或安装完成后应用仍缺失／无法启动，都不属于正常等待情况。

目标状态是桌面版 Codex 主目录，通常为 $env:USERPROFILE\.codex。不要使用独立的 CLI 入口点来决定桌面版修复方案；如果该包装器将 CODEX_HOME 设为 $env:USERPROFILE\.codex-cli 或其他隔离目录，那么其中的状态并非桌面版插件、市场、MCP、远程控制或登录状态。

从 VS Code Codex 或外部 PowerShell 启动前，请确认用户级或计算机级均未设置 CODEX_HOME。不要设置全局 CODEX_HOME，不要将 .codex 复制到 .codex-cli，也不要暴露或提交 auth.json、API 密钥、OAuth 令牌、MCP 凭据、浏览器配置文件或本地凭据存储。先备份桌面版状态，执行只读的软件包／配置／日志检查，然后运行相关的 -DryRun。只有在试运行找到并验证预期目标后，才使用 -Install、完整的 repatch-codex-windows.ps1，或带有 -Install -Launch -InstallPrerequisites 的定向 *-windows-msix.ps1。

重新启动后，请使用以下后台验证。实际的原生截图／输入测试属于可单独授权的诊断；普通修复完成时，即使未执行该测试，也不得因此阻止完成。外部执行器可使用官方运行时进行只读枚举，但无法替代桌面版可信的 Chrome／浏览器通道。应根据实际收集到的证据，分别报告各层状态。有关桌面版之外明确请求的原生交互诊断，请参阅 references/restriction-debug-cases.md 中的外部执行器案例。

默认不进行桌面输入验证

常规修复、升级和“验证所有功能”请求默认使用后台检查。不要打开计算器、记事本、任务管理器或其他测试应用；不要激活、还原、移动或关闭原生窗口；也不要仅为演示修复有效而发送点击、滚动、拖动或键盘输入。不要用其他应用或外部进程输入驱动程序替代同样具有侵入性的测试。

• 运行 scripts\install-computer-use-local.ps1 -StrictVerifyOnly -VerifyAllBundledPluginsAvailable。它会检查当前软件包／缓存／运行时契约、浏览器 AX 资源、原生主机配置、受信任路径，以及真实辅助程序的 list_windows 响应，不会选择应用或注入输入。
• 如果需要检查全新的桌面 CUA 界面，请使用其文档化 API 检查可用成员，并且只枚举窗口／应用。报告数量和 API 可用性，不要泄露无关的窗口标题。枚举成功表示传输可用；窗口列表为空本身并不能证明失败。
• 视情况继续进行软件包完整性、插件发现、沙箱和 Fast 请求线路检查。用户请求的浏览器检查可以通过 Browser Use 使用临时后台标签页；浏览器输入成功并不能证明原生 Windows 输入成功。
• 除非确实测试过这些操作，否则原生结果应报告为 runtime/transport verified; native screenshot/input not exercised。不要自动升级为交互式测试，以此将这一限制包装成更宽泛的成功声明。

如果确实需要复现截图或输入缺陷，请先说明目标窗口、操作和可能发生的焦点变化，然后取得对该诊断的明确授权。用户已明确要求执行相同操作时，即视为已授权；不要再次询问。条件允许时，优先使用一次性 VM／测试桌面，或选择用户指定的空闲时段；绝不要假设隐藏／屏幕外窗口能让 Windows 输入注入变得无干扰。本技能及其参考文档其他位置所述的可选实时检查也遵循此界限。

如果用户按下 Escape、停止 Computer Use、关闭测试窗口，或恢复对目标的操作，请停止交互式测试并报告最后完成的步骤。不要自动重新打开测试应用、重试输入或切换到其他控制机制。无需再进行桌面输入，也可以完成后台检查和修复报告。

对于从 Windows 11 主机调查的 Windows 10 截图问题，请遵循 references/win10-validation-on-win11.md。默认情况下，scripts\diagnose-win10-helper-capture.ps1 为只读；-BuildTargetOnly 只会编译专用目标，不会启动它。获得明确授权的 -RunCapture 会使用 Windows 10 来宾／测试控制台、隔离的辅助程序副本和一次性 Codex 主目录。-TestInput 单独用于选择是否执行仅限于该目标的点击／文本输入。该脚本会拒绝 Windows 11／Server 截图，也绝不会将补丁安装到活动辅助程序中。编译、候选项哈希和诊断保护测试并不能证明 Windows 10 截图已通过验收。

默认工作流

1. 如果任务可能修改 config.toml、技能、市场或 MCP 服务设置，请先创建状态快照：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action Backup

2. 检查当前用户和所有用户的软件包状态，以便发现更新的 SYSTEM-Staged Store 版本：

Get-AppxPackage -Name OpenAI.Codex | Select-Object Name,PackageFullName,Version,SignatureKind,InstallLocation
Get-AppxPackage -Name OpenAI.Codex -AllUsers |
  Select-Object Name,PackageFullName,Version,SignatureKind,InstallLocation,PackageUserInformation

即使当前用户查询返回较旧的已安装版本，MSIX 修补程序也会自动选择 app 布局完整的最高版本候选项。安装前，请确认日志中的 selected Codex app 和 source package 行。显式指定的 -AppPath 始终优先。

3. 在重新安装任何软件包之前，运行只读功能排查。记录判断依据，尤其是 Chrome／Computer Use 相关依据：

codex plugin list
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -StrictVerifyOnly

如果 -StrictVerifyOnly 因缺少 marketplace 清单、缺少插件文件、latest 链接过期、Chrome 原生消息传递清单路径过期、allowed_origins、注册表值或 extension-host-config.json 运行时路径有误、缺少辅助工具路径，或 @oai/sky 导入／运行时问题而失败，请先运行「仅限 Computer Use」修复：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -VerifyOnly

此本地修复可能会更新配置、插件缓存、Chrome 原生主机路径和来源、用户环境以及辅助工具运行时文件，但不会卸载或重新安装 Codex MSIX 软件包。它会调用当前 Chrome 插件的官方 scripts\installManifest.mjs，并使用用户本地的 Codex CLI（其哈希与已安装软件包匹配）以及路径匹配的当前 cua_node node.exe / node_repl.exe。该官方安装程序会写入外层原生主机清单、注册表值以及必需的 extension-host-config.json。修复还会使用当前插件的 NUL 分隔 SHA-256 身份契约，将当前 schema-2 app-server 条目同步到 %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json 和 $env:USERPROFILE\.codex\chrome-native-hosts-v2.json。严格验证要求来源集合与 scripts\extension-ids.json 中当前的精确集合一致，Chrome 缓存为稳定的当前版本缓存，主机配置中存在当前运行时路径，并且两个 v2 状态文件中均有有效的当前条目。在类似 26.814 的构建版本上，该条目必须在同一个稳定缓存中同时包含 browserClientPath 和 browserServicePath；省略服务路径虽然能通过字节检查，却会因受信任的 RPC 依赖检查而失败。如果稳定缓存通过联接点指向 CODEX_HOME 之外的位置，修复还会将其物理 marketplace／缓存根路径写入用户级 NODE_REPL_TRUSTED_CODE_PATHS。仍需完整的 MSIX 补丁，以便 Desktop 在重新生成 Node REPL 配置时追加该父级环境变量；对于这种外部根目录布局，严格验证要求已安装的 ASAR 中包含 CODEX_NODE_REPL_TRUSTED_PATHS_V1。

修复必须原样保留已安装软件包的 plugins\chrome\scripts\browser-client.mjs 字节。较早版本的 Node REPL 构建只有在导入的 browser-client SHA-256 与已安装 app.asar 中嵌入的信任列表匹配时，才会开放特权浏览器功能；重写 node:process 导入或进程 shim 会改变哈希，并导致 Chrome 发现前出现 Browser use requires privileged node_repl capabilities。Codex Desktop 26.814 则通过官方原生主机配置提供 browserClientPath，不再以 ASCII 格式将客户端哈希嵌入 app.asar。常规修复会将打包版本的字节恢复到稳定 marketplace 和带版本号的缓存中。严格验证要求这两个副本都与打包版本的 SHA-256 匹配，然后要求满足旧版 ASAR 哈希契约或完整的原生主机路径契约；未知或不完整的形态仍不受支持。

4. 在选择完整的 MSIX 重新打包之前，先检查这是否属于内置 marketplace 快速路径。将软件包的 .agents\plugins\marketplace.json 名称与 Desktop 协调日志进行比较。如果缺少描述符，或者 not_in_bundled_marketplace_plugin_names 移除了用户之前已安装的插件，请仅在大型本地驱动器上运行有针对性的内置 marketplace 补丁：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -DryRun -OutputRoot "<large-local-build-root>"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -Install -Launch -InstallPrerequisites -CleanupAfter -CleanupWindowsSdkAfterInstall -OutputRoot "<large-local-build-root>"

重新启动后，运行 scripts\install-computer-use-local.ps1 -VerifyOnly 和 scripts\install-computer-use-local.ps1 -StrictVerifyOnly -VerifyAllBundledPluginsAvailable。本地修复会保留每个无关可选插件的已安装／已启用状态，并且仅在某个可选插件原本已安装时刷新其缓存。可用性检查要求每个当前描述符的名称和版本都与已安装软件包匹配，并且在 CLI 的已安装或可用 JSON 中显示该版本；检查过程中不会调用 plugin add。 5. 仅当证据表明代码受 MSIX 包门控时，才升级到 MSIX：快速模式请求/界面门控、区域设置门控、目标/插件界面门控、reason=statsig-disabled 导致 browser_use 不可用、本地修复后仍因设置/界面可用性门控而禁用 Computer Use/Any App、ASAR 完整性失败、本地修复后物理目标仍被可信 RPC 依赖项门控拒绝的稳定 Browser 缓存联接，或 Phone Remote Control 包补丁。对于联接情况，必须先取得完整补丁程序的 Node REPL trusted-paths patch result，重启 Desktop，并确认重新生成的配置保留了解析后的外部根路径。否则，不要仅仅因为某个插件不可用就运行完整重新打补丁。

当有理由升级到 MSIX 时，每次 Codex 升级后都先运行试运行：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\repatch-codex-windows.ps1" -DryRun

6. 如果试运行发现所有补丁目标，则运行完整重新打补丁：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\repatch-codex-windows.ps1"

该封装脚本会使用以下默认参数调用内置补丁脚本 scripts\patch_codex_fast_mode_windows_msix.ps1：

• -InstallPrerequisites
• -Install
• -Launch
• -CleanupWindowsSdkAfterInstall
• -CleanupAfter
• -VerifyFastModeRequest 它还会验证并写入本地市场配置 $env:USERPROFILE\.codex\marketplaces\openai-curated-local，其中包括 source_type = "local" 和准确的 source 路径。 它还会将当前 Codex 程序包中的已安装 openai-bundled 市场同步到稳定的本地根目录，叠加本地 computer-use@openai-bundled 兼容插件，将该市场写入配置，并通过用户可访问的 Codex CLI 注册 browser@openai-bundled。传入 -VerifyAllBundledPluginsAvailable，即可为已安装程序包当前提供的每个完整描述符添加可用性断言，包括 deep-research 和 visualize 等依赖版本的插件。该断言本身使用 plugin list --available --json；它不会从网络下载内容、调用 plugin add，也不会更改无关的可选插件状态。外围包装器仍会执行所请求的修复或 DryRun 行为。当 .codex\.tmp 是联接时，会在联接目标旁创建稳定根目录，从而让现有的非系统盘布局继续留在 C: 盘之外；否则会使用 .codex\marketplaces\openai-bundled-local。它还会修复稳定的 browser / chrome 插件缓存副本，确保它们的 latest 联接不会指向可变的 .tmp 市场镜像，并为当前用户启用 CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1，以便桌面应用在重启后可以显示 Windows Computer Use。 它会同时修补请求路径和设置 UI 路径中的 Fast Mode。请求补丁会移除仅限 ChatGPT 的分支，同时仍读取主机/模型功能要求；UI 补丁会移除服务层级设置中相应的仅限 ChatGPT 可用性检查。 它还会强制让配置的自定义模型 ID 通过桌面端模型可见性筛选器。默认情况下，这些 ID 为 gpt-6-astra、gpt-6-sol、gpt-5.6-sol、gpt-5.6-terra 和 gpt-5.6-luna。此补丁只会取消隐藏当前版本中已存在的目录条目，不会创建条目。如果活动目录中不包含某个 slug，那么无论重新修补程序包多少次，它都不会出现在选择器中；因此，在将缺少模型视为补丁失败之前，请先确认该条目确实存在。CLI 内置目录嵌入在 codex.exe 中，其中可能包含尚未推出且设置了 "visibility": "hide" 的模型；这是该补丁处理的一种情况。用户的 model_catalog_json 会替换而非扩展此内置目录，因此必须自行包含新条目。当提供商公布了 gpt-6-sol 之类的新 slug 时，请先备份活动目录；如果内置目录中存在完整匹配条目，则将其导入；保留无关的模型设置，并在声称已修复目录之前验证 model/list。请勿推断其他模型的功能，也不要在未检查提供商的情况下声称内置模型受提供商支持。在包含紧凑型 Power 滑块的版本中，补丁还会开启 Electron 专用的 harborEnabled 开关，使相应的模型和推理组合使用该滑块，而非旧版仅包含模型/effort/speed 的菜单。 在 Ultra 滑块设置仅读取 ChatGPT 账户用户设置的版本中，它会为第三方提供商添加本地回退方案。此时，开关会在本地读取和写入 show-ultra-in-model-picker-slider，重启后仍会保留，并提供实际模型选择器使用的同一个 Ultra 包含值。通过 ChatGPT 进行身份验证的普通用户仍会使用官方账户设置路径。 它会修补区域设置 i18n 开关；当随附的 WebView 程序包中 enable_i18n 被禁用时，该开关可能会导致桌面 UI 在重启后恢复为英文。 它会同时修补 WebView 资源和 Electron 主进程功能发送器/接收器路径中的 Chrome/browser_use 开关，涵盖应用内浏览器、浏览器窗格和外部浏览器的可用性。这只会解锁本地桌面端开关；Chrome 扩展和原生消息传递文件仍需存在，并应单独验证。 它还会修补桌面 WebView 开关；这些开关原本会在 computer_use 功能和 Statsig 开关 1506311413 的控制下隐藏或禁用 Windows Computer Use。它还会将 features.computer_use = true 写入 $env:USERPROFILE\.codex\config.toml，而不会替换其余的 [features] 表。 它还会将 [windows] sandbox = "unelevated" 写入 $env:USERPROFILE\.codex\config.toml。在 Windows 上，这可以避免提升权限的沙盒设置刷新路径；该路径可能会因 spawn setup refresh / OS error 740 而失败，并导致 Computer Use 无法启动。 当本地根目录只有旧版根目录 marketplace.json 时，它还会修复本地市场清单布局；当前 Codex CLI 要求存在 .agents\plugins\marketplace.json，缺少此文件可能导致 codex plugin list 对所有已配置市场都失败。 默认情况下，它不会安装随附的自定义 model_instructions_file 提示词。只有在用户明确请求此可选配置时才安装。 随附脚本每次向现有 config.toml 写入内容前，都会在 .codex\backups\config\ 下为该脚本运行创建一个带时间戳的备份。

手机远程控制

修复手机远程控制前，请阅读 references/remote-control-debug-cases.md。明确以下边界：

• 远程控制配对/控制传输可以正常调用 https://chatgpt.com/backend-api/wham/remote/control/...。不要将该传输改写为第三方模型 API 端点。
• 手机配对成功后，验证实际的模型采样请求 URL。如果请求发往错误的模型 API 端点，应将其视为配对后的配置诊断，而不是远程控制配对实现的一部分。
• 远程控制 OAuth 是隔离的：使用 .codex\remote-control-oauth.json 和 .codex\remote.json；切勿在远程控制 bearer 注入路径中使用 .codex\auth.json。
• 用户要求不要占用系统盘时，必须使用备用构建根目录。在用户指定的大容量本地磁盘上传入 -WorkRoot / -OutputRoot，并将 Cargo、Rustup、临时文件、target、MSIX 和源代码检出目录都放在该根目录下。不要在工作流中硬编码盘符。

如果 Settings -> Connections -> Control this computer 可见，但设备列表提示需要重新登录 ChatGPT，请在再次修补 MSIX 前验证常规远程控制 bearer：

python "$SkillRoot\scripts\refresh-remote-control-auth.py" --verify-only

如果报告 remote_json_disabled、access_token_expired、endpoint_http_error、HTTP 401/403，或类似 refresh_token_reused 的令牌刷新诊断，请使用同一脚本仅重新生成 .codex\remote.json。该脚本使用官方 Codex OAuth 客户端，请求 openid profile email offline_access api.connectors.read api.connectors.invoke，将旧的 remote.json 备份到 .codex\backups\remote-control-auth，默认使用代理 http://127.0.0.1:10808，且不得写入 .codex\auth.json 或 config.toml。

如果 remote.json 验证成功，但点击 Add 或打开 Control this computer 后跳转回新的对话/主聊天页面，请检查 $env:USERPROFILE\.codex\remote-control-flow.log 和直接端点的结果，确认是否有已过期的 remote-control-oauth.json enroll 令牌遮蔽了常规 bearer。ASAR 修补器必须在返回隔离的 bearer 前跳过已过期的 JWT，并应在修补后的 ASAR 中验证 remote_control_auth_token_expired_skipped。不要贸然删除 .codex\remote-control-oauth.json；保留它以支持新的 step-up/enroll 流程，并让有效的 .codex\remote.json 满足 read/MFA 端点的要求。

如果 Allow 对话框失败，且最新的原生 app-server 日志显示 remote control requires ChatGPT authentication; API key auth is not supported，仅修补 ASAR 和刷新 .codex\remote.json 并不足够。请根据 Codex Rust 源代码和参考原生补丁，构建经过修补的原生 app\resources\codex.exe；如有要求，请使用大型非系统工作根目录：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\build-remote-control-native-replacement.ps1" -WorkRoot "<large-local-build-root>\native-remote"

如果替换原生程序后手机提示 Codex 环境已过期，请在构建前检查原始安装的原生版本。只能使用精确匹配的 Desktop/原生版本/源代码标签组合。例如，Desktop 26.715.2305.0 随附 codex-cli 0.145.0-alpha.18，Desktop 26.707.3748.0 随附 codex-cli 0.144.0-alpha.4：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\build-remote-control-native-replacement.ps1" -WorkRoot "D:\CodexData\rc145" -CodexSourceRef "rust-v0.145.0-alpha.18" -AppServerVersion "0.145.0-alpha.18"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\build-remote-control-native-replacement.ps1" -WorkRoot "D:\CodexWork\phone-remote-26.707\native-remote-0.144.0-alpha.4" -CodexSourceRef "rust-v0.144.0-alpha.4" -AppServerVersion "0.144.0-alpha.4"

构建辅助脚本会将克隆仓库、Cargo 缓存、Rustup 缓存、临时目录、目标目录以及所有已引导安装的 Windows SDK 包放在 -WorkRoot 下。若同时省略 -CodexSourceRef 和 -AppServerVersion，脚本会将已安装的 WindowsApps app\resources\codex.exe 复制到 WorkRoot\tmp，仅对该副本运行 --version，然后选择内置的版本映射；绝不会直接运行 WindowsApps 中的二进制文件。Desktop 26.715.2305.0 对应 rust-v0.145.0-alpha.18、references\remote-control-native-replacement-0.145.0-alpha.18.patch 和工作区版本 0.145.0-alpha.18。Desktop 26.707.3748.0 对应 rust-v0.144.0-alpha.4、references\remote-control-native-replacement.patch 和工作区版本 0.144.0-alpha.4。对于历史版本 rust-v0.142.4，匹配的参数会选择 references\remote-control-native-replacement-0.142.4.patch；该补丁已通过干净的补丁应用验证，但尚未像较新的映射那样完成端到端原生编译验证。其他源版本需要提供匹配的显式版本参数以及经过验证的 -PatchPathOverride。替换 Windows MSIX 时，不要使用 GNU 工具链的输出；请使用 MSVC 目标。

如果存在 MSVC，但缺少 kernel32.lib，辅助脚本会先搜索一个包含匹配的 x64 kernel32.lib、ucrt.lib 和头文件的完整现有 Windows SDK 根目录／版本；不会混用分别发现的已安装 SDK 版本。只有在不存在可用 SDK 时，才会将 Microsoft.Windows.SDK.CPP 和 Microsoft.Windows.SDK.CPP.x64 版本 10.0.26100.4188 下载到 <WorkRoot>\cache\windows-sdk-cpp。下载使用 .partial 文件，并会验证存档和预期载荷；仅在验证通过后才替换缓存；损坏的缓存包会被删除并重新下载。在 Windows PowerShell 5.1 上，请使用经过检查的 tar.exe 解压 NuGet 包；清理较深的 _rels\.rels 目录树时，Expand-Archive 可能会失败。这两个包采用拆分布局，因此请接受匹配的 NuGet 根路径 c\um\x64\kernel32.lib、c\ucrt\x64\ucrt.lib、c\Include\<version>\um\Windows.h，以及可选的 c\bin\<version>\x64\rc.exe，而不是要求使用一个传统的已安装 Kits 目录树。下载会遵循现有的 HTTPS_PROXY / HTTP_PROXY；如果两者都未设置，只有在端口正在监听时，辅助脚本才会使用 http://127.0.0.1:10808，否则会直接下载。

-WorkRoot 除了要位于系统盘之外，也应尽量简短。D 盘上层级过深的根目录仍可能导致 Cargo 检出 Git 依赖时因 path too long 而失败；经过验证的 0.145.0-alpha.18 构建在 D:\CodexData\rc145 下成功完成。若要在外部运行中断或超时后重试，请先确认子 PowerShell 进程已退出，并使用唯一的 WorkRoot / OutputRoot；超时的父进程可能会留下一个子进程，继续清理之前的根目录。

请先运行试运行。除非需要检查失败的补丁产物，否则不要传入 -KeepWorkDir；成功的试运行应清理生成的包和 ASAR 解压输出：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -DryRun

如果机器需要更大的临时构建位置，请显式传入：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -DryRun -OutputRoot "<large-local-build-root>"

如果已从 Codex Rust 源码构建带补丁的原生 app\resources\codex.exe，请显式传入：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -DryRun -ReplacementResourceCodexExe "<path-to-built-codex.exe>"

仅在试运行标记通过后，才进行安装并重新启动：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -Install -Launch -InstallPrerequisites -ReplacementResourceCodexExe "<path-to-built-codex.exe>"

如果缺少 makeappx.exe / signtool.exe，安装路径会从 NuGet 将 Windows SDK BuildTools 下载到 -OutputRoot\.remote-control-temp，而不是 %TEMP%。不要为此下载硬编码本地代理。请先使用默认的直连／环境代理路径；只有确认代理正在监听时，才传入 -BuildToolsProxy "http://127.0.0.1:10808" 或设置 CODEX_WINDOWS_SDK_BUILDTOOLS_PROXY。绝不会打印代理 URI 和凭据。curl download failed with exit code 7 通常表示所选代理端点拒绝了连接。 在外部 PowerShell 进程中运行有破坏性的安装命令，并判断子进程的实际退出代码。在 Windows PowerShell 5.1 下，如果 $ErrorActionPreference = 'Stop'，不要通过 Tee-Object 管道传递 *>&1；写入 stderr 的 npm 警告可能变成终止性的 RemoteException 记录。不要将子进程的 stdout 和 stderr 重定向到同一个文件。使用 Start-Process powershell.exe -Wait -PassThru -RedirectStandardOutput <stdout-file> -RedirectStandardError <stderr-file>，检查 ExitCode，然后在进程退出后合并或汇总两个日志。

如果卸载/签名后安装尝试被中断，且 Get-AppxPackage -Name OpenAI.Codex 未返回任何包，请勿先重新构建。如果所选的 -OutputRoot 中存在现有的已修补 MSIX，请安装它：

Add-AppxPackage -Path "<large-local-build-root>\OpenAI.Codex_<version>_remote-control-patched.msix" -ForceApplicationShutdown -Verbose

清理策略：成功运行远程控制脚本后，删除生成的 MSIX 暂存目录、ASAR 解压文件、脚本本地的 npx 缓存、已安装的已修补 .msix 制品，以及临时 Windows SDK BuildTools。如果用户只要求修复，未要求保留可复用的构建产物，也请删除仅为本次修复创建的原生源码检出、Cargo/Rustup 缓存、target 目录、临时目录，以及生成的补丁/MSIX 文件。保留已安装的已修补包、.codex\remote.json、.codex\remote-control-oauth.json、身份验证/配置/SQLite 状态、日志和明确要求保留的备份。

安装 Phone Remote Control 后，请验证重新打包远程控制功能后，常规功能仍然正常。至少检查实时 ASAR 标记是否表明远程控制和浏览器本地修补可用；如果使用了替换二进制文件，则检查实时原生标记；运行 scripts\install-computer-use-local.ps1 -StrictVerifyOnly、codex plugin list 和 Windows 沙箱冒烟测试；并确认 Chrome 原生消息清单指向稳定的版本化缓存路径，或指向一个解析到版本化缓存目录的 chrome\latest junction，绝不能指向 .tmp 或其他可变的 marketplace 镜像。如果严格检查报告 Chrome 原生主机清单过期或缺少捆绑缓存，请运行 scripts\install-computer-use-local.ps1 -VerifyOnly，然后重新运行 -StrictVerifyOnly。

读取共享日志数据库时，请区分正在运行的 WindowsApps app-server 进程与旧版扩展 app-server 进程。过期的 Antigravity/VS Code 扩展 codex.exe 可能会在 WindowsApps 包修复后仍记录 API key auth is not supported；在判定修复失败前，请按进程路径或 pid 进行筛选。

如果由手机创建的轮次已到达 Desktop，却因调用了错误的模型 API 端点而失败，请先检查具体请求 URL、config.toml 和受影响的线程/会话元数据，再进行任何更改。这属于配对后的配置诊断，不属于远程控制配对流程。请保留对话历史，不要仅为更改 URL 而更改 model_provider ID。

动态工具架构

仅当 Desktop 动态工具变体出现 missing field inputSchema 时，才使用此针对性的 MSIX/ASAR 路径。所需证据：

• 最新的 Desktop 日志显示 method=thread/start，并出现 missing field inputSchema。
• CLI/应用服务器烟雾测试可以启动线程，前提是它们未发送 Desktop 应用动态工具；例如，使用 codex debug app-server send-message-v2 "只输出 OK"，或使用 dynamicTools:null 的等效 thread/start 路径。
• Desktop 日志或提取出的捆绑包表明，故障发生在组装 Desktop 应用动态工具之后，而不是 MCP 服务启动之后。
• 提取出的 webview\assets\app-server-dynamic-tools-*.js 返回旧的命名空间包装器结构：[{type:\namespace`, name, description, tools:[...]}]`。

满足这些条件时，将 Desktop 资源补丁修改为返回扁平的 DynamicToolSpec[] 条目，其中包含 namespace、name、description、inputSchema，以及可选的 deferLoading。除非仍存在单独的 MCP 特定故障，否则此变体无需禁用 MCP 服务。

先运行试运行。系统盘空间不足时，请在容量较大的本地磁盘上使用 -OutputRoot：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-dynamic-tools-windows-msix.ps1" -DryRun -OutputRoot "<large-local-build-root>"

如果试运行通过，请安装并重新启动：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-dynamic-tools-windows-msix.ps1" -Install -Launch -InstallPrerequisites -OutputRoot "<large-local-build-root>"

安装后，通过实际的 Desktop UI 或最新的 Desktop 日志进行验证。仅进行 CLI 烟雾测试并不足够，因为它可能绕过 Desktop dynamicTools。确认最新的 thread/start 条目未报告 missing field inputSchema，然后在适用 Computer Use、Chrome 或浏览器使用的情况下，运行 scripts\install-computer-use-local.ps1 -StrictVerifyOnly 和 codex plugin list。

清理策略：成功运行动态工具脚本后，会删除生成的 MSIX 暂存目录、ASAR 解压文件、脚本本地 npx 缓存、-OutputRoot 下的临时 SDK 缓存，以及已安装的修补版 .msix 文件。仅在运行失败或正在调试时使用 -KeepWorkDir。

提供方历史记录同步

当切换 model_provider、API 账户或提供方配置后，Codex Desktop 本地对话消失，但实际的本地历史记录文件仍然存在时，请使用此针对性工作流。根本原因通常是 Codex 会按当前提供方分类筛选官方侧边栏；较早的线程行和 rollout 元数据仍保留在先前的提供方分类下。

如果进入第二阶段故障，也请使用此工作流：恢复的对话已显示在官方侧边栏中，但因 Desktop 报告工作目录缺失而无法继续。在这种情况下，提供方分类可能已经正确；但可信的事实来源仍可能指向旧的 session_meta.payload.cwd 目录，而该目录已不存在。

此工作流直接使用已验证的本地历史记录机制，不会安装或要求使用外部恢复工具。它会从 config.toml 读取当前提供方，然后对齐本地历史记录存储中的提供方元数据：

• sessions 和 archived_sessions rollout JSONL 的第一行：session_meta.payload.model_provider
• App SQLite 存储：$env:USERPROFILE\.codex\sqlite\state_5.sqlite
• 旧版 CLI SQLite 存储：$env:USERPROFILE\.codex\state_5.sqlite
• 如果 App 存储缺少某些线程行，而旧版 CLI 存储中仍有这些行，则将缺失的线程行从旧版 CLI 存储复制到较新的 App 存储。
• rollout 首行引用的历史 cwd 目录若已缺失，可在明确指定 -RepairMissingCwdDirs 时进行修复。

重要的事实来源细节：

• Codex 26.609+ 可以在启动时根据 rollout JSONL 重建 state_5.sqlite。应将 rollout 第一行中的 session_meta.payload 视为持久元数据，而不能只依赖 App SQLite 行。
• 不要只修改某一个 SQLite 存储来修复 当前工作目录缺失。这样可能会让 UI 看起来已修复，但重启后回填或读取 rollout 时，旧值可能再次出现。
• 在重写历史元数据之前，优先将原先缺失的 cwd 目录重新创建为空目录。这样可以保留 rollout 历史记录，并且已验证可修复已恢复但无法继续的可见对话。 进行任何更改前，先运行试运行：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\sync-codex-provider-history.ps1" -DryRun

阅读试运行输出后，再选择写入路径：

• 如果显示提供方存储区不匹配，请关闭或停止 Codex Desktop，然后运行同步。
• 如果侧边栏已显示恢复的对话，但继续对话时因缺少工作目录而失败，请查看 missing rollout cwd dirs before。如果列出了缺失的 cwd 条目，请使用 -RepairMissingCwdDirs。
• 如果缺失的 cwd 路径位于当前用户配置文件目录之外，默认不要创建这些目录。请先检查路径；只有在确认它们是预期的本地路径时，才传入 -AllowCwdOutsideUserProfile。

提供方同步写入路径：

Get-Process Codex,ChatGPT -ErrorAction SilentlyContinue | Where-Object { $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\Codex.exe' -or $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\ChatGPT.exe' } | Stop-Process -Force
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\sync-codex-provider-history.ps1"

缺失 cwd 修复路径：

Get-Process Codex,ChatGPT -ErrorAction SilentlyContinue | Where-Object { $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\Codex.exe' -or $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\ChatGPT.exe' } | Stop-Process -Force
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\sync-codex-provider-history.ps1" -RepairMissingCwdDirs

此操作只会创建 rollout 首行引用的缺失目录。它不会改写这些 cwd 值，并且仍会验证 config.toml 未发生更改。默认情况下，它会跳过 $env:USERPROFILE 之外的 cwd 路径，以避免在其他驱动器或网络共享上创建意外的根目录。

防护措施：

• 不要修改 config.toml；脚本会在每次运行前后检查文件哈希值，如果文件发生更改就会失败。
• 此工作流中不要安装或启动外部恢复工具。脚本会直接实现所需的本地元数据修复。
• 不要为此症状修补 ASAR 或注入浮动会话列表。单独的浮动面板可以显示会话，但它不是官方的侧边栏恢复机制，并可能引入 UI／编码问题。
• 默认不要同步 .codex-global-state.json 中的工作区／项目根目录。这样可能会导致许多历史 cwd 值在 Desktop 侧边栏中显示为空项目组。
• 默认不要改写 rollout cwd，也不要强制将所有缺失的 cwd 值改为 Documents\Codex 等备用目录。应先尝试恢复原始缺失目录。只有在目录恢复失败后，才将改写历史 cwd 作为单独备份后的最后手段。
• 在写入 SQLite 或 rollout 前，备份会保存到 $env:USERPROFILE\.codex\backups_state\history-sync-agent\<timestamp>。
• 如果有一条 rollout 首行无法读取或为空，可以跳过；如果 SQLite 与可读取的 rollout 数量相符，且官方侧边栏显示了预期的对话，则应将其视为残留数据问题，而非失败。

成功标准：

• 脚本会记录当前配置中的目标提供方。
• 如果 App 和旧版 SQLite 存储都存在，它们都会报告该目标提供方下的活跃和已归档会话行。
• 对于可读取的 rollout，sessions 和 archived_sessions 下首行中的提供方计数都与目标提供方相符。
• 日志中会记录 config.toml sha256 unchanged。
• 重启后，Codex Desktop 的官方侧边栏会显示恢复的历史对话。
• 如果症状是已显示的已恢复对话无法继续，则 missing rollout cwd dirs after 报告的数量应为零，或仅包含已检查／跳过的路径；重启 Desktop 后，受影响的对话可以发送新一轮消息。
• Projects／工作区区域不会因此新增空项目组。

重要防护措施

• 主完整修复安装程序会先验证每个未压缩的 MSIX 负载块，再调用共享的防护安装程序。通过所有预检后，部署会递增程序包修订版本，并使用 Add-AppxPackage -ForceApplicationShutdown 原位安装。部署失败时，现有程序包仍会保持注册；不要添加自动卸载回退。有效的 Authenticode 签名本身并不能证明负载与块映射一致。此路径仅用于受程序包限制的 Desktop 代码；本地 Chrome/Computer Use 故障应使用 Computer Use Only 工作流。
• 完整封装脚本会验证最终程序包仍与其修补的程序包版本一致，且 SignatureKind = Developer。如果 Store 在修复期间替换了程序包，脚本会针对当前程序包重试一次，而不是报告虚假的成功；如果再次发生替换，则会报错并提供可操作的建议。
• 不要原位修改 C:\Program Files\WindowsApps。请使用 MSIX 重新打包脚本。
• 不要通过恢复较旧的 Codex Desktop 程序包，或从其他运行时复制辅助程序，来解决 Windows 10 上 SetIsBorderRequired / 0x80004002 截图失败的问题。每个捆绑的辅助程序修补配置仅适用于其文档中列出的精确输入/输出哈希对，会备份原文件，并拒绝处理未知二进制文件。
• 不要将 list_windows、runtime import ok、返回的截图数量或写入的 PNG 文件视为 Computer Use 捕获正确的证明。对于 node_repl exec context not found，必须确保在请求上下文修补后，后续独立调用能够通过。捕获前立即激活并重新验证目标，然后检查图像内容是否与目标匹配，而不是与遮挡目标的前景窗口匹配。
• 不要将手机远程控制 MSIX 修补作为默认的重新修补副作用运行。仅在手机远程控制任务中，或用户明确要求该工作流时使用。
• 不要将每个 missing field inputSchema 都视为 MCP 问题。如果 CLI 冒烟测试通过，但 Desktop UI 失败，且动态工具 ASAR 资源仍返回命名空间封装器，请改用 Dynamic Tools Schema 工作流，而不是禁用无关的 MCP 服务。
• 不要将类似 FAST_CHECK_OK 的响应视为 Fast Mode 的证明。只有封装脚本的线路验证才可信：它会使用隔离的临时 CODEX_HOME 运行，提供 CLI 的 /v1/models 探测服务，随后捕获 /v1/responses HTTP 正文或 WebSocket 帧，并检查 service_tier=priority。仅有 models 请求不能作为证明。如果 codex exec 在发送该请求前退出或崩溃，验证器会回退到 codex debug app-server send-message-v2，且还必须观察到 thread/start serviceTier=priority；线路捕获仍然是必需步骤。如果 PATH 解析到的只有受保护的 WindowsApps CLI，修补程序必须使用复制到工作程序包中的 CLI；当不存在可运行的 CLI 时，显式验证请求必须失败，而不能悄悄跳过。
• 不要将 %USERPROFILE%\.codex\logs_2.sqlite 中的关键词命中视为当前已安装程序包已修补的证明。任务提示词和记录的工具调用可能会保留 local-patched、already-patched 和修补标记名称等字符串，从而造成误报。判断修补状态时，请使用当前修补程序的 DryRun、来自运行中程序包/ASAR 的直接证据，以及真实的线路、UI、浏览器或运行时冒烟测试。这并不否定带时间戳的 Desktop 运行时日志，只要这些日志与当前程序包、进程和测试运行相关联即可；请勿为此检查删除或修改 logs_2.sqlite。
• 如果应用启动后立即退出，请启用 Electron 日志记录并检查 ASAR 完整性错误：

$pkg = Get-AppxPackage -Name OpenAI.Codex | Select-Object -First 1
$manifest = [xml](Get-Content -Raw -LiteralPath (Join-Path $pkg.InstallLocation 'AppxManifest.xml'))
$desktopExecutable = [string](($manifest.Package.Applications.Application | Select-Object -First 1).Executable)
$exe = Join-Path $pkg.InstallLocation $desktopExecutable
$env:ELECTRON_ENABLE_LOGGING='1'
Push-Location (Split-Path -Parent $exe)
& $exe --enable-logging=stderr --v=1 2>&1 | Select-String -Pattern 'FATAL|Integrity|asar|ERROR'
Pop-Location
Remove-Item Env:ELECTRON_ENABLE_LOGGING -ErrorAction SilentlyContinue

• 如果缺少 makeappx.exe 或 signtool.exe，请正常运行包装脚本；它会临时安装 Windows SDK，并在之后将其移除。
• 如果试运行或重新打包在早期因 robocopy failed with exit code 16 失败，请先检查配置的 -OutputRoot，再更改补丁目标。常见的 Windows 故障是损坏的联接点，例如 Downloads\codex-msix-repack 指向已删除的构建目录。补丁脚本现在会在可能的情况下重新创建缺失的重解析目标，否则会尽早显示可操作的错误消息 OutputRoot is a broken reparse point。如果默认位置无法修复，请在本地大容量驱动器上指定有效的 -OutputRoot。
• 如果本地市场目录缺失，请勿凭空创建市场。报告缺失路径，并询问是否要从备份恢复，或从已知来源重新提取。
• 对于用户级 Codex 状态备份或迁移，请使用 scripts\manage-codex-backups.ps1。它会备份 config.toml、提取的 mcp_servers.json、自定义技能、市场和 chrome-native-hosts.json。默认情况下，它会排除 .git、node_modules、构建输出和虚拟环境；只有在确实需要精确的离线依赖副本时才使用 -IncludeDependencyDirs。插件缓存和 .tmp\bundled-marketplaces 也默认不包含，因为它们可能很大。
• 如果 codex plugin list 因 failed to load configured marketplace snapshot(s) 而失败，且本地市场根目录中只有 marketplace.json，请将该清单复制到 .agents\plugins\marketplace.json，然后重新运行 codex plugin list，再诊断单个插件。
• 请勿依赖 Downloads\patch_codex_fast_mode_windows_msix.ps1；此技能旨在独立运行。除非用户明确传入 -PatchScript，否则请使用 scripts\patch_codex_fast_mode_windows_msix.ps1。
• 除非用户明确要求，否则不要启用捆绑的自定义 model_instructions_file 提示词。将 assets\system-prompt.md 视为不透明资源；复制或配置它，但除非用户另行要求审查提示词，否则不要检查或概述其内容。
• 在 Codex 26.601.2237+ 中，Fast Mode 可能受 webview\assets\read-service-tier-for-request-*.js 中的异步辅助函数控制，其形态类似 return authMethod===\chatgpt` ? featureRequirements?.fast_mode !== false : false。补丁应移除仅针对 chatgpt` 的分支，同时仍读取模型／主机的功能要求，然后通过线路捕获进行验证。
• 在 Codex 26.601.2237+ 中，Fast Mode 也可能因 webview\assets\use-service-tier-settings-*.js 而在设置 UI 中不可见或处于禁用状态。补丁应连接 Fast UI 补丁器并记录 fast-mode UI patch result，不能只补丁请求辅助函数。
• 如果重启后语言选择恢复为英语，请在提取的 webview 资源中检查 enable_i18n、locale_source 和 localeOverride。语言区域补丁应记录 locale i18n patch result；仅写入配置不能视为足够。
• 如果浏览器、Chrome、浏览器窗格或 browser_use 仍不可用，请检查 Desktop 日志中的 browser_use_availability_resolved。reason=statsig-disabled 表示本地门控补丁未生效，或 Store 版本引入了新的目标形态；reason=local-patched 表示可用性门控已开放，接下来应检查 Chrome 扩展、本机消息传递主机和捆绑插件状态。
• 在 Codex 26.601.2237+ 中，旧版插件 UI 门控目标 533078438 和 pluginDeepLinkAuthBlocked 可能不存在。请在 webview\assets\plugins-page-*.js 中检查 openPluginInstall、authMethod: 和类似 {authMethod:x}=..., y=authBlocked(x), 的紧凑赋值；将身份验证阻止变量补丁为 false，不要因缺少旧版侧边栏／技能／详情代码块而失败。
• 在 Codex 26.616.3767+ 中，plugins-page-*.js 可能会在 authMethod 与身份验证阻止变量之间插入账户数据钩子，形态类似 {authMethod:x}=authHook(),{data:y}=accountHook(),z=authBlocked(x),。保留插入的钩子，只将身份验证阻止变量补丁为 false。
• 在 Codex 26.616.3767+ 中，Goal 斜杠命令可能不再包含旧的 3074100722／goals 配置门控或 threadGoalObjective 锚点。如果 composer 根据非云端／本地状态计算 Goal 可用性（例如将 isGoalActionAvailable 传入 enabled），则应将该形态视为已开放，不要导致 MSIX 试运行失败。
• 在 Codex 26.616.3767+ 中，use-is-plugins-enabled-*.js 可能保留相同的 featureName:\browser_use`和featureName:`browser_use_external`语义，但用于功能钩子、statsig 和runCodexInWsl读取的缩减变量名称可能不同。应根据featureName、enabled、isLoading、410262010和runCodexInWsl周围的形态匹配门控；不要依赖x、g或u` 等固定辅助函数标识符。
• 在 Codex 26.707.3748.0 中，Desktop 功能发送器可能会在 externalBrowserUseAllowed 与 computerUse 之间插入 findShortcuts。强制设置浏览器使用可用性字段时，请保留该字段；不要要求 computerUse 必须紧跟在 externalBrowserUseAllowed 后面。
• 在 Codex 26.707.8479.0 中，Electron 功能接收器使用带参数的缩减变量，例如 o=r===\win32`&&n.CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE...，而不是较旧的固定 i` 平台变量。应根据赋值、平台变量、环境对象和基础功能对象的结构进行匹配；不要硬编码缩减标识符。
• 在 Codex 26.707.8479.0 中，plugins-page-*.js 可能会在 {authMethod:x}=...() 与身份验证阻止赋值之间插入工作区／账户推导。请根据后续的 route.kind===\manage`` 边界定位阻止赋值，并只对该变量打补丁；保留所有中间钩子和派生状态。
• 在 Codex 26.519.11010+ 中，use-plugin-install-flow-*.js 可能不再包含 featureName:\computer_use`。对于 Computer Use 安装流程门控，请定位包含 installPlugin:async和openPluginInstall的文件，然后补丁修改导入的可用性元组，将 Computer Use 对应的第一个.available` 值强制设为 true。
• 在 Codex 26.707.8479.0 中，Computer Use 安装流程可能迁移到 plugin-detail-page-utils-*.js，并在缩减后的异步 mutation 中用 install-plugin RPC 替换字面属性 installPlugin:async。接受任一锚点，但必须要求存在 openPluginInstall，并且只补丁三个可用性元组中的第一个值。
• 在 Codex 26.707.8479.0 中，捆绑市场复制器可能已通过 windows-file-copy-*.js 中的 copyDirectoryAllowDecryptedDestinationOnEncryptionFailure 为 Windows 设置路由。将此原生 Windows 回退视为已修复，不要将其替换为较旧的字节流回退；仍应在需要时独立应用捆绑的 sites 可用性补丁。
• 请勿在 C:\Program Files\WindowsApps 中直接修改文件以启用 Computer Use。Windows 门控由 CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1 控制，辅助程序路径通过本地 computer-use@openai-bundled 插件提供。
• 如果 Computer Use 或 node_repl Computer Use 插件在 Windows 上因 windows sandbox failed: spawn setup refresh 而失败，请检查 $env:USERPROFILE\.codex\.sandbox\sandbox.<date>.log。如果日志显示 codex-windows-sandbox-setup.exe 因 OS error 740 失败，请设置 [windows] sandbox = "unelevated"。验证前请检查 codex sandbox --help：如果帮助中列出 windows 命令，请使用 codex sandbox windows "C:\Windows\System32\cmd.exe" /c echo OK 验证；只有帮助接受直接命令形式的版本才应使用 codex sandbox "C:\Windows\System32\cmd.exe" /c echo OK。
• 如果 Computer Use 任务在与应用交互前因 Package subpath ... is not defined by "exports"、Module not found: @oai/sky、缺少 setupComputerUseRuntime，或内部 @oai/sky／computer_use_client_base 导入路径错误而失败，应将其视为本地捆绑插件／运行时不匹配。运行 scripts\install-computer-use-local.ps1 -VerifyOnly，然后运行 -StrictVerifyOnly。除非 Desktop 日志也证明 UI 可用性门控仍处于关闭状态，否则不要为此类问题修补 app.asar 或 resources\codex.exe。
• 如果“任意应用”可见但因组织／区域不可用而处于禁用状态，请检查提取的 ASAR 中的 webview\assets\use-is-plugins-enabled-*.js。相关本地门控为 featureName:\computer_use`和 Statsig1506311413`；应重新应用 MSIX 补丁，而不是直接编辑 WindowsApps。
• 如果 Computer Control 页面显示 Computer Use 插件不可用，请检查 Desktop 日志中是否有 computer-use native pipe startup failed 和 missing-helper-path，然后检查 [marketplaces.openai-bundled] 下配置的 source，以及其中的 .agents\plugins\marketplace.json 和 plugins\computer-use。如果这些内容缺失或不完整，请停止 $env:USERPROFILE\.codex\plugins\cache\openai-bundled 下捆绑的 extension-host 进程，重新运行 scripts\install-computer-use-local.ps1，重启 Codex Desktop，并确认日志最终显示 computer-use native pipe startup ready。
• 当前 Codex 版本可以使用轻量级的版本化 Computer Use 缓存，其中没有可用的 latest 联接点，也没有插件本地的 node_modules；@oai/sky 位于 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node 下。有些版本仅提供描述符，因此不包含 scripts\computer-use-client.mjs。如果版本化描述符与已安装的包匹配，且导入独立运行时后可使用返回数组的 sky.list_windows，则此布局正常。对于已识别的 @oai/sky 0.6.2 Window2 配置，不要依赖捆绑的运行时文档调用；修复会应用受保护的本地技能覆盖层，使用 list_windows、get_window_state({ window, ... }) 和 activate_window({ window })。仍附带客户端脚本的版本则保留旧版客户端导入和辅助程序传输检查。
• 如果完全退出并重新打开 Codex Desktop 后故障再次出现，请检查 $env:USERPROFILE\.codex\chrome-native-hosts.json、%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json 和 $env:USERPROFILE\.codex\chrome-native-hosts-v2.json，以及 $env:USERPROFILE\.codex\plugins\cache\openai-bundled\chrome\latest 和 browser\latest 的实际目标。即使外层清单和 extension-host-config.json 正确，侧边栏错误（例如 Codex app-server manifest entry is missing required path nodePath）仍可能持续出现，因为两个 v2 状态文件都只包含旧包／运行时路径，或当前条目的哈希错误。较新的 Chrome 插件版本可能会将版本化缓存路径规范化为 chrome\latest；仅当该联接点解析到版本化缓存目录时，这才是可接受的。过时的 Chrome 本机主机条目，或指向 $env:USERPROFILE\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome 的 chrome\latest 联接点，也可能导致 Chrome 本机消息传递锁定可变的市场镜像。重新运行 scripts\install-computer-use-local.ps1，以停止锁持有进程、重建稳定的 browser／chrome 缓存副本、重新指向外层清单，并以原子方式同步两个 v2 状态文件。
• 请勿从可变的 .tmp\bundled-marketplaces 镜像构建稳定的 browser、chrome、sites 或基础 computer-use 缓存。Desktop 可能会在复制文件期间协调该镜像。请使用已安装包的市场作为稳定来源，然后将本地 Computer Use 运行时直接覆盖到其版本化缓存中。
• 如果重启后故障再次出现，且在 copy_plugins 期间发生 plugin_marketplace_folder_write_failed、出现 bundled_plugins_marketplace_resolve_failed，或因 not_in_bundled_marketplace_plugin_names 移除了先前安装的捆绑插件，请只修补捆绑市场复制辅助程序，不要运行完整的 Fast／浏览器／Computer Use 门控补丁。此定向补丁会在本地保留包描述符集合，但不得安装或启用用户未选择的可选插件。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -DryRun -OutputRoot "<large-local-build-root>"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -Install -Launch -InstallPrerequisites -OutputRoot "<large-local-build-root>"

如果本地 Computer Use 运行时已通过 install-computer-use-local.ps1 -StrictVerifyOnly，但 Desktop 仍未提供 cua.computer.* 接口，请先检查当前 ASAR 中是否存在两个受支持的仅适用于 Darwin 的门控条件。只有两者都存在时，才使用下面的定向主 ASAR 模式。此模式与范围更广的 Fast Mode/浏览器/插件补丁集刻意分开：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyComputerUseSurface -DryRun -OutputRoot "<large-local-build-root>"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyComputerUseSurface -Install -Launch -InstallPrerequisites -OutputRoot "<large-local-build-root>"

该模式要求恰好有一个内容匹配的 .vite\build 目标，并且每个原始门控条件都恰好出现一次。要满足幂等性，必须同时具备两个完整的已修补门控条件、一个 CODEX_CUA_WINDOWS_SURFACE_V1 标记，且不存在原始门控条件；只有标记、状态混杂或候选项重复都会导致安全失败。旧版 Windows 布局会保留 computerUse 和 computerUseNodeRepl。不含后一个标志的 Desktop 26.917 布局，必须恰好匹配一次完整的统一 CUA 就绪条件，允许使用 n.Gu 和 n.Wu 等重命名的导入/导出符号。完整的早期补丁会迁移为适用于主机布局的正确表达式；早期补丁插入的依赖项不能证明主机仍支持该标志。Darwin 行为保持不变。已修补的资源必须通过 node --check。此模式会跳过无关的 Chrome 注册表补丁，并拒绝与其他定向模式、市场注册、Fast Mode 验证或截图助手补丁组合使用。它不会编辑插件缓存文件、.mcp.json 或用户配置。正常重新打包仍会更新复制包的 ASAR 完整性元数据和签名；安装/重新启动必须由外部执行器运行。

通过夹具测试且安装包空运行成功，并不能证明 Desktop 中的实际交互可用。重新启动后，请在新对话中检查 Object.keys(cua)，并枚举窗口以进行默认后台检查。@oai/cua 0.2.5 中的 cua.listWindows() 支持此检查。仅当明确授权进行捕获/输入诊断时，才使用 cua.getApp({ windowId: <real id> }) 或较低层级的窗口 API；向 getApp 传入字符串参数是 macOS 的用法。分别记录审批界面、截图内容、辅助功能和输入情况；未测试的项目应标明未测试。

在 Windows 上，高层绑定的 getScreenshot() 可能会因 multiple screenshot regions; a single screenshot is unavailable 而拒绝处理窗口。Desktop 26.917.9434.0 在 Explorer 窗口中返回了两个区域，而较低层级的 cua.computer.get_window_state() 则返回了所有可见截图和辅助功能状态。请检查 screenshots[] 区域和目标窗口内容，不要将高层级的单图错误视为原生 Computer Use 失败。如果 Sky 报告窗口中有用户同时输入，请停止输入，不要覆盖用户操作。

实用封装器选项

• -PatchWindowsStoreUpdateFallback：仅当 Desktop 日志显示存在更新的官方清单，而 Store 却报告 NoUpdates 时才选择启用。受支持的 26.928 分支随后会调用现有的官方 MSIX 回退机制，而不是报告已是最新版本。请先运行完整的 DryRun；此选项会修改 Codex 的更新程序，而非 Windows Store 任务或策略。参见 Windows Store 下载回退。

• -DryRun：仅验证捆绑项目标；不安装。除非指定 -KeepBuild，否则包装脚本会要求补丁程序在成功完成补丁阶段后清理其复制的构建根目录。清理为尽力而为，因此若必须确保没有残留数据，请检查报告的路径；即使补丁程序已清理自己的构建根目录，后续包装脚本验证仍可能失败。

• -NoLaunch：安装，但不启动 Codex Desktop。

• -SkipFastVerify：跳过本地 HTTP/WebSocket service_tier 捕获。

• -CustomModels <id1,id2,...>：强制通过 Desktop 模型可见性筛选器的自定义模型 ID；默认值为 gpt-6-astra、gpt-6-sol、gpt-5.6-sol、gpt-5.6-terra 和 gpt-5.6-luna。包装脚本和主补丁程序都接受以逗号分隔的 ID 或 PowerShell 字符串数组。传入此参数会替换默认列表，即使之前的补丁已完整应用也是如此，因此请在新增模型的同时重复列出仍要保留的模型。空项会被移除，重复 ID 会去重。

• -KeepBuild：无论执行 DryRun 还是安装，都保留包装脚本的 MSIX 构建根目录和保留的产物，以便调试。补丁程序内部的临时 ASAR 工作目录仍遵循其自身的清理策略。

• -OutputRoot <path>：可选的大型本地构建根目录；当默认输出根目录空间不足、指向失效的联接，或需要将其移出系统盘时使用。

• -OnlyBundledMarketplaceCopy：仅修补 Desktop 捆绑的市场副本／辅助程序可用性路径，以便 Windows 在 fs.cp() 无法从受 WindowsApps 保护的包路径复制捆绑插件文件时改用字节流复制。当 sites、deep-research、Code Review 和统一 Computer Use 的功能谓词会将其筛掉时，此参数也会恢复受支持的可选市场条目。发布这些条目不会安装它们，也不会切换浏览器引擎。仅在已确认捆绑市场同步或发现失败时使用，不适用于一般的 Fast Mode 或 UI 门控。

• -OnlyComputerUseSurface：仅修补当前主 ASAR 中仅限 Darwin 的 Windows Computer Use 界面门控。请先使用 -DryRun；如果包锚点缺失或存在歧义，操作会安全失败。

• -OnlyModelExperience：检查并有选择地修复 Fast Mode 请求门控、Fast Mode UI 门控、自定义模型可见性筛选器、紧凑 Power 滑块门控，以及 Ultra 设置持久化。适用于 Fast Mode、自定义隐藏模型、依赖它们的紧凑 Power 滑块，以及自定义提供商下被禁用的 Ultra 开关。旧名称 -OnlyCustomModels 保留为别名。

• 如果 26.1007 的 DryRun 报告 fastModeTarget 缺失，请查看 references/restriction-debug-cases.md 中的服务层级访问对象案例；该版本会将两种速度模式委托给共享转换器，而不是使用较旧的内联布尔门控。

• -SkipSdkCleanup：保留已安装的 Windows SDK。

• -RegisterMarketplaceOnly：仅注册 openai-curated-local；不修补 Codex。

• -PatchScript <path>：仅在测试更新版本的补丁程序时覆盖捆绑的补丁脚本。

• -SkipComputerUse：跳过本地 Computer Use 兼容插件的安装／验证。

• -PatchWindows10ScreenshotHelper：在完整 MSIX 修复期间，显式修补暂存的原生辅助程序；仅在 Windows 10 上复现 SetIsBorderRequired / 0x80004002 或 FrameArrived timed out 后使用。包装脚本和主补丁程序均支持此参数。默认情况下辅助程序保持不变；显式请求会拒绝未知哈希，且不能与定向模式结合使用。

• 仅当遇到上述确切的包门控可信路径错误时，包装脚本才可继续执行 Computer Use 预检；只有在有意将本地运行时修复与包修补分开时，才使用 -SkipComputerUse。

• -VerifyAllBundledPluginsAvailable：添加断言，确保稳定的 openai-bundled 描述符名称和版本与已安装的包完全匹配，并且结构化 CLI 输出中每个条目都以该版本显示为已安装，或显示为可用且具有现有的本地来源。此断言绝不会调用 plugin add，但主包装脚本仍会执行常规修复或 DryRun 行为。如需完全只读检查，请直接运行 install-computer-use-local.ps1 -StrictVerifyOnly -VerifyAllBundledPluginsAvailable。

• -InstallModelInstructionsFile：可选；将捆绑的提示词资源复制到 $env:USERPROFILE\.codex\prompts\system-prompt.md，并在 $env:USERPROFILE\.codex\config.toml 中设置顶层 model_instructions_file。

• -ModelInstructionsSource <path>：-InstallModelInstructionsFile 的可选源路径覆盖值；默认为 assets\system-prompt.md。

• -ModelInstructionsDestination <path>：-InstallModelInstructionsFile 的可选目标路径覆盖值；默认为 $env:USERPROFILE\.codex\prompts\system-prompt.md。 手机远程控制脚本选项：

• scripts\build-remote-control-native-replacement.ps1 -WorkRoot <path>：在选定的工作根目录下克隆、打补丁并构建原生替代版本，同时将 Cargo/Rustup/临时文件/目标文件/源文件产物以及备用 Windows SDK C++ NuGet 缓存放在系统盘之外。省略两个版本参数时，脚本会从临时 WorkRoot 副本中自动检测已安装的原生版本；如果检测到的版本没有映射，则必须显式提供参数，而不会假定版本为 0.144。

• -CodexSourceRef <rust-vX> -AppServerVersion <X>：覆盖自动检测时，务必提供这两个完全匹配的参数。0.145.0-alpha.18 已通过 Desktop 26.715.2305.0 的精确标签构建、安装和手机端到端验证；0.144.0-alpha.4 已通过 Desktop 26.707.3748.0 的同等范围验证；专用的 0.142.4 补丁已通过补丁应用验证，但尚未在此工作流中完成完整编译。

• -PatchPathOverride <path>：仅在提供了完全匹配的源引用/应用服务器版本参数，并确认指定补丁针对该确切源后使用；编译前仍会检查补丁是否能成功应用。

• -SkipBuild：仅复用之前生成且附带 codex.remote-control-build.json 的二进制文件。此辅助脚本会验证确切的 Git 提交、源引用、应用服务器版本、补丁 SHA-256、Rust 工具链、目标平台、构建配置、二进制文件的 --version 输出和原生标记；仅含标记或未盖章的过期二进制文件会被拒绝。此模式下不会初始化或下载 Windows SDK。

• scripts\patch-remote-control-windows-msix.ps1 -DryRun：修补并验证提取出的软件包，但不安装；随后清理成功生成的产物。

• -KeepWorkDir：保留 MSIX 暂存目录、ASAR 提取文件和脚本本地 npx 缓存以供调试；常规修复时请勿使用，因为每次保留都可能占用数 GB 空间。

• -OutputRoot <path>：可选的大型本地构建根目录；默认临时目录或输出盘空间不足时使用。

• -ReplacementResourceCodexExe <path>：复制经过打补丁的原生应用服务器二进制文件，并在打包前验证远程控制标记。

• -Install -Launch -InstallPrerequisites：DryRun 通过后，对打补丁的软件包签名、安装并重新启动。

动态工具架构脚本选项：

• scripts\patch-dynamic-tools-windows-msix.ps1 -DryRun：提取当前软件包，修补并验证 app-server-dynamic-tools-*.js，运行 node --check，然后在不安装的情况下清理成功生成的产物。
• -OutputRoot <path>：可选的大型本地构建根目录；系统盘空间不足时使用。
• -Install -Launch -InstallPrerequisites：DryRun 通过后，对目标 dynamicTools 补丁软件包签名、安装并重新启动。
• -KeepWorkDir：仅用于调试时保留 MSIX 暂存目录、ASAR 提取文件和脚本本地 npx 缓存。

可选模型指令文件

此工作流提供可选的自定义模型指令安装程序。它不属于默认的 repatch 流程，仅应在用户要求进行额外配置时运行。

面向用户的名称“听话水”（Tinghuashui）指现有的捆绑式系统提示词配置。诸如“配置听话水”或“帮我进行听话水相关的配置”之类的请求会选择此工作流。仅针对这项请求，请使用下方的独立安装程序和 assets/system-prompt.md；不要生成替代提示词，也不要运行 Desktop repatch。保持捆绑提示词内容不变。

若要仅安装捆绑提示词资源并配置 Codex：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-model-instructions-file.ps1"

安装程序会将 assets\system-prompt.md 复制到 $env:USERPROFILE\.codex\prompts\system-prompt.md，写入此顶层 TOML 条目，在 Python 可用时验证 TOML 语法，并为任何现有的 config.toml 创建带时间戳的备份日志：

model_instructions_file = 'C:\Users\<user>\.codex\prompts\system-prompt.md'

若要将其与主包装器结合使用，请显式添加 -InstallModelInstructionsFile：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\repatch-codex-windows.ps1" -InstallModelInstructionsFile

若要在不更改文件的情况下检查当前计算机：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-model-instructions-file.ps1" -VerifyOnly

配置 model_instructions_file 后，请重启 Codex CLI/Desktop，或启动新会话，以便加载新的模型指令文件。

仅限计算机操作

使用此路径修复本地 Computer Use 插件/运行时，不重新打包 MSIX。此流程会重建本地 openai-bundled 市场镜像，从一个固定版本的已安装软件包源修复稳定的 computer-use / browser / chrome / sites 缓存链接，将已安装的 CUA @oai/sky 运行时叠加到本地 Computer Use 插件中，在需要时修补本地化/默认值 Chrome 注册表解析和 Computer Use 客户端导入结构，保留有效的 SKY_CUA_NATIVE_PIPE 配置并移除过期的覆盖项，将 Chrome 原生消息传递主机及两个 schema-2 app-server 状态文件更新为当前稳定的缓存/运行时路径，并验证客户端导入或独立运行时传输。

如果运行时有响应、codex-computer-use-* 管道存在且 -StrictVerifyOnly 通过，但 Object.keys(cua) 仍不包含原生成员，请检查当前插件布局。仅当存在 unified-computer-use/scripts/launch.mjs 时，才运行以下插件级修复；仅含描述符的 26.908+ 版本需要使用上文所述的针对性 ASAR 工作流：

$surfaceRepair = "$SkillRoot\scripts\repair-cua-surface-lock.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File $surfaceRepair -VerifyOnly
powershell -NoProfile -ExecutionPolicy Bypass -File $surfaceRepair -Install

只要有任何必需目标缺失、不受支持或未修补，-VerifyOnly 就会失败；仅有标记绝不会被视为已完成修补。默认报告和单独使用的 -Json 都是只读的；-Json 也可以格式化明确指定的安装/回滚报告。-VerifyOnly 不能与写入模式组合使用。-Rollback 仅在相邻的 <file>.bak-* 备份与已安装补丁匹配时才会还原，并会拒绝覆盖之后所做的编辑。此修复会在 scripts\launch.mjs 中强制启用 computer 界面，并在 resources\computer-description.md 中添加 Windows 使用说明，覆盖缓存副本和受支持的市场源副本。它绝不会修改生成的 .mcp.json：即使该环境值仍为 browser，新服务也会从启动器读取强制启用的界面。

此工作流要求插件采用基于脚本的布局。没有 scripts\launch.mjs 或所需说明文件的仅含描述符版本不受支持；不要仅为通过检查而安装额外插件或扩大修补范围。scripts\test-cua-surface-lock-patterns.ps1 会使用隔离的测试样例验证此修复；python "$SkillRoot\scripts\test-probe-cua-surface.py" 会在不启动服务的情况下检查探测结果验证。实时运行的 probe-cua-surface.py 要求存在使用说明、API 成员以及非空的窗口/应用程序结果；这些结果不能证明 Desktop 确实已重启或已捕获屏幕截图。 两个补丁在同一版本的 Desktop 重启后仍会保留，只有在插件缓存重新生成时才会重置；实际情况下，这意味着 Desktop 升级并更改插件版本目录。每次 Desktop 更新后，重新应用，而不是重新分析：运行 -VerifyOnly，只有在失败时才运行 -Install。脚本会匹配所有插件版本目录，因此版本升级无需修改。若报告显示 unsupported，请参阅 references/restriction-debug-cases.md 中的重新应用案例，了解该如何处理。

如果枚举正常，但后续的 Computer Use 调用返回 node_repl exec context not found，请在修复前检查源配置文件：

$contextPatcher = "$SkillRoot\scripts\patch-computer-use-node-repl-context.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File $contextPatcher

文档记录的 @oai/sky 0.6.2 配置文件为 6423BA83...702B7C -> 3600AC24...5BB60A。优先使用常规的 install-computer-use-local.ps1 -VerifyOnly 路径进行安装，然后重置当前的 node_repl JavaScript 内核，并重新运行 -StrictVerifyOnly。补丁程序会将精确的原始文件备份到 .codex\backups\computer-use-node-repl-context，并支持 -Rollback；它会拒绝未知哈希。端到端验证必须先在一次 JavaScript 调用中启动辅助程序，再在后续调用中捕获一个受控且刚激活的窗口，以便测试涵盖过时上下文边界。

如果 Windows 10 能够调用原生辅助程序，但截图捕获在 SetIsBorderRequired 处因 0x80004002 失败，或在枚举成功后报告 FrameArrived timed out，请在重新运行常规本地修复前检查辅助程序配置文件：

$helperPatcher = "$SkillRoot\scripts\patch-computer-use-helper-win10.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File $helperPatcher

只有某个已记录的完整辅助程序 SHA-256 配置文件返回 original-patchable 结果时，才允许进一步评估。实际写入还要求系统为 Windows 10，且截图失败原因是已记录的边框接口或帧回调问题；Windows 11 上的匹配哈希不构成授权。配置文件包括较早的边框接口版本，以及较新的回调超时版本，涵盖来自 issue #93 的 @oai/sky 0.7.6-F78948E6 和 0.7.6-63C98C4D。这两个版本都已分别通过二进制文件、候选文件和展开验证；Windows 10 上的捕获和输入验收仍待完成。二进制兼容边界由辅助程序哈希决定，而非 Desktop 版本；报告的版本相同，仍可能对应不同的二进制文件：

powershell -NoProfile -ExecutionPolicy Bypass -File $helperPatcher -Install

补丁程序会验证完整的输出哈希，将原始文件存储在 .codex\backups\computer-use-helper，并支持 -Rollback。安装后，继续运行 -VerifyOnly 和 -StrictVerifyOnly。在单独授权的捕获测试或用户提供的运行时证据予以确认之前，截图缺陷是否实际解决仍未得到验证；请勿为此测试自动打开 Explorer/Task Manager。请勿将该配置文件应用于哈希未知的辅助程序。

要仅刷新本地 Windows Computer Use 文件和环境门控：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1"

要验证并自动修复缺失的本地 Computer Use 文件：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -VerifyOnly

要验证但不更改文件：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -StrictVerifyOnly

如果 -StrictVerifyOnly 因缓存路径缺失或过时而失败，请运行一次 -VerifyOnly，然后重新运行 -StrictVerifyOnly。如果 -VerifyOnly 成功，但 Desktop 仍报告原生管道不可用，请重启 Codex Desktop，并在最新的 Desktop 日志中查找 computer-use native pipe startup ready。

备份管理

要备份本地 Codex 配置、MCP 服务条目、自定义技能、市场和 Chrome 原生主机状态：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action Backup

要列出或恢复快照：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action List
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action Restore -BackupPath "<backup path>"

成功标准

• 如果修改了现有的 config.toml，日志会显示在 .codex\backups\config\ 下带时间戳的备份。
• 补丁日志中的 selected Codex app 和 source package 行会标识预期的最高版本包；如果存在更新的 SYSTEM-Staged Store 包，也会包含在内。
• Get-AppxPackage -Name OpenAI.Codex 显示 SignatureKind = Developer。
• 安装日志会通过 AppUserModelId 启动已打补丁的 Desktop 包，避免在 WindowsApps 下直接访问可执行文件时失败。
• 清单声明的 Codex Desktop 进程会从已安装的包启动并持续运行；新版本当前为 ...\app\ChatGPT.exe，旧版本为 ...\app\Codex.exe。
• Fast Mode 验证会到达 /v1/responses，并记录 request wire service_tier=priority；仅探测 /v1/models 不足以通过验证。使用 app-server 回退时，也会记录 thread/start serviceTier=priority。
• 补丁日志包含 fast-mode UI patch result 和 locale i18n patch result，各自的结果为 patched 或 already-patched。
• 补丁日志包含 custom models patch result，且打补丁后的模型筛选器包含所有已配置的自定义模型 ID。
• 补丁日志包含 browser-use gate patch result，结果为 patched 或 already-patched。
• 打补丁后的应用启动后，Desktop 日志会显示 browser_use_availability_resolved，其中 available=true 且 reason=local-patched。
• $env:USERPROFILE\.codex\config.toml 包含 [marketplaces.openai-curated-local]。
• $env:USERPROFILE\.codex\config.toml 包含 [marketplaces.openai-bundled]，其指向 install-computer-use-local.ps1 选定的 marketplace 根目录，且该 marketplace 包含已安装的捆绑插件以及本地 Computer Use 覆盖项。在 codex-cli 0.149+ 中，openai-bundled 是保留的 marketplace 名称，因此可接受的来源是由 Desktop 物化的 .tmp\bundled-marketplaces\openai-bundled 保留根目录；脚本回退到该根目录是正确行为，并非偏离预期，而且会记录 codex-cli refused the local bundled marketplace source; repointing marketplaces.openai-bundled at the reserved root。只有在仍接受非保留名称的旧版 CLI 中，才预期使用稳定的非保留根目录。不要将保留根目录来源“修复”为稳定根目录：这样会导致 CLI 完全丢弃该 marketplace，使 codex plugin marketplace list --json 不再报告 openai-bundled，且 Desktop 日志会显示 marketplace `openai-bundled` is reserved and cannot be added from this source。如果 .codex\.tmp 是指向其他卷的联接点，保留根目录不会违反不得使用 C 盘的限制，因为保留路径会解析到该卷。
• 任何用于个人插件的已配置本地 marketplace 都必须具有受支持的 .agents\plugins\marketplace.json；仅有根目录级别的 marketplace.json 不足以满足当前插件 CLI 的要求。
• codex plugin list 会将请求修复所需的插件显示为 installed, enabled；对于 Browser/Chrome/Computer Use 工作，所需插件包括 browser@openai-bundled、chrome@openai-bundled 和 computer-use@openai-bundled。可选插件保持原有状态。
• 请求 -VerifyAllBundledPluginsAvailable 时，稳定版 openai-bundled marketplace 中的每个完整描述符都与已安装包具有相同的名称和版本，并以该版本显示在 CLI installed 和 available JSON 条目的并集中，且存在本地来源；不会因此安装或启用任何可选插件。此开关会将 marketplace 与包自身的 app\resources\plugins\openai-bundled 清单进行比较。请根据当前完整判定条件诊断描述符集合不匹配：已记录的 26.825.6671.0 平台/帐户缺项仍属预期，而受支持的 26.1007 可选条目发现修复则要求部署后存在全部九个可发布描述符。请参阅 references/restriction-debug-cases.md 中的两种捆绑描述符情形；仅凭不匹配不足以授权使用未知的门控覆盖项。
• 最近的 Desktop 日志会保留当前包中的捆绑描述符名称，且不会显示 not_in_bundled_marketplace_plugin_names 移除了已安装的插件。
• $env:USERPROFILE\.codex\config.toml 包含 [plugins."computer-use@openai-bundled"]，其中 enabled = true。
• codex plugin list 将 computer-use@openai-bundled 显示为 installed, enabled。
• 如果需要使用 Chrome/browser，codex plugin list 会将 chrome@openai-bundled 和 browser@openai-bundled 显示为 installed, enabled；Chrome 原生消息传递主机清单指向稳定的当前版本缓存，而非 .tmp\bundled-marketplaces，其来源与当前 extension-ids.json 完全一致。extension-host.exe 目录包含 extension-host-config.json，其中有架构 1、与当前包匹配的用户本地 codex.exe，以及当前同一运行时的 node.exe / node_repl.exe 路径。%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json 和 $env:USERPROFILE\.codex\chrome-native-hosts-v2.json 均包含相同的当前架构 2 条目、官方 NUL 分隔的 SHA-256 标识、已安装包的 resourcesPath，以及现存的运行时/缓存路径。活动 marketplace 和版本化缓存中的 browser-client.mjs 哈希与已安装包匹配。旧版构建还要求该哈希存在于已安装的 app.asar 中；26.814 风格的构建则要求满足完整的原生主机路径契约，并且两个 v2 状态文件中的 browserClientPath / browserServicePath 值位于同一稳定根目录下。setupBrowserRuntime() 成功，agent.browsers.get("chrome") 返回 Chrome 扩展后端，chrome\latest 和 browser\latest（若存在）解析到稳定的版本目录；真实冒烟测试会通过 Desktop 浏览器通道读取请求的公共 HTTPS 页面，并确认其最终 URL、检测到的标题及有意义的可见内容。
• 当 Chrome/browser 冒烟验证属于范围且 Chrome 未运行时，应自动启动 Chrome，无需额外请求用户授权。使用与任务相关的公共 HTTPS 页面，并验证其最终 URL、检测到的标题及有意义的 AX/DOM 内容。不要要求特定的第三方 DOM（例如历史上的 example.com 标题）。如果目标访问失败或页面已更改，请参阅 references/restriction-debug-cases.md 中的“Browser Smoke Target Changes or Fails Independently”情形。
• 当前用户的 CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE 已设置为 1。
• 完整重新打补丁可以写入 [features] computer_use = true 以实现兼容，但定向的 -OnlyComputerUseSurface 模式不会编辑配置。在 CLI 0.155.0-alpha.16.4 上，codex features list 报告 computer_use 为稳定功能且默认开启；若全新的 Desktop 会话暴露原生 CUA 并成功枚举窗口，则缺少显式键也能通过后台检查。捕获/输入是单独的可选证据。
• $env:USERPROFILE\.codex\config.toml 包含 [windows]，其中 sandbox = "unelevated"，且 codex sandbox --help 显示的沙盒命令语法可正常运行。
• Computer Use 插件缓存与已安装包匹配。既支持旧版 computer-use\latest\node_modules\@oai\sky，也支持当前的轻量级版本化缓存或仅含描述符的缓存，以及 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node；验证会通过辅助程序传输或官方独立运行时导出到达 list_windows。
• 对于旧版布局，scripts\install-computer-use-local.ps1 -StrictVerifyOnly 会记录 client import ok 和 helper transport ok；对于仅含描述符的布局，则会记录 runtime import ok 和 method=list_windows。
• 对于基于脚本的 CUA 表面锁，scripts\repair-cua-surface-lock.ps1 -VerifyOnly 要求每个发现的副本都包含完整的 surface 和 description 补丁；不要将此测试用作仅含描述符的 26.908+ 插件的门槛。在已记录的 26.903.61454 配置中，打补丁后的哈希为 4312E22A...419175 和 C72E08A0...FB9291；其他完整文件需要各自的证据，而不能套用这些历史哈希前缀。两套 fixture 测试都必须通过。实时探测必须在强制使用 browser 环境时报告 Windows 指引、全部三个 API 成员、windows/<n> 且 n > 0，以及正数的应用程序计数。请单独记录真实 Desktop 重启、授权 UI 和截图结果；外部探测无法证明这些结果。
• Windows 原生 Computer Use 使用窗口 ID。在 @oai/cua 0.2.5 上，随附的 tinysky_alt 代码和文档针对 Windows 提供 cua.listWindows()、cua.listApps() 和 cua.getApp({ windowId })；也提供较低层的 cua.computer.* 窗口 API。较早的 Native app bindings are unavailable for windows. 情形仅适用于已记录的旧版运行时，并非所有 Windows 构建。成功导入运行时或检查源代码，不能替代恢复 ASAR 门控后进行的新 Desktop 捕获。
• 对于受支持的 @oai/sky 0.6.2 跨调用授权配置，scripts\patch-computer-use-node-repl-context.ps1 会报告 patched，SHA-256 为 3600AC240CD6CB7029F1E489DF990CAE22D72177350B8084412DF1F3FA5BB60A；其原始备份与 6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C 匹配。
• 只要适用的包/运行时契约和真实辅助程序枚举都通过，且未启动或激活目标、未发送输入，默认原生 Computer Use 验证即通过。应将原生截图/输入记录为未执行；完成常规修复不要求这些可选检查。
• 用户明确授权进行原生捕获/输入诊断时，应在一次调用中启动持久辅助程序，然后在后续独立调用中针对商定的目标进行操作。检查截图内容并记录每项授权操作的效果。仅有截图数量或 PNG 文件不足以证明捕获成功。用户中断时应停止，不要重新打开或重新激活目标。
• 外部执行器可运行官方运行时的只读枚举，以用于默认验证。通过外部进程进行捕获或输入，与 Desktop 交互一样需要明确授权；这不能绕过该边界。授权进行测试时，应在同一进程中完成捕获和 element_index 输入。Chrome/browser 冒烟验证仍须使用 Desktop 受信任的浏览器通道；环境前提请参阅 references/restriction-debug-cases.md。
• 对于受支持的 Windows 10 截图辅助程序配置，scripts\patch-computer-use-helper-win10.ps1 会报告 patched，并给出所选配置的完整输出 SHA-256；原始备份与该配置的完整输入 SHA-256 匹配。每种已记录配置都包含重复静态资源检查和动态捕获图像变化检查。对应关系如下：0.4.20：F2B2F56F... -> 71A13CBC...，0.5.2：2C4CAC16... -> D816B14A...，0.6.6：BE488E66... -> 34D6EB4F...，0.6.11：DE07F17A... -> 40530E62...，0.6.11：7A95D14E... -> E84A4ECB...，0.6.16：E40BE614... -> F35CA6D8...，以及 0.6.17：29D5E113... -> DC83663F...。一个 @oai/sky 版本可能附带多个辅助程序二进制文件，因此应依据完整哈希选择配置，绝不能仅依据版本字符串。0.6.6 基线包含冷启动后的 Explorer 捕获、两批各十次的静态画面不变捕获、预热后 20 次捕获的资源计数，以及三张不同的 Task Manager 性能画面；0.6.16 基线包含十张相同的静态画面、八张不同的 Performance 选项卡画面、无障碍文本，以及 20 次捕获的资源稳定性样本。0.6.17 基线复用相同的五个受保护区域，并增加八张不同的静态画面、20 张不同的动态画面，以及线程数/句柄数/工作集稳定性样本。动态捕获检查必须激活目标并选择持续动画的视图，因为处于后台的 Task Manager Processes 选项卡不会重绘；因此出现相同画面并非补丁问题。目标还必须是由真实可执行文件拥有的非浏览器窗口：Computer Use 对浏览器窗口操作时会因 could not determine the current browser URL on Windows with enough confidence to enforce policy 而结束回合，且 list_windows 不会枚举由 powershell.exe 承载的窗口。
• 打补丁后的 ASAR 会将 Computer Use 的可用性和安装门控强制设为本地可用。在较新的构建中，这些目标可能合并到 webview\assets\app-initial-*.js，而非旧版的 use-is-plugins-enabled-* 和 use-plugin-install-flow-* 分块。
• 打补丁后的 ASAR 会解除 Fast Mode UI 门控，将 locale 分块中的 enable_i18n 强制设为已启用，并修改 browser_use 功能分块/主功能分发逻辑，使其在本地报告应用内和外部浏览器均可用。Codex Desktop 26.721.3996.0 可以将 Fast UI、模型可见性和 Browser 侧边栏目标合并到 webview\assets\app-initial-*.js。
• 对手机远程控制修复，打补丁后的 ASAR 包含 remote_control_desktop_fetch_override_used、remote_control_auth_token_expired_skipped、remote_control_mobile_setup_no_auth_redirect、remote_control_mobile_setup_authorize_before_enable、remote_control_mfa_info_403_nonblocking、remote_control_client_list_partial_failure_nonblocking、remote_control_settings_force_control_this_pc_visible、remote_control_settings_force_remote_control_section_visible 和 remote_control_qm_start。
• 对带有原生替换项的手机远程控制修复，实时 app\resources\codex.exe 包含 remote_control_app_server_isolated_oauth_used、remote_control_native_remote_json_first、remote_control_websocket_proxy_attempt、remote_control_websocket_proxy_connected、remote-control-oauth.json、remote.json 和 codex.remote_control.enroll。
• 对于手机远程控制的设备列表登录错误，scripts\refresh-remote-control-auth.py --verify-only 会针对 /backend-api/wham/remote/control/clients 报告 ok: true；如果脚本重新生成了身份验证信息，之前的 .codex\remote.json 已备份，且 .codex\auth.json 和 config.toml 未被修改。
• 对于手机远程控制修复，Settings -> Connections 会显示移动设备/手机设置路径，二维码会出现，手机扫描后不再报告 Codex 环境已过期；与 PID/路径关联的原生日志会显示 remote_control_websocket_proxy_connected 和状态 Connected，且不会反复出现 Windows os error 10060；手机发送的回合会到达 Desktop。Ping/Pong 帧文本是可选项，因为某些原生版本会处理这些帧但不记录日志。如果手机发送的回合随后调用了错误的模型 API 端点，应将其作为配对后的配置问题处理。
• 对于 Dynamic Tools Schema 修复，打补丁后的 ASAR 中的 webview\assets\app-server-dynamic-tools-*.js 会返回包含 namespace、name、description 和 inputSchema 的扁平条目，而非 namespace 包装对象；该资源通过 node --check 检查，且 Desktop 实际创建新聊天/线程时不再记录 missing field inputSchema。
• 对于 Provider History Sync，App 和旧版 SQLite 存储均会在当前提供商下报告线程行，可读的 rollout 首行使用当前提供商，会记录 config.toml sha256 unchanged，官方 Desktop 对话会重新出现，且不会新增空项目组。
• 如果启用了 SDK 清理，makeappx.exe 和 signtool.exe 会再次缺失。