Codex 桌面版 Windows 安装排障全记录

适用对象：在 Windows 上安装 Codex 桌面版时遇到 Microsoft Store 卡死、winget 商店源异常、AppX 启动失败、PowerShell shell snapshot 崩溃、state db discrepancy 冲突的用户
最终结论：本次问题已经成功绕过并稳定落地，Codex 可以通过本地启动器正常打开使用

情况说明：

在一台 Windows 上安装 Codex 桌面版时，先后遇到了 Microsoft Store 卡死、0x80080005、winget msstore 证书错误 0x8a15005e、AppX 激活错误 0x800705B4、PowerShell shell snapshot 不支持，以及 state db discrepancy 数据状态冲突。最终稳定方案不是继续硬怼 Store 或开始菜单入口，而是：先确认正式包 OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0 已正确安装，再把应用内容复制到本地目录 F:\Codex\CodexDesktopPortable，同时给桌面版单独指定 CODEX_HOME=F:\Codex\codex-desktop-home，并在配置里加入 [features] shell_snapshot = false。之后通过 Start-Codex-Desktop-Portable.cmd 启动，最终可以稳定打开和使用。关键经验是：Windows 上 Codex 桌面版如果和现有 CLI/Cursor 共用 C:\Users\用户名\.codex，很容易出现状态库冲突，所以隔离 CODEX_HOME 往往比反复重装更重要。

---

整理好的Codex Installer.exe、Codex-Windows-x64.msix、Microsoft.DesktopAppInstaller.msixbundle等文件已上传到百度网盘，不必耗费时间再下载。

通过网盘分享的文件：Codex Installer.exe等7个文件
链接: https://pan.baidu.com/s/1btD5ZTg9KWjqacVzPWQq9A?pwd=CODE

一、这份文档记录什么

这不是一篇只写“最后怎么装上”的简略笔记，而是一份完整的安装与排障实录。它覆盖了以下内容：

1. 最初为什么会卡在 Microsoft Store。
2. 为什么 winget 安装也没有直接成功。
3. 为什么即使安装了 AppX 包，Codex 依然可能打不开。
4. 为什么后面又出现了 shell snapshot 和 state db discrepancy 两类崩溃。
5. 最后为什么要改成“本地便携部署 + 独立 CODEX_HOME”。
6. 最终稳定可用的目录结构、启动方式、验证方式、避坑建议。

如果你碰到的现象和下面这些接近，那么这篇记录基本就是对症的：

• Microsoft Store 下载 Codex 一直转圈，长时间不动。
• 商店报错：0x80080005
• winget install --source msstore 报错：0x8a15005e
• AppX 包安装成功，但点开 Codex 没反应，或者报 0x800705B4
• Codex 桌面壳体能起来，但内部 core 崩溃
• 报错里出现 shell snapshot not supported yet for PowerShell
• 报错里出现 state db discrepancy during read_repair_rollout_path: upsert_needed (fast path)

---

二、先给结论：本次最终成功方案

先给最终可用结果，方便只想直接复现的人：

1. 已确认安装的正式包身份

• 包名：OpenAI.Codex
• 完整包名：OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• 安装位置：C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• AppxManifest.xml 中的关键信息：
  • Identity Name="OpenAI.Codex"
  • Version="26.527.3686.0"
  • PublisherDisplayName="OpenAI"
  • Executable="app/Codex.exe"

2. 最终稳定运行的本地部署目录

• 便携可运行目录：F:\Codex\CodexDesktopPortable
• 独立运行数据目录：F:\Codex\codex-desktop-home
• 推荐启动器：F:\Codex\Start-Codex-Desktop-Portable.cmd

3. 最终推荐启动方式

以后不要优先从 Microsoft Store 页面、开始菜单、AppX 默认入口直接启动。
在这台机器上，最稳定的入口是直接双击：

F:\Codex\Start-Codex-Desktop-Portable.cmd

启动器内容如下：

