Codex占满C盘？符号链接迁移数据目录，彻底释放开发缓存空间

C 盘又红了。这次不是电影缓存，也不是微信聊天记录，而是一个开发工具把整个用户目录塞满了。我用 Codex 做了一段时间的 AI 编程辅助，装好 CLI、跑了几次批处理任务、同步了几轮会话记录之后，发现 C 盘可用空间肉眼可见地往下掉。顺着用户目录一层层查下去，问题不只是 Codex 本身，而是所有开发缓存全都默认写进了 C 盘。

这篇文章就围绕一个实测过的问题展开：Codex 装好之后，C 盘空间为什么越来越小？怎么在不卸载工具、不重装系统的情况下，把 C 盘从红色恢复到健康状态？我会从空间定位开始，到 Codex 数据目录迁移，再到 npm、pip、HuggingFace、Windows 系统缓存的整体搬家，最后补上功能验证、批量任务、常见问题和避坑建议。整套流程跑完，腾出几十 GB 到几百 GB 都是可能的，关键是你得先搞清楚谁在占你的 C 盘。

如果你也是 Codex 重度用户，或者 C 盘长期告急，这篇可以直接收藏。

1. 核心能力速览

先用一张表说清楚 Codex 这个工具的性质，以及它在本地磁盘上到底做了什么。

这里的关键点在于：Codex 不像本地部署的大模型那样吃显存，它真正吃的是磁盘和网络。本地装好 CLI 后，模型请求都是发到云端，但你的会话记录、配置文件、日志、临时文件都会留在 C:\Users\你的用户名\ 下面。如果 C 盘本身已经接近满盘，哪怕只增加几个 GB 的缓存，也可能直接导致系统变卡、编译失败、驱动更新失败。

2. 适用场景与使用边界

Codex 适合下面这些读者：

• 日常用 AI 辅助写代码的开发者，需要 CLI 工具而不是网页版。
• 经常跑批处理任务，比如批量重构、批量生成单元测试、批量检查 TODO。
• C 盘空间长期紧张，希望把开发缓存统一迁移到 D 盘或其他数据盘的 Windows 用户。
• 对显存、显卡不敏感，但希望有一个可靠编码助手的用户。

Codex 不适合的场景还是得说清楚：

• 你的代码涉及内部敏感信息，不能发到云端模型处理。这种情况下不适合把真实代码直接交给 Codex，需要先做脱敏。
• 完全离线环境的机器，不适合。
• 把 Codex 当成“本地大模型”来跑的用户，理解有偏差。它不是本地推理工具，而是云端模型加本地 CLI。
• 账号没有 API 权限，或者所在网络环境无法正常访问官方服务时，功能会受限。

需要特别提醒一个使用边界：你在 Codex 会话里输入的代码片段、问题描述、上下文字段，会发送到模型服务端进行处理。所以以下几点必须注意：

• 不要在会话里粘贴未脱敏的内部密钥、用户隐私数据、身份证号等敏感信息。
• 如果要处理公司代码库，先确认公司的外发数据合规要求。
• 使用兼容 OpenAI API 协议的第三方模型服务时，同样要考虑数据合规和授权问题。
• 自动生成的代码可能存在漏洞或误用，提交前要做人工审查。

C 盘清理也有安全边界。不要为了腾空间直接删除 Windows 系统目录、不要关闭关键系统服务、不要随意修改注册表里的系统启动项。涉及恢复分区、系统压缩卷、BitLocker 分区时，优先用系统自带工具和官方文档操作，重要数据先备份。

3. C 盘空间分析与占用定位

在动手清理之前，先搞清楚一个问题：到底是谁把 C 盘吃掉的？

最常见的思路是先看用户目录。用户目录在 Windows 上通常位于 C:\Users\你的用户名，这里面塞满了各类开发工具的数据。Codex 的会话记录也在里面。不要一上来就删文件，先用工具扫描一次。

常用的工具有：

• WizTree：读取 NTFS 主文件表，扫描速度极快，几秒钟就能列出 C 盘大文件排行。
• TreeSize：功能全面，按目录展示占用，适合逐层下钻。
• PowerShell 脚本：纯命令行环境下的备用方案。

如果你不想装第三方工具，可以用 PowerShell 列目录大小。下面这个脚本可以扫描用户目录下的所有子目录，并按大小倒序排列：

