Codex与开发工具缓存迁移：彻底解决C盘空间告急

1. C盘又红了Codex、缓存和自动化工具的“三座大山”最近在本地开发时发现 C 盘空间又亮起了红灯清理完临时文件、回收站之后没过多久空间又被打回原形。仔细排查了一遍磁盘占用发现问题主要集中在三个方向Codex 的配置与缓存数据、各类 IDE 和工具的插件目录、以及自动化脚本运行过程中产生的日志与临时产物。这三个部分都属于“看起来不起眼、用起来疯狂占空间”的类型而且它们的默认存放位置几乎都写死在 C 盘的用户目录下面。对于习惯使用 Codex 作为编程助手的开发者来说这个问题会更加明显。Codex 在运行时会缓存 AI 响应、维护会话历史、保存身份认证信息同时还会在本地保存大量模型调用相关的临时文件。如果你的 Codex 配置还关联了插件市场、harness 插件的扩展机制那 C 盘占用就会进一步恶化。更麻烦的是如果只是粗暴地删除这些文件会导致 Codex 登录状态丢失、会话上下文被清空甚至引发启动失败的问题。本文把整个迁移过程拆解了一遍包含 Codex 配置目录分析、缓存迁移、插件目录重定向、自动化脚本日志分流、常见异常排查以及一套可以复用的 C 盘清理策略。对于已经被磁盘占用困扰、想彻底把开发环境从系统盘“请出去”的开发者这篇文章可以直接当作操作手册来用。2. Codex 到底把什么数据写进了 C 盘目录结构与关键文件2.1 .codex 目录是什么Codex 在 Windows 下的默认配置目录是C:\Users\你的用户名\.codex。这个目录和很多 CLI 工具的配置目录规则一致都遵循了“用户级配置放用户目录”的惯例。目录里面保存的内容可以大致分成四类内容类别典型文件/目录作用主配置文件config.toml模型参数、代理设置、API 基础地址、超时时间等认证信息auth.json登录凭证、API Key 或令牌敏感文件会话与历史sessions、history等对话历史、上下文记忆可帮助 Codex 维持连续性缓存与临时文件cache、logs、tmp等模型响应缓存、运行日志、临时生成文件重点要说一下config.toml它是整个 Codex 行为的“总开关”。迁移配置时这个文件必须保留而且里面的路径如果是绝对路径还需要在迁移后同步调整。2.2 为什么 C 盘空间会快速耗尽Codex 的缓存机制和传统 IDE 的缓存不太一样。它不只是缓存界面状态或编译中间文件而是会缓存大段的模型回复内容、代码补全片段、工具调用结果。每次和模型交互产生的上下文数据可能从几 KB 到几百 KB 不等。随着使用频次增加这些会话文件和缓存文件会像滚雪球一样增长。此外如果 Codex 开启了插件机制例如接入 deepseek harness 插件或者其他自定义插件插件自身的下载包、依赖库、中间产物也会落在用户目录中。再加上 VS Code 插件、PyCharm 插件、npm 全局缓存、pip 缓存C 盘被塞满只是时间问题。2.3 迁移的基本思路迁移的思路不是简单地“把文件剪切到 D 盘”而是要让 Codex 在启动时自动去新的位置读写数据。常见做法有三种修改环境变量让程序从新的路径加载配置和缓存。修改config.toml中的路径属性把输出目录指到 D 盘。使用目录联接junction技术把原来的 C 盘路径“指向” D 盘真实目录。三种方案各有优劣。修改环境变量最干净但不是所有工具都支持修改配置文件最直接但要逐项核对配置项目录联接最“无感”迁移后原路径依然可以访问但对操作准确性要求较高不能删错。3. 动手迁移 Codex 到 D 盘从环境变量到配置文件3.1 第一步查看当前 Codex 配置位置先确认 Codex 的配置目录当前在哪里以及里面的文件结构。打开 PowerShell 或 CMD执行以下命令cd %USERPROFILE%\.codex dir如果目录存在你会看到类似下面的文件列表auth.json config.toml sessions/ logs/ cache/ plugins/如果使用的是 PowerShell可以用Get-ChildItem查看得更细致Get-ChildItem -Force $env:USERPROFILE\.codex3.2 第二步迁移配置文件到 D 盘建议先创建一个规范的目标目录例如New-Item -ItemType Directory -Force -Path D:\DevData\Codex然后把.codex目录下的内容整体复制过去。复制时需要注意如果 Codex 正在运行最好先退出相关进程否则可能有文件被占用。Copy-Item -Path $env:USERPROFILE\.codex\* -Destination D:\DevData\Codex\ -Recurse -Force复制完成后不要急着删除原目录。先把原目录改名作为备份例如改为.codex_backupRename-Item -Path $env:USERPROFILE\.codex -NewName .codex_backup这一步非常重要原因有两个如果新路径配置有问题可以快速回滚。防止某些进程还在使用旧路径导致启动失败。3.3 第三步设置环境变量 CODECX_HOME 或修改 config.tomlCodex 在寻找配置目录时一般会优先读取环境变量。常见的环境变量名包括CODEX_HOME但不同版本可能有差异。如果你不确定当前版本支持哪个变量最稳妥的方式是查看官方文档或者在终端中运行codex --help查看是否有类似--config或--home的参数。如果环境变量没有生效可以修改配置文件中的相关路径。打开D:\DevData\Codex\config.toml将需要重定向的目录配置修改为绝对路径。例如[storage] cache_dir D:/DevData/Codex/cache session_dir D:/DevData/Codex/sessions log_dir D:/DevData/Codex/logs注意不同版本的 Codex 配置项命名可能有差异如果storage段不存在可以把需要重定向的目录通过环境变量或启动参数方式传入。设置系统环境变量的方式如下[System.Environment]::SetEnvironmentVariable(CODEX_HOME, D:\DevData\Codex, User)配置完成后新开的终端窗口会自动生效。一定要重新打开终端再启动 Codex因为环境变量的读取发生在进程启动时。3.4 第四步创建目录联接可选但推荐如果你的 Codex 版本对环境变量支持不够好或者某些插件仍然把路径写死在%USERPROFILE%\.codex可以使用目录联接方案。命令如下mklink /J C:\Users\你的用户名\.codex D:\DevData\Codex执行这个命令前必须确保原本的.codex目录已经被改名或删除。/J参数表示创建目录联接Junction和符号链接Symbolic Link不同目录联接在 Windows 上创建时不需要管理员权限而且兼容性更好。创建成功后对系统和其他程序来说C:\Users\你的用户名\.codex仍然存在但实际数据都写入 D 盘。这种方式对 Codex、插件、自动化脚本都完全透明。4. 插件与依赖缓存迁移给 VS Code、npm 和 pip 瘦身4.1 Codex 插件目录迁移Codex 支持插件体系后插件本身及其依赖会占据不少空间。插件目录通常在.codex\plugins下。迁移时只需要跟随 Codex 配置目录一起搬走。如果插件配置中写死了路径需要在插件的配置文件里同步修改。以 deepseek harness 插件为例这类插件通常会缓存模型调用参数、本地向量索引或测试运行日志体积增长比较明显。迁移后如果插件找不到缓存可能表现为响应变慢或功能异常这时可以重新生成缓存目录或检查插件配置中的cache_path参数。4.2 VS Code 插件迁移VS Code 的插件默认存储在C:\Users\你的用户名\.vscode\extensions这个目录可以说是 C 盘空间杀手装的插件多了以后轻松超过 5GB。迁移方式同样是“复制 设置启动参数”。先把插件目录复制到 D 盘Copy-Item -Path $env:USERPROFILE\.vscode\extensions -Destination D:\DevData\VSCode\extensions -Recurse -Force然后修改 VS Code 快捷方式在目标后面增加参数--extensions-dir D:\DevData\VSCode\extensions如果你使用命令行启动 VS Code可以写成code --extensions-dir D:\DevData\VSCode\extensions如果不想每次手动加参数也可以设置环境变量[System.Environment]::SetEnvironmentVariable(VSCODE_EXTENSIONS, D:\DevData\VSCode\extensions, User)4.3 npm 全局缓存迁移npm 的缓存目录通常在C:\Users\你的用户名\AppData\Local\npm-cache里面是 npm 下载过的所有包压缩文件。迁移时先执行npm config get cache确认当前缓存位置然后设置为新路径npm config set cache D:\DevData\npm-cache如果想验证设置是否生效npm config get cache同理pnpm 和 yarn 也支持通过配置项或环境变量修改存储路径。pnpm 的全局存储目录可以用pnpm config set store-dir D:\DevData\pnpm-storeyarn 可以使用yarn config set cache-folder D:\DevData\yarn-cache4.4 pip 缓存迁移Python 开发者的 pip 缓存也会占用大量空间。查看当前缓存目录pip cache dir修改缓存路径可以通过环境变量实现[System.Environment]::SetEnvironmentVariable(PIP_CACHE_DIR, D:\DevData\pip-cache, User)5. 自动化脚本和数据产物的重定向方案5.1 为什么自动化脚本也会占 C 盘自动化测试、爬虫脚本、数据处理脚本在运行时往往会在用户目录下输出日志、临时文件、下载文件、测试报告。例如 Jenkins 的 workspace、pytest 的.pytest_cache、Playwright 的浏览器缓存和测试产物这些目录如果不加约束默认都会写入 C 盘。5.2 在脚本中规范化输出路径与其等到 C 盘满了再清理不如从一开始就把脚本的输出路径设计为可配置。以 Python 脚本为例可以使用环境变量来动态拼接路径import os from pathlib import Path data_root Path(os.getenv(DEV_DATA_ROOT, D:/DevData)) log_dir data_root / logs cache_dir data_root / cache output_dir data_root / output for d in [log_dir, cache_dir, output_dir]: d.mkdir(parentsTrue, exist_okTrue)这样日志和缓存都统一收敛到D:\DevData下C 盘完全不受影响。5.3 pytest 缓存迁移pytest 会在项目根目录或用户目录生成.pytest_cache里面保存所有测试节点的收集信息。可以通过参数关闭或修改缓存目录pytest -p no:cacheprovider也可以使用配置项# pytest.ini [pytest] cache_dir D:/DevData/pytest-cache5.4 Playwright 缓存迁移Playwright 的浏览器和缓存默认位于用户目录。执行以下命令可以查看npx playwright install --list如果要修改缓存路径可以设置环境变量[System.Environment]::SetEnvironmentVariable(PLAYWRIGHT_BROWSERS_PATH, D:\DevData\Playwright\browsers, User)这个变量会让 Playwright 把浏览器安装到 D 盘而不是默认的C:\Users\用户名\AppData\Local\ms-playwright。5.5 Jenkins 工作目录迁移如果本地使用 Jenkins 做自动化测试默认的JENKINS_HOME也可能在 C 盘。迁移方式就是把环境变量指到新路径[System.Environment]::SetEnvironmentVariable(JENKINS_HOME, D:\DevData\Jenkins, User)修改完成以后重启 Jenkins 服务才会生效。最好在停止服务后再迁移原有数据避免数据不一致。6. 常见问题与排查思路问题现象可能原因解决思路Codex 启动后找不到历史会话环境变量未生效或会话路径配置错误重新打开终端执行echo $env:CODEX_HOME或echo %CODEX_HOME%确认环境变量迁移后 Codex 登录状态丢失只迁移了配置文件没迁移auth.json将备份目录中的auth.json复制到新目录并检查文件权限出现cc switch local proxy failed while handling codex endpoint /responses报错本地代理服务地址失效或配置中的代理参数不完整检查config.toml中代理相关配置确认地址和端口正确然后重启 CodexVS Code 插件不加载快捷方式未加--extensions-dir参数重新创建快捷方式或在命令行中使用完整参数启动目录联接创建失败原.codex目录仍然存在先改名或删除原目录再执行mklink /Jnpm 缓存迁移后下载仍然很慢缓存目录权限不足或网络问题检查D:\DevData\npm-cache是否有读写权限尝试执行npm cache verify删除旧目录后 Codex 启动报错某些进程仍占用了旧路径的动态链接文件注销并重新登录 Windows或在安全模式下清理旧目录重点说一下 proxy 报错这个场景。最近不少 Codex 用户反馈在请求/responses端点时出现cc switch local proxy failed while handling codex endpoint /responses.这类问题往往不是 Codex 主程序的问题而是本地代理转发服务没有正确处理请求。排查思路如下查看config.toml中的代理配置确认是否填写了正确的本地服务地址。启动代理服务后先用浏览器或 curl 测试代理服务是否可用。检查防火墙或安全软件是否拦截了 Codex 到本地代理的连接。如果代理配置指向的是内网网关还要确认网关白名单是否包含当前用户。如果是刚完成配置迁移后出现的这个报错优先检查迁移后的config.toml中是否有硬编码的旧路径以及环境变量是否互相冲突。7. 磁盘清理的延伸方案哪些缓存可以放心删除了迁移C 盘清理也需要知道哪些缓存可以放心删除。缓存位置是否可以删除删除后影响C:\Users\用户名\AppData\Local\Temp可以删除未占用文件正在使用的临时文件会被跳过不影响系统C:\Users\用户名\AppData\Local\npm-cache可以删除下一次npm install会重新下载依赖C:\Users\用户名\AppData\Local\pip\cache可以删除pip 会重新下载安装包C:\Users\用户名\AppData\Local\Microsoft\Windows\Explorer建议手动清理缩略图缓存删除后缩略图会重新生成Chrome/Edge 缓存可以删除浏览器会重新拉取资源首次打开可能稍慢C:\Users\用户名\.codex不建议直接删除会丢失登录状态和会话历史建议先迁移备份C:\Users\用户名\.vscode\extensions不建议直接删除删了以后所有插件需要重装建议迁移这里的核心原则是有配置属性的目录优先迁移纯缓存目录可以删除混合型目录先备份再处理。8. 最佳实践与工程建议8.1 建立统一的开发数据目录建议在 D 盘建立整套开发数据目录而不是每个工具各自散落。例如D:\DevData\ Codex\ VSCode\ npm-cache\ pip-cache\ Playwright\ Jenkins\ logs\ output\这样做的优势是备份容易、迁移方便、目录结构一目了然。后续给每台新电脑配置开发环境时只需要复制这一个目录。8.2 环境变量管理要集中不要只设置一两个环境变量就完事。建议在 Windows 的“环境变量”面板中统一维护一个命名规范的区域例如所有开发工具的路径都以D:\DevData作为前缀。同时把环境变量配置写进一份 Markdown 笔记或 PowerShell 初始化脚本中方便重装系统后快速恢复。8.3 定期执行磁盘占用巡检建议每两周执行一次简单的巡检命令如下Get-ChildItem D:\DevData -Recurse -Directory | ForEach-Object { $size (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Path $_.FullName; SizeMB [math]::Round($size / 1MB, 2) } } | Sort-Object SizeMB -Descending | Select-Object -First 20这段脚本会列出 D 盘开发数据目录下体积最大的前 20 个子目录方便快速定位是什么占满了空间。8.4 登录态和敏感信息的安全边界迁移auth.json这类认证文件后如果电脑需要借给别人使用或者有安全审计要求建议把该文件的访问权限收紧。右键点击auth.json在“安全”选项卡中只保留当前用户的读取权限其他用户全部移除。此外不要把auth.json提交到 Git 仓库.gitignore 中一定要加上**/auth.json **/config.toml8.5 自动化脚本的路径设计原则自动化脚本在路径设计上要遵循“环境变量优先、配置文件次之、硬编码兜底”的原则。不要把路径写死在代码里因为换一台机器就失效了。推荐的做法是import os from pathlib import Path def get_cache_dir(): cache_env os.getenv(CACHE_DIR) if cache_env: return Path(cache_env) return Path.home() / .cache8.6 注意生产环境和本地环境的区别本文讨论的迁移方案只适用于本地开发环境。如果是生产环境中的服务器尤其是容器化部署的 Jenkins、Docker 数据卷、模型缓存服务不建议直接采用修改用户目录的方式迁移而应该通过容器挂载卷或云盘资源来管理。生产环境的任何路径变更都要走变更评审流程先备份、再测试、后发布。9. 总结与后续学习方向通过这次迁移C 盘的空间压力得到了明显缓解。Codex 的缓存、插件、会话数据全部转移到 D 盘之后系统盘不再承担大量的读写压力开机速度和日常操作流畅度也会有一定提升。更重要的是这种“数据与应用自然分离”的思路可以复用到几乎所有开发工具上。接下来可以继续研究的方向包括深入学习 Codex 的配置体系掌握更多模型参数、代理设置和日志开关。探索自动化测试中的临时数据管理比如如何把 Playwright、pytest、Jenkins 的产物统一归档到远程存储。了解 Windows 下 NTFS 目录联接、符号链接的权限模型以及它们在开发环境中的应用边界。对于日常已经被 C 盘耗尽困扰的开发者建议先动手执行一次完整的迁移再根据实际项目的目录特征做增量调优。每个人电脑上安装的工具不同占空间的模块也不同但只要掌握了“找目录、设路径、验证效果”这套方法C 盘告急问题基本都能解决。如果本文对你有帮助可以收藏备用后续换了新电脑这套流程也完全能够复用。