@echo off
set CODEX_HOME=F:\Codex\codex-desktop-home
set CODEX_CI=
set CODEX_INTERNAL_ORIGINATOR_OVERRIDE=
set CODEX_THREAD_ID=
cd /d F:\Codex
start "Codex Desktop" "F:\Codex\CodexDesktopPortable\Codex.exe"

4. 最终成功验证结果

本次已经确认过以下结果：

• Codex 主窗口标题可见：Codex
• 主程序路径：F:\Codex\CodexDesktopPortable\Codex.exe
• 内部 core 路径：F:\Codex\CodexDesktopPortable\resources\codex.exe
• 独立运行目录已实际存在并可写：F:\Codex\codex-desktop-home
• 之前两类核心崩溃点均已绕开：
  • shell snapshot for PowerShell
  • state db discrepancy

---

三、问题背景与机器环境

本次排障发生在一台已经存在多套开发工具、并且本地可能已经在使用 Codex CLI / Cursor 扩展的 Windows 机器上。
这点非常关键，因为它意味着“桌面版问题”并不一定只是桌面版自己的问题，可能还会和已有的 .codex 数据目录发生耦合。

1. 用户目标

用户的目标并不是“理论上装过一次”，而是：

1. 在当前机器上安装 Codex 桌面版 Windows 最新可用版本。
2. 安装后必须真实能打开。
3. 打开后不能只是闪一下或者报错退出。
4. 要确认后续可持续使用。
5. 最终尽量把程序落到当前工作目录一侧，便于管理。

2. 机器上的关键上下文

排障过程中已经确认到的关键环境信息：

• 当前工作主目录：F:\Codex
• 已存在共享 Codex 数据目录：C:\Users\l\.codex
• 本机已经运行过 Codex CLI / 相关扩展
• winget 可以调用，但 Microsoft Store 源状态不健康
• Windows 上的 Store/AppX 激活链路存在异常

也正是因为这些因素叠加，才导致问题不是一个单点故障，而是多个问题串在一起。

---

四、完整时间线：从“商店卡死”到“最终可用”

下面按真实问题推进顺序记录。

阶段 1：Microsoft Store 安装卡住，随后报 0x80080005

最开始的直观现象不是命令行错误，而是图形界面层面的安装卡住：

• 打开 Codex 的 Microsoft Store 页面
• 点击安装
• 安装过程长时间不动
• 最后 Store 提示：

我们已了解此问题，并正在努力解决此问题。请稍后再试。
代码: 0x80080005

这一步说明了什么

这说明问题首先不在“用户不会点安装”，而在 Microsoft Store 自身的分发或激活链路上。
0x80080005 往往意味着 Store / COM / 包管理相关服务链路有异常，但仅凭这个错误码还不能直接定位到最终根因。

这一步的经验结论

如果 Store 图形界面已经明显卡死，不建议继续无休止地在商店窗口里反复点“重试”。
应该尽快转向：

1. winget 检查商店源状态
2. 商店包与 App Installer 状态检查
3. AppX 包安装链路和直接包验证

---

阶段 2：改用 winget，又遇到 0x8a15005e

因为 OpenAI 的 Windows Codex 页面指向的是 Microsoft Store，所以接下来尝试用商店产品 ID 走 winget。

本次识别到的商店产品 ID 为：

9PLM9XGG6VKS

尝试过的典型命令：

winget install --id 9PLM9XGG6VKS --source msstore --accept-package-agreements --accept-source-agreements

结果没有顺利安装，而是报出：

打开源时失败;如果问题仍然存在，请尝试 "source reset" 命令。
0x8a15005e : The server certificate did not match any of the expected values.

这一步说明了什么

这不是 Codex 包本身坏了，而是本机 winget 的 msstore 源访问链路有问题。
更准确地说，是 Store 源证书校验或源元数据缓存出了问题。

为什么这个错误和 0x80080005 不是同一件事

虽然前后都和“安装失败”有关，但两者不完全相同：