powershell复制$target = "C:\Users\你的用户名"
Get-ChildItem $target -Directory -Force -ErrorAction SilentlyContinue |
    ForEach-Object {
        $size = (Get-ChildItem $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue |
                 Measure-Object -Property Length -Sum).Sum
        [PSCustomObject]@{
            Path = $_.FullName
            SizeGB = [math]::Round($size / 1GB, 2)
        }
    } |
    Sort-Object SizeGB -Descending |
    Select-Object -First 20 |
    Format-Table -AutoSize

脚本运行速度取决于磁盘速度，如果目录很大，可能要多等一会儿。真实场景下直接用 WizTree 更省时间。

按我的经验，C 盘空间被吃掉通常集中在下面几类位置：

需要注意的是，WinSxS 目录不能手动删除里面的文件，只能通过系统工具清理组件备份。普通用户如果只是想要空间，不要直接删这个目录。

定位完成之后，再决定清理顺序。我的建议是先处理开发缓存，再处理 Codex 数据目录，最后处理系统级文件。因为系统级操作风险更高，应该放在最后，并且每一步都要确认不影响正常功能。

4. Codex 安装与本地部署

Codex 的安装方式其实不复杂，主要是通过包管理器安装 CLI。以常见方式为例：

bash复制npm install -g @openai/codex

安装完成后，检查版本：

bash复制codex --version

如果命令找不到，说明 npm 全局 bin 目录没有加入 PATH。Windows 下通常需要检查 %APPDATA%\npm 是否在环境变量中，然后重新打开终端。

登录和配置 API Key 的方式有两种。一种是用官方登录流程：

bash复制codex login

另一种是设置环境变量：

bash复制setx OPENAI_API_KEY "你的API密钥"

设置完环境变量后，需要重新打开终端才能生效。新版 Windows 终端也可以直接用：

powershell复制$env:OPENAI_API_KEY = "你的API密钥"

启动交互式会话：

bash复制codex

进入 Codex 终端界面后，可以直接输入自然语言任务，比如“给这个仓库写一个 README 生成脚本”。模型会结合上下文给出代码修改建议或直接执行操作。

Codex 还支持非交互模式，适合自动化脚本和批量任务。基本形式是：

bash复制codex exec "你的任务描述" --skip-git-repo-check

参数细节会随版本变化，运行前先看 codex exec --help。如果你要在现有 Git 仓库内运行，就不需要跳过仓库检查，直接在当前目录执行即可。

Codex 安装本身不会直接占用几个 GB，真正让它变重的，是使用过程中产生的历史会话、日志和缓存结果。这些数据会写进用户目录下的 .codex 文件夹。运行越频繁，数据越多。接下来这一步就是整个清理流程的核心。

5. Codex 数据目录迁移实战

先关闭所有 Codex 进程，再开始迁移。如果有正在运行的会话，先正常退出。

找到 Codex 数据目录。默认一般在：

text复制C:\Users\你的用户名\.codex

里面有配置文件、会话历史、日志、临时文件等。目标是把整个目录搬到 D 盘，然后在原位置建立一个目录符号链接（junction），让 Codex 依然能从原路径读写数据，但实际文件已经落在 D 盘。

建议先在 D 盘建一个统一的数据目录，比如：

text复制D:\DevCache
D:\DevCache\.codex

迁移命令用 robocopy：

cmd复制robocopy "C:\Users\你的用户名\.codex" "D:\DevCache\.codex" /E /COPYALL /DCOPY:DAT /MIR

/E 表示复制所有子目录，/COPYALL 表示复制所有文件属性，/MIR 表示镜像目录。执行完毕后，先不要删除原目录，检查一下目标目录里的文件数量和总大小是否和原目录一致。

确认复制成功之后，再删除原目录，建立符号链接：

cmd复制rd /s /q "C:\Users\你的用户名\.codex"
mklink /J "C:\Users\你的用户名\.codex" "D:\DevCache\.codex"

mklink /J 创建的是目录联接（junction），作用对系统和应用程序完全透明。Codex 认为自己还在读写原来的路径，但实际数据已经落到 D 盘。

用下面的命令验证：

cmd复制dir "C:\Users\你的用户名\.codex"

如果能看到目录内容，并且没有报错，说明符号链接创建成功。

注意一个顺序问题：一定先验证复制结果，再删除原目录。如果 robocopy 还没跑完就删原目录，数据就丢了。删除原目录后，如果符号链接创建失败，可以用新建目录的命令先补救，但不如一次成功省事。

