将 ChatGPT 和 Codex 迁移到其他盘

我们调查了 ChatGPT 和 Codex 的文件存储位置，将应用本体及其主要数据放在 D 盘，把约 3.78GB 正在使用的运行环境及其他文件留在 C 盘。需要考虑的文件分为三类：应用、已保存的数据和运行环境。

三类主要文件

“把 ChatGPT 相关内容全部移到 D 盘”这个说法太笼统。运行应用的文件与保存对话、设置的文件分属不同位置。应用调用的 CLI、Python、Node 等组件也分别部署在不同位置。

OpenAI 的环境变量文档说明，CODEX_HOME用于设置配置、身份验证、日志、会话、技能及相关状态的根目录。该目录必须事先存在。这项设置不会把应用本体、Windows AppData 及所有相关运行环境一并迁移。

保留 Codex 本地会话，也不等于导出整个 ChatGPT 账号的云端对话历史。我们没有将此次备份视为全部 ChatGPT 数据的完整导出。

哪些原本就在 D 盘，哪些发生了变化

调查开始时，Codex 主目录的实际数据就已经在 D 盘。C 盘的%USERPROFILE%\.codex是一个目录联接（junction），指向 D 盘的CodexHome。也就是说，本次并未将原有约 65GB 主目录数据从 C 盘迁到 D 盘；数据原本就在 D 盘。

目录联接让一个文件夹成为另一个文件夹的访问入口。Microsoft 的文档说明，它可以指向同一台电脑的其他本地卷。从 C 盘入口看到文件，并不一定代表 C 盘另存了一份副本。Microsoft 对目录联接的说明

调查浏览器问题时，这一区别也很重要。我们指定主目录的实际路径，彻底退出应用并重新启动后，内置浏览器和 Chrome 集成恢复了。但没有分别测量路径设置与重启各自的效果。浏览器恢复案例介绍了前后状态及所做的检查。

在应用停止时备份约 68.6GB 数据

改变应用的启动方式之前，我们先停止 ChatGPT、Codex 及 IDE 中相关的 Codex 组件，再进行备份。复制的内容包括 Codex 主目录、应用包的实际存储区域，以及常规 Local AppData 路径下的 OpenAI 文件夹。备份保存在 C 盘，而不是目标盘。

表中是这台电脑在应用停止时创建的备份的逻辑大小。这里的 GB 按十亿字节计算。约 68.6GB 是留在 C 盘的备份大小，不是本次从 C 盘腾出的空间。

备份位置仅允许用户本人和 SYSTEM 访问。由于备份包含身份验证文件和私人对话，本文不附上备份本体。

测试 CODEX_HOME，再检查正常启动

因为主目录原本就在 D 盘，我们先以CODEX_HOME=D:\CodexHome进行一次试启动。保持相同的应用版本，彻底退出后启动新实例。

唯一改动的是用户级的CODEX_HOME变量，没有修改系统级环境变量或 PATH。Windows 环境变量分为进程、用户和系统三个作用域，所以我们检查了正常启动的应用，而不是看到某个 Shell 的值就结束。Microsoft 对环境变量的说明

用于检查存储位置的只读命令

以下 PowerShell 仅会读取值。第一行显示当前 Shell 使用的值；第二、三行显示 Windows 保存的设置；最后一行显示默认主目录的入口。值可能为空，单凭空白结果不能认定数据丢失。

$env:CODEX_HOME
[Environment]::GetEnvironmentVariable('CODEX_HOME', 'User')
[Environment]::GetEnvironmentVariable('CODEX_HOME', 'Machine')
Get-Item -LiteralPath (Join-Path $env:USERPROFILE '.codex') -Force |
  Select-Object FullName, Attributes, LinkType, Target

这里没有移动或删除命令。本次测试的前提是数据已在 D 盘，与直接将设置指向一个空文件夹不同。应用到其他电脑前，应先确定要复制哪些内容、停止哪些应用，以及需要回退时将数据恢复到哪里。

用 Windows 内置功能移动应用

确认主目录设置与浏览器恢复后，操作者在 Windows 应用列表中为 ChatGPT 选择“移动”，将其移至 D 盘。目标是 Windows 管理的 WindowsApps 和 WpSystem。Microsoft 对应用包存储位置的说明

我们核对了移动成功事件、D 盘可执行文件的有效签名（OpenAI OpCo）以及 C 盘的联接。对于应用数据，对应文件夹的设备 ID 和文件 ID 也一致。

单看显示路径，既不能证明迁移成功，也不能证明存在重复占用。我们结合实际位置、引用目标和基本操作进行检查，没有更改 Windows 管理的入口或权限。

为什么约 3.78GB 留在 C 盘

主要组件迁移后，C 盘仍有正在使用的数据。下表汇总了已知的相关存储区域，不会把通向 D 盘的入口重复计入。