• 0x80080005：更偏 Microsoft Store 图形安装通道异常
• 0x8a15005e：更偏 winget 访问 msstore 源时的证书/源验证异常

也就是说，这台机器并不是单纯“商店不好用”，而是“商店 GUI 和 winget Store 源都分别有问题”。

当时采取的方向

排障过程中尝试过以下思路：

1. 重置 winget source
2. 检查 Microsoft.DesktopAppInstaller
3. 检查并重新注册 Microsoft Store 包
4. 并行寻找可验证的 MSIX 安装路径

这一阶段的核心判断是：
不能再把“官方安装成功”完全寄托在单一的 Store GUI 或 winget msstore 上。

---

阶段 3：确认真正的安装对象，避免装错成 CLI 或别的包

在 Windows 上排这类问题，很容易出现一个假成功：

• 以为装好了 Codex 桌面版
• 实际只是系统里已有 npm 版 Codex CLI
• 或者只是打开了商店页面
• 或者只是创建了某个缓存和快捷方式

所以必须先确认“到底要装的是什么”。

本次确认到的目标对象

1. Microsoft Store 产品 ID：9PLM9XGG6VKS
2. 包身份：OpenAI.Codex
3. 实际安装包版本：26.527.3686.0
4. 包内主执行文件：app/Codex.exe

这一步非常重要，因为后面所有验证都要围绕这个对象展开，而不是围绕名字相似的 CLI。

---

阶段 4：绕开 Store 分发故障，转向 MSIX 包安装

因为 Store GUI 和 winget msstore 都不稳定，后续改走 MSIX 包路径。

本次落地到本地的文件为：

F:\Codex\Codex-Windows-x64.msix

同时对安装包做了两类核验：

1. 哈希核验

SHA256  9EACA939262036442A09633031A401112DB54D422BCEC53F7513A0E64B0810D1

2. 安装后包身份核验

通过 Get-AppxPackage -Name OpenAI.Codex 以及 AppxManifest.xml，确认安装对象与目标包一致。

这一步为什么关键

很多“第三方镜像下载”的风险不在于“能不能下载”，而在于“下载的是否真的是对应商店包”。
因此这一阶段不能只看文件名，要看：

1. 安装后包名是否为 OpenAI.Codex
2. 版本号是否正确
3. PublisherDisplayName 是否为 OpenAI
4. Executable 是否为 app/Codex.exe

这些都对上之后，才能继续往后排。

---

阶段 5：AppX 包虽然装上了，但启动阶段又失败，报 0x800705B4

安装完成后，并不代表就能正常打开。

后续从事件日志层面确认到的典型错误为：

0x800705B4: 无法为程序包 OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0 创建进程，因为在准备激活的过程中遇到错误。

这一步说明了什么

这意味着：

1. 包注册本身已经不是主要问题
2. 问题已经进入到 AppX 激活 / 运行时容器准备阶段
3. “安装成功”与“可以稳定启动”是两回事

为什么这一步特别麻烦

因为从用户视角看，会误以为“明明已经装好了，为什么还是不能用”。
实际上：

• 安装链路解决的是包落地和注册问题
• 启动链路解决的是运行时激活、容器准备、配置初始化、内部 core 拉起问题

本次故障后半段主要就集中在这里。

---

阶段 6：Codex 壳体起来了，但内部 core 因 shell snapshot 崩溃

继续推进后，Codex 桌面壳体已经能部分起来，但内部 core 又报错。

关键报错信息如下：

codex_core::shell_snapshot: Failed to create shell snapshot for powershell:
Shell snapshot not supported yet for PowerShell

在本机日志中也能直接找到类似记录：

C:\Users\l\.codex\log\codex-tui.log
WARN ... codex_core::shell_snapshot: Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

这一步的根因

根因不是“PowerShell 坏了”，而是当前这版 Codex 在该启动路径下尝试为 PowerShell 创建 shell snapshot，而这条路径本身还不支持。

换句话说：