如果你不喜欢符号链接，也有替代方案：把 Codex 的配置目录通过环境变量指向 D 盘。部分 CLI 工具支持通过环境变量指定配置目录，比如 CODEX_HOME。具体是否支持要以你安装的 Codex 版本文档为准。相比之下，符号链接方案的兼容性更好，因为它不需要 Codex 本身支持自定义路径。

Codex 目录迁移成功之后，C 盘能腾出一部分空间。但更重要的目标是后续的会话记录、日志、临时文件全部写入 D 盘，C 盘不再成长。

6. 开发缓存与系统级 C 盘清理

Codex 数据目录迁走之后，马上做第二轮。把开发工具链里的缓存全部从 C 盘搬到 D 盘，或者直接清理掉不要的缓存。

6.1 npm 缓存迁移

bash复制npm config set cache "D:\DevCache\npm-cache"
npm config get cache

迁移完成后，原来的 npm 缓存目录就可以清理了：

cmd复制rd /s /q "C:\Users\你的用户名\AppData\Local\npm-cache"

如果后续发现某些全局命令失效，先确认环境变量和 npm 配置是否生效。

6.2 pnpm 存储迁移

bash复制pnpm config set store-dir "D:\DevCache\pnpm-store"

清理旧存储，需要先在 pnpm store path 里确认旧的存储路径，然后在确认没有项目依赖它之后清理。

6.3 pip 缓存迁移

pip 可以用环境变量：

powershell复制setx PIP_CACHE_DIR "D:\DevCache\pip"

或者用 pip 自带的配置：

bash复制pip config set global.cache-dir "D:\DevCache\pip"

6.4 HuggingFace 模型缓存迁移

如果你经常跑本地模型，HuggingFace 缓存往往很大。设置两个环境变量：

powershell复制setx HF_HOME "D:\DevCache\huggingface"
setx HF_HUB_CACHE "D:\DevCache\huggingface\hub"

旧缓存默认在 C:\Users\你的用户名\.cache\huggingface，确认新缓存生效后再删除。

6.5 临时目录迁移

把系统和用户临时目录改到 D 盘，能明显减少 C 盘碎片文件写入。在系统环境变量里把 TEMP 和 TMP 修改为：

text复制D:\DevCache\Temp
D:\DevCache\Temp

不要直接用 C 盘根目录当临时目录。改完之后重新打开所有终端，再运行一次安装或编译任务，观察临时目录是否会生成文件。

6.6 Windows 系统缓存清理

开发者缓存处理完之后，再做系统级清理。

磁盘清理工具：

cmd复制cleanmgr /d C:

勾选“下载的程序文件”“临时文件”“缩略图”等选项，让系统自动判断哪些可以删。

清理 Windows 组件存储：

cmd复制DISM.exe /Online /Cleanup-Image /StartComponentCleanup

这个命令会清理 WinSxS 目录里旧版本的组件备份，执行时间较长，期间不要关机。

关闭休眠文件。如果这台机器不需要休眠功能，可以执行：

powershell复制powercfg /hibernate off

这会删除 C:\hiberfil.sys，释放的内存容量取决于机器内存大小。

页面文件迁移到 D 盘。在“系统属性” -> “高级” -> “性能设置” -> “高级” -> “虚拟内存”中，把 C 盘的页面文件设为“无”，然后到 D 盘设置“系统管理的大小”或自定义大小。页面文件迁移必须重启生效，且不建议普通用户直接关闭页面文件，容易影响系统稳定性。

清理更新缓存：

cmd复制net stop wuauserv
rd /s /q C:\Windows\SoftwareDistribution\Download
net start wuauserv

如果之前升级过 Windows 并且确认不需要回滚，C:\Windows.old 目录也可以通过磁盘清理工具删除。

系统级清理最关键的原则是：每一项操作都要明白它的作用，确认不影响日常使用后再执行。不要为了省几个 GB 去删不知道用途的文件。

7. 功能测试与效果验证

清理完成不等于清理成功。Codex 要能正常使用，C 盘空间也确实释放了，才算是成功。按下面的顺序做验证。

7.1 验证 Codex 能否正常启动

打开终端，进入任意目录：

bash复制codex

出现交互式界面，说明 Codex 启动正常。再执行一个简单任务：

bash复制codex exec "用 Python 写一个读取 CSV 并输出统计信息的脚本" --skip-git-repo-check

如果命令执行成功，说明符号链接和配置目录都没有问题。

7.2 验证数据是否写入新路径