这个总量是已知文件夹的逻辑大小，并不涵盖整个 C 盘的更新缓存、还原点，以及每个浏览器或编辑器保存的所有内容。

留在 C 盘的运行环境无需在 D 盘另有对应副本也能工作，因为应用目前使用的就是 C 盘文件。如果误以为已经迁移而将其删除，CLI 或浏览器控制可能会失效。本次最终配置同时使用 C、D 两个盘。

我们也检查了官方的CODEX_INSTALL_DIR变量，但它调整的是独立 CLI 安装程序的安装位置，不会迁移应用管理的全部 CLI 组件和共享运行环境。在 D 盘额外安装 CLI，也不能证明 C 盘现有文件已不再需要。

我们还只读检查了该版本的更新流程，并用小型测试文件夹验证替换行为。在一种配置中，将待更新文件夹设为指向 D 盘的联接后，更新时该联接作为旧版本被移开，同时 C 盘生成了新的普通文件夹。这仅是文件替换测试，不是真实应用的迁移测试。

我们没有为了迁移约 3GB 的运行环境而引入非官方路径和额外的更新后检查。权衡应用及主要数据迁到 D 盘的收益与 C 盘剩余占用后，决定保留正常工作的组件。

迁移后的检查

检查并未止于“应用能启动”。我们把当前保存值与备份进行比较，选中的项目均一致，包括 2 个置顶聊天、18 个置顶项目、63 个本地项目、43 条项目排序记录和 58 条聊天与项目的关联。比较的是所选项目的完整值，而不只是数量。

历史与相关文件方面，备份中的对应文件均存在且可读：sessions 有 459 个，archived_sessions 有 39 个，attachments 有 4 个，automations 有 3 个。缺失文件为 0，读取错误为 0。这是文件存在性检查，不代表重新对每段对话或每个数据库的全部内容进行了哈希校验。

CLI 登录状态检查成功。内置浏览器能读取公开页面、点击链接并返回。我们也在专门的 Chrome 测试标签页检查了读取和导航，随后将其关闭，没有为文章收集现有私人标签页的内容。

我们验证了正常的应用重启，但尚未检查电脑重启或未来应用更新后能否持续正常工作。这两项检查推迟至用户方便时进行，没有只为完成文章再额外重启。

最终保留的配置

在这一范围内，我们认为迁移已完成：直接指定 D 盘主目录的实际路径，将应用和主要数据放在 D 盘，运行环境保留在 C 盘。约 68.6GB 的迁移前备份仍在 C 盘，删除时间由用户另行决定。

迁往其他盘时，重点不是让 C 盘占用归零，而是弄清什么存在哪里、由哪个应用使用，以及保留什么用于恢复。尤其首次将目标注册为 Windows 应用存储位置时，停止计划还必须涵盖同盘的虚拟磁盘和活跃项目。

进行同样迁移时的顺序

1. 将迁移对象分为 Codex 主目录、应用本体及主要应用数据，以及 CLI 等运行环境三类，分别确认它们当前的位置。
2. 除 ChatGPT、Codex 外，也要停止使用目标盘的其他应用（如 Docker 的虚拟磁盘）以及正在进行的项目。
3. 在停止状态下进行备份，比较文件数量和大小；设置、身份验证等重要文件还要比较哈希值。备份应保存在目标盘之外的其他盘。
4. CODEX_HOME 先只用一次启动进行测试，确认基本操作正常后，再设置为用户环境变量。
5. 应用本体用 Windows 的“移动”功能迁移。C 盘上保留的入口（联接）不要删除。
6. 只要应用仍在使用 C 盘上保留的运行环境，就不要删除它。
7. 不要以“能启动”为结束，还要确认已保存的项目、历史文件以及浏览器操作。电脑重启和应用更新后也要再次确认，之后再决定是否删除备份。

常见问题

将 CODEX_HOME 设为 D 盘，会把 ChatGPT 相关内容全部迁过去吗？

不会。它指定的是 Codex 状态数据的根目录。在这台电脑上，应用本体单独迁移，而 CLI、共享运行环境和 VS Code 扩展仍留在 C 盘。

能删除 C 盘里显示的 .codex 或应用文件夹吗？

本次 C 盘中存在通向 D 盘的入口。即使看起来占用空间，也未必是独立副本。删除入口会破坏引用。Windows 创建的管理联接也保留原样。

迁移前的备份可以马上删除吗？

本次没有删除。计划先按新布局继续工作，方便时检查电脑重启或更新后的状态，再由用户决定删除备份的时间。

为了修复浏览器，必须移动应用本体吗？

本次浏览器在应用本体迁到 D 盘前就已恢复，没有依据将移动应用列为浏览器修复的必要步骤。