• 桌面版不是死在 UI
• 也不是死在安装包
• 而是死在会话初始化时的 shell 快照功能

这一步的修复方法

找到并加入一个非常关键的配置：

[features]
shell_snapshot = false

本次实际处理方式是先备份原配置，再只增加这一项，不去碰其它模型、认证、项目信任配置。

为什么这个配置能解决问题

因为它等价于告诉 Codex：

启动会话时不要去抓 PowerShell 的 shell snapshot。

这样就直接绕开了当前版本对 PowerShell 快照不支持的路径。

这一步的经验结论

如果你在 Windows 上启动 Codex 桌面版，看到的错误里明确出现：

• shell_snapshot
• PowerShell
• Shell snapshot not supported yet for PowerShell

那么优先级最高的动作之一，就是检查 config.toml 里是否有：

[features]
shell_snapshot = false

---

阶段 7：shell_snapshot 修好后，又撞上 state db discrepancy

修完 PowerShell 快照问题后，Codex 又不是立刻就万事大吉。
紧接着出现了第二类更隐蔽的崩溃：

codex_rollout::state_db: state db discrepancy during read_repair_rollout_path:
upsert_needed (fast path)

这类错误的麻烦在于：

1. 看起来不像图形界面错误
2. 看起来不像安装错误
3. 很容易让人误以为“是不是数据库坏了，删掉就行”

但这里最危险的地方恰恰是：
这台机器并不是只有桌面版在用 Codex 运行时数据目录。

根因分析

本次最终定位到的真实根因是：

Codex 桌面版与现有 Codex CLI / Cursor 相关运行环境，共用了同一个 C:\Users\l\.codex。

共享同一个 .codex 目录会带来几个问题：

1. 状态库可能被多个客户端交替写入
2. rollout path / state DB 的读修复逻辑可能出现不一致
3. 桌面版和 CLI 并不一定按完全相同的时机、相同的假设去维护这些状态文件
4. 一旦并发或路径假设不一致，就可能触发 read_repair_rollout_path 相关报错

为什么这里不能粗暴删除一切状态文件

因为排障时当前对话本身就可能运行在另一个 Codex/CLI 进程之上。
如果你直接按名字批量 Stop-Process codex* 或者粗暴删除共享 .codex 下所有状态库，可能会：

1. 误杀当前命令行会话
2. 破坏已有 CLI 会话状态
3. 让问题从“桌面版打不开”扩大成“全局 Codex 环境一起坏掉”

所以这一阶段的正确思路不是“清空共享库”，而是：

给桌面版彻底隔离出一个独立的 CODEX_HOME。

---

阶段 8：最终稳定方案不是继续硬怼 AppX，而是本地便携化运行

到这里，已经可以得出很明确的判断：

1. Store GUI 不稳定
2. winget msstore 源不稳定
3. AppX 默认激活链路不稳定
4. PowerShell shell_snapshot 要绕开
5. 共享 .codex 目录会引发状态库冲突

在这种前提下，继续把全部希望寄托在“开始菜单那个 AppX 快捷方式终于某次能顺利启动”，价值已经不大。

所以最后采用了更稳妥的方案：

最终方案核心

1. 保留已经正确安装好的 OpenAI.Codex 包
2. 从其安装目录中复制真实可执行应用内容
3. 落地到本地目录 F:\Codex\CodexDesktopPortable
4. 给桌面版单独指定 CODEX_HOME=F:\Codex\codex-desktop-home
5. 用本地启动器运行

实际复制来源

来源目录：

C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app

目标目录：

F:\Codex\CodexDesktopPortable

复制方式本次使用的是 robocopy。

为什么这一步有效

因为它同时绕开了两类问题：

1. AppX 默认激活链路问题
   不再强依赖开始菜单 / Store 的那套入口。

2. 共享运行时状态目录问题
   通过独立 CODEX_HOME，让桌面版不再与现有 CLI 共享 C:\Users\l\.codex。

这一步不是“破解”，而是“本地部署”