运行一次 Codex 会话后，检查 D 盘目录：

cmd复制dir "D:\DevCache\.codex"

如果里面的文件修改时间更新了，说明 Codex 确实在往新路径写数据。

7.3 验证 C 盘可用空间变化

清理之前先记录：

powershell复制Get-PSDrive C

清理完成并重启之后，再执行一次：

powershell复制Get-PSDrive C

把两次的 Free 值做对比。不同人机器差异很大，只要空间明显增加，并且 Codex、npm、pip 都能正常工作，就算成功。

判断标准：

• Codex 正常启动，能执行任务。
• npm 安装依赖不报错。
• pip 安装包不报错。
• D 盘出现了新增的缓存目录。
• C 盘可用空间大于清理前。

如果测试阶段发现某个工具找不到配置，不要慌。先检查符号链接是否完整，再检查环境变量是否生效。最坏情况也就是把原目录从回收站恢复或者重新建目录。

8. 接口 API 与批量任务

Codex 的价值不只是交互式聊天。它更适合批量任务。比如给一个项目生成单元测试、扫描所有文件里的 TODO、给每个接口写文档，这类任务一个个手动敲太慢，用脚本循环调用更合理。

Codex 本质上是一个 CLI 客户端，背后走的是模型服务接口。自己写代码调用时，官方接口的模型名、路径、鉴权方式都可能随版本变化，这里给一个通用示例结构，实际调用前必须以官方文档为准。

python复制import requests

headers = {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
}

payload = {
    "model": "MODEL_NAME",
    "messages": [
        {"role": "user", "content": "分析这个项目的目录结构并生成改进建议"}
    ]
}

resp = requests.post(
    "https://api.openai.com/v1/chat/completions",
    headers=headers,
    json=payload,
    timeout=120,
)

print(resp.status_code)
print(resp.json())

如果你接的是兼容 OpenAI 协议的服务商或自建服务，把 URL 和模型名换成自己的即可。对接前确认服务商授权和合规要求。

CLI 批量任务更适合大多数普通场景。把任务写进文本文件，逐行执行：

text复制tasks.txt
为当前项目生成 README 文档
检查所有 Python 文件中的硬编码路径
为 utils 目录生成单元测试

用 Python 脚本循环调用：

python复制import subprocess
import os
import time

tasks = [
    "为当前项目生成 README 文档",
    "检查所有 Python 文件中的硬编码路径",
    "为 utils 目录生成单元测试",
]

os.makedirs("logs", exist_ok=True)

for i, task in enumerate(tasks, 1):
    print(f"--- task {i} ---")
    try:
        result = subprocess.run(
            ["codex", "exec", task, "--skip-git-repo-check"],
            capture_output=True,
            text=True,
            timeout=180,
        )
    except subprocess.TimeoutExpired:
        print(f"task {i} timeout")
        continue

    log_path = f"logs/task_{i}.log"
    with open(log_path, "w", encoding="utf-8") as f:
        f.write(f"STDOUT:\n{result.stdout}\nSTDERR:\n{result.stderr}\n")

    if result.returncode != 0:
        print(f"task {i} failed, log written to {log_path}")
    else:
        print(f"task {i} done")
    time.sleep(2)

批量任务的核心注意事项：

• 给每个任务加超时时间，避免单个任务卡死整个队列。
• 输出结果单独写入日志文件，按任务编号命名。
• 失败任务不要自动重试太多次，建议先看日志再决定。
• 如果任务依赖具体仓库上下文，请先在仓库目录内运行。
• 批处理任务耗时较长，设置合适的时间间隔，避免请求过于密集。

9. 资源占用与性能观察

Codex 云端推理，本地不消耗显卡显存，这是一个容易忽略的优势。你不需要为了 Codex 去买新显卡。但它对网络、CPU、内存和磁盘还是有一定要求的。

建议观察以下几个维度：

在 CPU 和内存方面，简单的代码解释、单次任务不会造成很大压力。真正高负载的场景是批量任务同时跑多个进程，或者在大型仓库里让 Codex 读取大量文件。这时候 CPU 占用会明显上升，尤其是第一次读取目录、构建上下文的时候。

优化建议：

• 批量任务不要一次开太多并发，逐条执行更稳。
• 大型仓库可以先让 Codex 只关注指定目录，减少上下文体积。
• 定期清理 Codex 的会话历史和日志，防止 D 盘缓存无限增长。
• 如果 D 盘是机械硬盘，等待时间会比固态明显，符号链接本身不引入额外性能损失，但目标盘的读写速度会影响体验。