这点需要说清楚。
本次不是随便找个未知来源绿色版，而是：

1. 先确认安装对象是正确的 OpenAI.Codex
2. 再从已安装包的应用目录复制出可运行内容
3. 然后把运行时数据彻底独立

本质上，这是在现有系统环境异常时，对已验证安装内容做本地可控部署。

---

五、最终目录结构

最终建议保留的目录结构如下：

F:\
└─Codex
  ├─CodexDesktopPortable
  │  ├─Codex.exe
  │  ├─resources\
  │  └─...
  ├─codex-desktop-home
  │  ├─config.toml
  │  ├─auth.json
  │  ├─state_*.sqlite
  │  ├─goals_*.sqlite
  │  ├─logs_*.sqlite
  │  └─...
  ├─Start-Codex-Desktop-Portable.cmd
  ├─Start-Codex-Desktop.ps1
  ├─Codex-Windows-x64.msix
  ├─Codex Installer.exe
  └─Codex-StoreInstaller.exe

其中真正建议长期使用的是：

• F:\Codex\CodexDesktopPortable
• F:\Codex\codex-desktop-home
• F:\Codex\Start-Codex-Desktop-Portable.cmd

---

六、关键命令与每一步的意义

下面把本次排障中最重要的命令按作用整理出来。

1. 检查已安装 AppX 包

Get-AppxPackage -Name OpenAI.Codex | Select-Object Name,PackageFullName,Version,InstallLocation,Status

意义：

• 检查系统是否真的已经注册了 OpenAI.Codex
• 检查版本号是否正确
• 确认安装路径

2. 检查包清单

Get-Content 'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\AppxManifest.xml'

意义：

• 核对 Identity Name
• 核对 Version
• 核对 PublisherDisplayName
• 核对 Executable

3. 安装 MSIX 包

Add-AppxPackage -Path 'F:\Codex\Codex-Windows-x64.msix'

意义：

• 绕开 Microsoft Store GUI 的卡死
• 直接把包交给系统的 AppX 安装链路

4. 修复 shell_snapshot

关键配置：

[features]
shell_snapshot = false

意义：

• 禁用对 PowerShell 的 shell snapshot 尝试
• 绕过当前版本不支持 PowerShell shell snapshot 的问题

5. 创建独立桌面版 home

本次最终使用的独立 home 为：

F:\Codex\codex-desktop-home

意义：

• 彻底切断与 C:\Users\l\.codex 的共享状态耦合
• 让桌面版维护自己的状态库、日志、session、插件缓存

6. 复制已安装应用到本地目录

逻辑上相当于：

$src = 'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app'
$dst = 'F:\Codex\CodexDesktopPortable'
robocopy $src $dst /E

意义：

• 把已验证的应用内容拷贝到本地可控目录
• 不再强依赖开始菜单/AppX 默认入口

7. 通过启动器指定独立 CODEX_HOME

set CODEX_HOME=F:\Codex\codex-desktop-home

意义：

• 不与共享 .codex 再发生状态冲突

---

七、为什么最终一定要用独立 CODEX_HOME

这是整篇记录里最值得强调的技术结论之一。

很多人排到这里会想：

既然 shell_snapshot 修好了，为什么不直接继续用默认配置？

答案是：因为默认配置目录还会继续引出下一层问题。

1. 默认共享目录的问题

默认共享目录：

C:\Users\l\.codex

这个目录在本机上已经不是“桌面版专用”目录，而是一个可能被多端复用的目录：

• Codex CLI
• Cursor / 相关扩展
• 历史会话
• 插件缓存
• rollout 状态
• sqlite 状态库

2. 桌面版最怕的不是“目录存在”，而是“共享同一份可变状态”

如果只是共享静态配置，问题还不一定马上爆炸。
真正危险的是共享以下这些可变状态：

• state_*.sqlite
• goals_*.sqlite
• logs_*.sqlite
• .codex-global-state.json
• session / rollout 相关状态

这些东西一旦被不同客户端按不同节奏写入，就可能出现：

• 读修复逻辑触发
• 状态路径不一致
• 数据快照与当前客户端预期不一致

3. 独立 CODEX_HOME 的收益

独立 CODEX_HOME 带来的收益非常直接：

1. 桌面版拥有单独的状态库
2. 不会再与 CLI 共用 rollout/state DB
3. 后续即使需要清理桌面版状态，也只需要动 F:\Codex\codex-desktop-home
4. 不会误伤现有 C:\Users\l\.codex

这一步相当于把问题从“全局环境纠缠”变成“桌面版自己的局部问题”，后续维护会简单很多。

---

八、最终稳定配置的最小必要内容

为了方便复现，这里只保留与本次问题直接相关的最小配置片段。
任何认证、第三方接口地址、密钥、个性化模型配置都不应直接公开分享到社区。

1. 最小必要配置片段

[features]
shell_snapshot = false
js_repl = false

2. 这份配置为什么要“最小暴露”

因为本机的实际 config.toml 里还可能包含：

• 模型提供商配置
• 自定义 API 地址
• API key
• 继承到 shell 的环境变量
• 认证相关内容

这些都不应该原样贴到博客或社区。

3. 分享配置时的建议

公开文档中建议只展示：

1. 与故障直接相关的配置项
2. 目录结构
3. 启动器内容
4. 命令和错误码

不要公开：

1. auth.json
2. 完整 config.toml
3. 任何 token / key / base URL
4. 浏览器或插件信任信息

---

九、验证“真的修好”应该看什么

很多安装记录最大的问题是：只写“成功了”，但没有写“怎么确认是真的成功”。
这里给出一套更可靠的验证标准。

1. 包注册层验证

确认系统中存在：

Get-AppxPackage -Name OpenAI.Codex

应看到：

• Name = OpenAI.Codex
• Status = Ok
• Version = 26.527.3686.0

2. 本地部署文件层验证

确认文件存在：

• F:\Codex\CodexDesktopPortable\Codex.exe
• F:\Codex\Start-Codex-Desktop-Portable.cmd
• F:\Codex\codex-desktop-home\config.toml

3. 运行态验证

启动后，至少要再确认：

1. 主窗口标题确实是 Codex
2. 主进程路径来自 F:\Codex\CodexDesktopPortable\Codex.exe
3. 内部 core 路径来自 F:\Codex\CodexDesktopPortable\resources\codex.exe
4. 没有再次弹出 shell snapshot 报错
5. 没有再次弹出 state db discrepancy 报错

4. 重启验证

真正稳不稳，不是看“第一次是否碰巧成功”，而是看：

1. 关闭 Codex
2. 再次双击 Start-Codex-Desktop-Portable.cmd
3. 是否还能稳定打开

如果你只成功过一次，但第二次又崩，那就不能算真正修好。

---

十、这次排障里最容易踩的坑

坑 1：把 Microsoft Store 故障误认为 Codex 包损坏

Store 卡死并不等于 Codex 包本体损坏。
很多时候是本机商店通道有问题。

坑 2：把 winget 失败误认为“官方没有 Windows 版”

本次 winget 报 0x8a15005e，本质是 Store 源验证异常，不是“没有这个包”。

坑 3：看到 AppX 安装成功，就以为一定能启动

不是。
AppX 安装成功只说明包注册成功，不代表激活链路和内部 core 都正常。

坑 4：看见数据库错误就删整个 C:\Users\l\.codex

非常不推荐。
这样很可能顺手把已有 CLI / Cursor 相关环境一起打坏。

坑 5：按进程名批量杀 codex

同样危险。
如果当前还有 Codex CLI 会话正在工作，可能会把正在用的进程也一起杀掉。

坑 6：把完整配置文件原样发到社区

这是安全问题，不是美观问题。
config.toml、auth.json、环境变量内容都必须脱敏。

---

十一、如果以后再次出现类似问题，建议按这个顺序排