显存占用这块不需要过度担心。Codex 是云端推理，本地没有模型权重文件，不在本地加载大模型。这和本地部署的编程模型有本质区别，也是它能在低配机器上流畅使用的原因。

10. 常见问题与排查方法

清理过程和使用过程中可能会遇到不少问题，这里整理一份排查表。

这里特别解释一下 Codex 报“模型不支持”的情况。这个报错常见于配置了当前账号不可用的模型名，或者工作区模型配置与服务端不匹配。排查时先看报错里的实际模型名，再对比当前账号可用模型。不要把模型名写死在脚本里，建议从环境变量或配置文件中读取。

还有一个高频错误是 cc switch local proxy failed while handling codex endpoint /responses。这个报错和本地代理配置直接相关，是 Codex 在访问 endpoint 时和本地代理发生了连接问题。处理思路是检查本机代理设置是否对 Codex 生效、API endpoint 是否配置正确、防火墙有没有拦截连接，然后按官方网络要求调整即可。

11. 最佳实践与使用建议

这套清理流程跑完，不是说一劳永逸。缓存会继续长，日志会继续写，如果不建立长期习惯，半年后 C 盘还会红。分享几条能落地的建议。

第一，建立一个统一的开发缓存根目录。比如 D:\DevCache，然后把 Codex、npm、pip、pnpm、HuggingFace、临时目录全部指到这里。以后排查空间占用时，只需要看这一个目录。

目录结构可以这样规划：

text复制D:\DevCache
├── .codex
├── npm-cache
├── pip
├── pnpm-store
├── huggingface
└── Temp

第二，先分析再清理。不要看到 C 盘红了就到处删文件。先用 WizTree 扫一遍，找到真正的占用大户，再决定是迁移还是删除。盲目删除很容易把开发环境搞坏。

第三，符号链接一定要“先复制验证，再删除原目录”。robocopy 跑完，先看目标目录大小，再删原目录。只有确认数据完整才能删。

第四，系统级清理最后做。开发者缓存、Codex 数据目录这些迁移完以后，C 盘通常已经释放了大量空间。如果还不够，再一步步处理休眠文件、页面文件、系统更新缓存。每一项系统级操作前都查一下官方文档或者确认当前机器的具体配置。

第五，批量任务要带日志、超时和失败标记。Codex 批量执行任务时，不要把输出只打到控制台，至少要落盘。日志就是排查问题的第一手依据。

第六，环境和密钥管理要规范。API Key 永远不要写进代码仓库。用环境变量管理密钥，敏感操作前脱敏。如果你用的是第三方兼容接口，还要留意服务商的使用条款和授权范围。

第七，Codex 生成的内容要人工复核。尤其是涉及到重构、批量替换、删除代码的任务，自动生成的改动必须经过 review 才能提交。AI 工具提高的是效率，不是替代你的判断。

第八，不要做高风险操作去换空间。比如关闭 Windows 核心服务、删除 WinSxS 里的文件、随意调整系统分区大小。为了 10 GB 空间把系统弄崩，得不偿失。

12. 总结与下一步

这次清理的核心思路很简单：不是卸载 Codex，而是把 Codex 和所有开发缓存的生长路径从 C 盘挪到 D 盘。Codex 数据目录用符号链接迁移，npm、pip、pnpm、HuggingFace、临时目录用环境变量和配置文件迁移，最后再做系统级清理。跑完之后，Codex 照常使用，C 盘可用空间恢复正常，并且后续缓存不会再持续写回 C 盘。

下一步可以继续做的事情有几个方向：

• 如果你用 Docker Desktop，把 WSL 的 vhdx 虚拟磁盘迁移到 D 盘，通常能释放更多空间。
• 如果你用 WSL 2，发行版会占一块不小的虚拟磁盘，迁移命令是 wsl --export 和 wsl --import，迁移前先备份。
• 给 C 盘做一套定期监控，比如每个周末用 PowerShell 记录一次剩余空间，空间低于阈值时自动提醒。
• 把 Codex 的批量任务集成到 CI 流程里，但必须设置严格的模型权限、代码审查和日志留档。

如果你现在的 C 盘已经红色告警，建议从第 3 节开始操作，先定位，再迁移，最后清理。Codex 本身是好工具，问题往往出在磁盘管理和缓存习惯上。这套流程跑完，你的开发机应该会清爽很多。