下面给一个比这次更干净的排查顺序。

第一步：先分辨是哪一层出错

按错误现象分层：

1. Store 图形界面卡住
   优先怀疑 Microsoft Store / App Installer

2. winget msstore 报错
   优先怀疑 Store 源或证书/缓存

3. AppX 已装但打不开
   优先怀疑 AppX 激活链路、运行时准备

4. 打开后 core 崩溃
   优先检查 shell_snapshot、配置、日志

5. 报 state db discrepancy
   优先检查是否共享了 .codex

第二步：先保留证据，再改配置

建议先保存：

• 错误弹窗截图
• 终端报错截图
• Get-AppxPackage 输出
• 事件日志关键报错
• config.toml 备份

第三步：不要优先删共享目录

优先选择：

1. 新建独立 CODEX_HOME
2. 用独立目录验证是否恢复

如果独立目录可以恢复，那基本就说明问题确实出在共享状态污染，而不是程序本体。

第四步：只有在需要时才清理桌面版独立状态

如果未来独立目录自己又出状态问题，清理时建议只清理：

F:\Codex\codex-desktop-home

而不是先去动：

C:\Users\l\.codex

---

十二、面向社区分享时建议怎么写

如果你准备把这次经历发到博客、社区、论坛、小红书、知乎或 GitHub Issues，建议按下面这个逻辑写，别人最容易看懂：

1. 先写“现象”

例如：

• Store 卡死
• 0x80080005
• winget 报 0x8a15005e
• AppX 激活报 0x800705B4
• shell snapshot PowerShell 不支持
• state db discrepancy

2. 再写“每个现象对应哪个层级”

例如：

• Store 层
• winget Store 源层
• AppX 激活层
• Codex core 初始化层
• 运行时状态数据库层

3. 再写“为什么最终要用独立 CODEX_HOME”

这是整篇最有价值的经验点，远比一句“我最后重装好了”更有帮助。

4. 最后给出“最终可复现方案”

包括：

• 目录结构
• 启动器内容
• 关键配置
• 验证方式

这样别人才能真正照着复现，而不是只得到一堆零碎报错图。

---

十三、报错情况清单

插图 1：Microsoft Store 错误

建议内容：

• Store 页面
• 错误文案
• 0x80080005

插图 2：winget 商店源证书错误

建议内容：

• 终端命令
• 0x8a15005e
• The server certificate did not match any of the expected values

建议插图 3：shell snapshot 崩溃

建议内容：

• Codex 弹窗或终端日志
• shell snapshot
• PowerShell

建议图注：

图 3 Codex 启动后内部 core 因 PowerShell shell snapshot 不支持而崩溃

建议插图 4：state db discrepancy

建议内容：

• 崩溃弹窗
• 日志
• read_repair_rollout_path
• upsert_needed (fast path)

图 4 桌面版与共享 .codex 目录冲突，触发 state db discrepancy

建议插图 5：最终运行成功界面

建议内容：

• Codex 主窗口

• 本地启动器已成功打开

图 5 通过 Start-Codex-Desktop-Portable.cmd 成功打开 Codex

---

十四、最终沉淀下来的经验结论

把这次全过程压缩成几句话，核心经验其实只有四条：

1. Store 能不能装上，和 Codex 包本身好不好，是两回事。
2. AppX 装成功，和桌面版能不能稳定打开，也是两回事。
3. shell_snapshot = false 能解决 PowerShell 快照崩溃，但不能解决共享状态库冲突。
4. 在这类混合环境里，最稳的方案往往是“本地便携部署 + 独立 CODEX_HOME”。

如果以后再次遇到类似问题，我个人不会再从“疯狂重装商店”开始，而会更快地做下面这几个动作：

1. 核验目标包身份
2. 分离安装问题与启动问题
3. 尽快关闭共享 .codex 带来的干扰
4. 直接建立独立运行目录验证

这能比单纯反复点“重试”节省很多时间。

---