这几天打开电脑C 盘又红了。右下角反复弹出“磁盘空间不足”IDE 保存文件开始卡顿甚至 Codex 对话到一半直接写不进去日志。打开磁盘管理器一看剩余空间只剩 1.8GB。我平时并没有往 C 盘安装大型游戏或软件为什么还是会被塞满排查了一圈之后发现真正吃空间的不是应用程序本体而是 Codex 这类开发工具在%USERPROFILE%、%APPDATA%和%LOCALAPPDATA%下面积累的缓存、日志、插件以及自动化测试跑完留下的浏览器内核和依赖包。本文就用一次完整的“磁盘瘦身”实践把 Codex 缓存、插件目录和自动化相关数据全部迁到 D 盘顺便把迁移过程中最典型的一个报错cc switch local proxy failed while handling codex endpoint /responses也一起梳理掉。1. 为什么 C 盘总是爆满先定位“空间真凶”1.1 三类典型的空间占用大户很多人清理 C 盘的第一反应是打开“设置-存储”删除临时文件或者去C:\Windows\Temp一顿乱删。但这些操作往往只能释放几百 MB过几天又被打回原形。原因很简单C 盘被占满罪魁祸首通常是开发者工具在用户目录下持续写入的数据。第一类是工具缓存。Codex CLI 会在用户目录下保存会话记录、运行日志和配置文件npm 会默认把缓存写到npm-cachepip 也会把下载的 wheel 包缓存到本地。这些缓存日积月累经常是几个 GB 起步。第二类是 IDE 插件和索引。VSCode 的扩展默认装在C:\Users\你的用户名\.vscode\extensionsPyCharm 和 IDEA 会额外在%LOCALAPPDATA%\JetBrains下生成大量索引和本地历史。插件安装越多C 盘消耗越明显而且 IDE 索引重建还会带来额外的磁盘读写压力。第三类是自动化测试数据。以 Playwright 为例它会把 Chromium、Firefox、WebKit 三个浏览器内核下载到%USERPROFILE%\AppData\Local\ms-playwright一套内核下载下来就是几百 MB 到 1GB 以上。如果还使用 Jenkins 跑自动化任务工作区、构建报告、插件缓存全部放在JENKINS_HOME下增长速度快得惊人。所以解决 C 盘爆满的关键不是“表面清理”而是把这三类数据从系统盘引导到其他分区。1.2 用命令定位具体大目录在迁移之前先确认哪些目录占用了大量空间。可以用 PowerShell 快速扫描用户目录# 以管理员身份运行 PowerShell统计用户目录下各目录大小 Get-ChildItem -Path $env:USERPROFILE -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.PSIsContainer } | ForEach-Object { $size (Get-ChildItem -Path $_.FullName -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Directory $_.FullName Size_MB [math]::Round($size / 1MB, 2) } } | Sort-Object Size_MB -Descending | Select-Object -First 20这个脚本会递归统计用户目录下所有子目录的大小结果按从大到小排列。目录非常多时执行会比较慢所以也可以借助 WizTree、TreeSize 这类可视化工具扫描几秒钟就能看到哪些目录占了几个 GB。如果你不想扫描整个用户目录可以先单独看几个高频占用目录# 查看几个常见缓存/插件目录的大小 $paths ( $env:USERPROFILE\.codex, $env:USERPROFILE\.vscode\extensions, $env:LOCALAPPDATA\npm-cache, $env:LOCALAPPDATA\pip\cache, $env:LOCALAPPDATA\ms-playwright, $env:USERPROFILE\.m2\repository, $env:USERPROFILE\.gradle ) foreach ($p in $paths) { if (Test-Path $p) { $size (Get-ChildItem -Path $p -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum Write-Host ({0,12:N2} MB {1} -f ($size / 1MB), $p) } }扫完之后基本就能确定哪些目录需要优先迁移。1.3 迁移方案并不是只有“改路径”一种发现大目录之后常见的处理方式有两种。第一种是修改软件原生支持的配置项。例如 npm 可以通过npm config set cache指定新的缓存目录pip 可以通过配置文件指定cache-dirPlaywright 可以设置环境变量PLAYWRIGHT_BROWSERS_PATH。这种方式最安全软件本身会在新路径下创建数据。第二种是直接把现有目录移动到 D 盘再用 Windows 的目录联接junction把原来的路径“映射”过去。这种方式不需要软件支持路径自定义适用于 Codex、VSCode 插件这类“写死路径”的场景。不过操作顺序有讲究乱剪切可能会导致工具找不到配置。不管使用哪种方式操作前都要先退出相关程序并备份重要配置和凭证。下面从 Codex 开始。2. 迁移底层逻辑目录联接与缓存路径2.1 为什么不能直接把目录剪切过去很多人会尝试把C:\Users\用户名\.codex整个文件夹剪切到 D 盘然后希望工具自动去 D 盘找。这样做通常会失败。原因是大量的 CLI 工具和 IDE 在启动时会通过固定的%USERPROFILE%路径读取配置不会自动感知目录被移动。如果原来路径不存在工具就会按照默认配置重新创建一个空目录。结果就是 D 盘多了一份数据C 盘又被新建了一份空间问题反而更严重。这里需要一个“假路径”原路径仍然存在但实际上指向 D 盘。Windows 天然支持这种机制也就是目录联接。2.2 mklink /J 目录联接是什么mklink 是 Windows 自带的命令用于创建符号链接和目录联接。推荐使用/J参数创建 directory junction它的兼容性较好不需要管理员权限的情况也更多而且跨盘使用时不会像符号链接那样容易出问题。命令格式如下mklink /J C:\Users\你的用户名\.codex D:\DevData\codex前面一个参数是“原来的路径”后面一个参数是“真实的 D 盘路径”。执行后C:\Users\你的用户名\.codex会变成一个目录联接程序访问它时Windows 会自动把读写操作转发到D:\DevData\codex。这里有几个注意点操作前要确保原路径已经被清空或删除否则 mklink 会提示文件已存在。D 盘目标目录可以先建好也可以让 mklink 自动创建但建议手动创建更稳妥。如果提示权限不足请以管理员身份打开命令提示符。不要对系统盘根目录或系统关键目录做这种操作。理解了底层原理之后接下来的迁移步骤就很统一了备份、移动、建联接、验证。3. 将 Codex 缓存与数据目录迁移到 D 盘3.1 找出 Codex 实际数据目录迁移前先确认 Codex 的数据落在哪里。常见路径是%USERPROFILE%\.codex但不同版本、不同安装方式可能略有差异。可以用下面命令查找# 在用户目录、AppData、LocalAppData 下查找 codex 相关目录 Get-ChildItem -Path $env:USERPROFILE -Force -Filter *codex* -ErrorAction SilentlyContinue Get-ChildItem -Path $env:APPDATA -Force -Filter *codex* -ErrorAction SilentlyContinue Get-ChildItem -Path $env:LOCALAPPDATA -Force -Filter *codex* -ErrorAction SilentlyContinue找到之后先看一眼目录里的内容。通常包含config.toml、auth.json、log、sessions等文件或目录。其中auth.json是登录凭证属于敏感信息备份时要注意存放位置不要随便传到网盘或代码仓库。3.2 用目录联接迁移 Codex以最常见的C:\Users\你的用户名\.codex为例完整流程如下。第一步退出 Codex CLI 以及 IDE 内集成的 Codex 插件避免文件被占用。第二步备份配置。直接把整个目录复制到 D 盘备份位置Copy-Item -Path $env:USERPROFILE\.codex -Destination D:\backup\codex-backup -Recurse -Force第三步在 D 盘创建目标目录把原目录内容移动过去。这里推荐使用 robocopy它比Move-Item更适合处理大量小文件和隐藏文件robocopy C:\Users\你的用户名\.codex D:\DevData\codex /E /COPYALL /DCOPY:T rd /s /q C:\Users\你的用户名\.codexrobocopy 的/E表示复制所有子目录包括空目录/COPYALL会尽量复制文件属性、权限和时间戳/DCOPY:T保留目录时间戳。复制完成后确认 D 盘目录内容完整再删除原目录。第四步创建目录联接mklink /J C:\Users\你的用户名\.codex D:\DevData\codex第五步验证。重新打开一个终端运行 Codex 命令或启动 IDE 集成确认能正常读取之前的会话和配置。然后在资源管理器里检查C:\Users\你的用户名\.codex如果右键属性显示“目录联接”且 D 盘空间占用正常就说明迁移成功。3.3 顺手迁移 npm 全局缓存Codex 如果通过 npm 安装npm 的缓存也会占用不少空间。先看一下当前缓存位置npm config get cache如果返回的是C:\Users\你的用户名\AppData\Local\npm-cache说明默认缓存都在 C 盘。迁移方法很简单# 先手动创建 D 盘缓存目录 New-Item -Path D:\DevData\npm-cache -ItemType Directory -Force # 修改 npm 缓存路径 npm config set cache D:\DevData\npm-cache # 查看是否生效 npm config get cache旧的缓存目录可以保留一段时间确认新路径下安装依赖正常后再删除Remove-Item -Path $env:LOCALAPPDATA\npm-cache -Recurse -Force如果你是 npm 全局包的重度用户还可以把全局包安装位置也迁移到 D 盘npm prefix -g # 例如输出 C:\Users\你的用户名\AppData\Roaming\npm迁移全局包需要设置NPM_CONFIG_PREFIX环境变量并把新的全局 bin 目录加入 PATH。这个操作比单纯迁移缓存要复杂容易造成命令找不到。如果你的 C 盘主要压力来自缓存可以先不迁全局包只迁移缓存就够了。4. 把 VSCode / JetBrains 插件目录搬到 D 盘4.1 VSCode 插件与缓存迁移VSCode 插件默认安装在C:\Users\你的用户名\.vscode\extensions。随着插件数量增加这个目录很容易超过 2GB。迁移步骤和 Codex 一致。先关闭所有 VSCode 窗口确保没有残留进程Get-Process code -ErrorAction SilentlyContinue | Stop-Process -Force然后备份并复制到 D 盘robocopy C:\Users\你的用户名\.vscode\extensions D:\DevData\vscode-extensions /E /COPYALL /DCOPY:T rd /s /q C:\Users\你的用户名\.vscode\extensions mklink /J C:\Users\你的用户名\.vscode\extensions D:\DevData\vscode-extensions重新启动 VSCode查看“扩展”面板是否正常加载。如果某些扩展提示损坏通常是原目录里存在正在写入的文件被跳过重新安装对应扩展即可。另外VSCode 的窗口布局、缓存数据也会写入%APPDATA%\Code目录其中Cache和CachedData子目录是重点占用项。这两个目录可以单独迁移robocopy %APPDATA%\Code\Cache D:\DevData\vscode-cache\Cache /E /COPYALL /DCOPY:T robocopy %APPDATA%\Code\CachedData D:\DevData\vscode-cache\CachedData /E /COPYALL /DCOPY:T rd /s /q %APPDATA%\Code\Cache rd /s /q %APPDATA%\Code\CachedData mklink /J %APPDATA%\Code\Cache D:\DevData\vscode-cache\Cache mklink /J %APPDATA%\Code\CachedData D:\DevData\vscode-cache\CachedData缓存目录迁移后 VSCode 可能需要重建一部分缓存第一次启动会稍慢之后恢复正常。4.2 PyCharm / JetBrains 插件与索引迁移JetBrains 系 IDE 的数据分散在两个位置插件目录%APPDATA%\JetBrains\产品名版本号\plugins索引/缓存目录%LOCALAPPDATA%\JetBrains其中%LOCALAPPDATA%\JetBrains占用的空间非常大因为 IDE 会把项目索引、本地历史、日志等全部写到这里。迁移方式同样是 robocopy 加 mklink。但要特别提醒JetBrains 目录下通常同时存在多个版本的产品目录迁移时要看清楚哪些是正在使用的版本不要一股脑全迁移。建议先关闭 IDEA 或 PyCharm再复制对应目录。robocopy %LOCALAPPDATA%\JetBrains D:\DevData\jetbrains /E /COPYALL /DCOPY:T rd /s /q %LOCALAPPDATA%\JetBrains mklink /J %LOCALAPPDATA%\JetBrains D:\DevData\jetbrains重启 IDE 后如果发现索引异常可以通过菜单File - Invalidate Caches / Restart重建索引。新版 PyCharm 在Files - Manage IDE Settings - Disk Cache也提供一键查看缓存目录的入口。5. 自动化相关数据迁移浏览器内核、依赖包与 CI 工作区5.1 Playwright 浏览器内核迁移自动化测试里最常见的大块头是 Playwright 下载的浏览器内核。默认路径在%USERPROFILE%\AppData\Local\ms-playwright一套 Chromium 加 WebKit 下载下来磁盘占用轻松超过 1GB。迁移分两步。第一步把现有目录移动到 D 盘robocopy %LOCALAPPDATA%\ms-playwright D:\DevData\ms-playwright /E /COPYALL /DCOPY:T rd /s /q %LOCALAPPDATA%\ms-playwright第二步设置环境变量PLAYWRIGHT_BROWSERS_PATH指向新的目录setx PLAYWRIGHT_BROWSERS_PATH D:\DevData\ms-playwright重新打开终端运行playwright install这样会自动检测新路径下的浏览器是否完整缺失的部分会重新下载。注意环境变量设置后需要新开终端才能生效。如果项目里有多个团队成员建议在项目的.env文件中统一配置PLAYWRIGHT_BROWSERS_PATH避免每个人各自维护一套本地路径。5.2 pip / Maven / Gradle 依赖缓存迁移Python 项目的 pip 缓存同样占用明显。新版 pip 支持命令行设置全局 cache-dirpip config set global.cache-dir D:\DevData\pip-cache执行后pip 会把下载的安装包缓存写入 D 盘。旧的缓存可以手动清理pip cache purge如果不想修改全局配置也可以在安装时临时指定pip install --cache-dir D:\DevData\pip-cache -r requirements.txtJava 项目里Maven 本地仓库默认在C:\Users\你的用户名\.m2\repository。迁移时需要修改%USERPROFILE%\.m2\settings.xml把localRepository改为 D 盘路径settings xmlnshttp://maven.apache.org/SETTINGS/1.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd localRepositoryD:\DevData\maven-repository/localRepository /settingsGradle 用户则通过环境变量迁移setx GRADLE_USER_HOME D:\DevData\gradle-home设置后Gradle 的依赖缓存、守护进程日志都会写入 D 盘。5.3 Jenkins 工作区与 Appium 依赖迁移如果你用 Jenkins 跑自动化测试JENKINS_HOME是空间消耗的大户。Jenkins 默认把工作区、构建记录、插件全部放在 C 盘。迁移的正确姿势是停止 Jenkins 服务。把整个 Jenkins 数据目录复制到 D 盘。修改服务配置或系统环境变量JENKINS_HOMED:\DevData\jenkins_home。重新启动 Jenkins跑一个现有任务确认工作区和构建记录正常。Appium 的场景类似。如果通过 npm 安装了 Appium 及各种 driver这些依赖都位于 npm 全局目录中。迁移 npm 全局包之后需要重新执行appium driver list确认驱动路径没有丢失。6. 常见报错CC Switch 切换 Codex Endpoint 失败6.1 报错现象在完成目录迁移、重新配置 Codex 与本地 API 服务后偶尔会遇到一条很典型的报错cc switch local proxy failed while handling codex endpoint /responses. provided ...这个报错一般出现在使用 CC Switch 切换 Codex 接口配置之后下次执行 Codex 请求时直接失败。单纯从磁盘迁移的角度看它并不是由目录搬移直接引起的但在实际项目中常常伴随出现因为你刚动过 Codex 的配置目录CC Switch 可能还在使用旧的配置路径或旧的缓存。6.2 原因分析根据社区里的反馈和我自己的排查经验这类报错通常有以下几个来源。第一Codex CLI 访问的/responses接口在当前配置的 API 服务中不存在。部分兼容接口只实现了传统的/chat/completions并没有实现 OpenAI 的/responses接口。CC Switch 切过去之后Codex 默认请求/responses自然报错。第二配置文件中的base_url路径不正确。错误示例包括多写了一层/v1或者忘了补全/v1。Codex 会直接拼接 endpoint 路径导致请求地址 404 或 405。第三Codex CLI 版本与目标 API 服务版本不匹配旧版本 CLI 请求方式和服务端支持接口不一致。第四本地服务没有启动或者端口被占用。CC Switch 中配置的 local proxy 地址无法访问时也会出现类似报错。6.3 排查步骤与解决方案遇到这条报错不要急着重装 Codex按下面的顺序排查。第一步打开 CC Switch核对当前激活的配置。重点检查base_url和 API Key 是否填写正确是否和你想切换的目标服务一致。第二步确认目标 API 服务是否支持/responses接口。如果不支持需要在 Codex 配置中切换为chat_completions兼容方式。不同版本的 Codex 配置字段不同常见做法是修改%USERPROFILE%\.codex\config.toml# 文件路径%USERPROFILE%\.codex\config.toml # 注意以下为常见结构字段名以你当前 Codex 版本为准 model your-model-name [model_provider] name your-provider base_url https://api.example.com/v1 wire_api chat_completions如果你的版本不支持wire_api字段建议先查阅当前版本配置说明不要强行照抄。第三步重启本地网关服务。如果 CC Switch 里启动了一个本地转发服务先退出 CC Switch再重新打开。然后确认本机端口没有被其他进程占用netstat -ano | findstr 端口号第四步清理 Codex 会话缓存避免旧请求模式被复用。可以删除或重命名.codex下的 sessions 目录然后重新发起对话。第五步检查 Codex CLI 版本。如果版本过旧可以升级到较新版本后再尝试。7. 常见问题汇总表问题现象常见原因解决思路C 盘空间没有明显变化程序迁移后又在原路径重新创建了目录检查原路径是否为目录联接排查有没有开机自启任务重新生成数据启动 Codex 提示找不到配置.codex目录迁移时遗漏了隐藏文件恢复备份使用 robocopy/COPYALL重新复制检查 auth.json 和 config.toml 是否完整VSCode 插件全部失效extensions 目录被移动但联接未创建确认%USERPROFILE%\.vscode\extensions是否为 mklink 联接必要时重建PyCharm 启动后索引重新构建JetBrains 缓存目录迁移不完整让 IDE 重建索引或者恢复原目录后再用/MIR参数重新同步Playwright 提示找不到浏览器PLAYWRIGHT_BROWSERS_PATH未在当前终端生效新开终端重新执行playwright installcc switch local proxy failed目标 API 服务不支持/responses或本地服务未启动检查 base_url、切换兼容接口、重启 CC Switch迁移后目录没有写权限D 盘目录权限默认受限给当前用户授予该目录的完全控制权限8. 最佳实践与工程建议8.1 迁移三原则先备份、再迁移、后验证任何目录迁移都存在风险。备份不是“可选动作”而是“必要动作”。尤其是 Codex 的auth.json和 IDE 的配置目录一旦迁移过程出错可能会导致登录态丢失或配置丢失。迁移后一定要验证。验证不只是打开软件看一眼而是要实际执行一条完整链路Codex 发起一次请求VSCode 安装并启用一个扩展Playwright 跑通一条用例。只有核心流程走通才能确认迁移成功。8.2 定期给缓存“瘦身”迁移到 D 盘并不意味着缓存永远不会膨胀。建议给缓存设置清理策略npm 缓存可以定期执行npm cache clean --force。pip 缓存可以执行pip cache purge。Codex 日志目录可以手动删除超过 7 天的日志文件。Playwright 可以删除不再使用的旧版本浏览器内核使用npx playwright uninstall --all清理无用内核。8.3 用环境变量统一管理路径多个工具都需要设置路径时建议使用系统环境变量而不是每次启动前临时设置。因为临时设置只对当前终端生效离开终端就失效很容易造成“明明配置了但工具还是去 C 盘”的错觉。可以在系统环境变量里统一维护一份清单PLAYWRIGHT_BROWSERS_PATHD:\DevData\ms-playwright GRADLE_USER_HOMED:\DevData\gradle-home JENKINS_HOMED:\DevData\jenkins_home NPM_CONFIG_CACHED:\DevData\npm-cache记录下每次修改的环境变量项后续排查问题时能节省大量时间。8.4 不要把所有希望寄托在“删文件”上C 盘爆满后很多人会选择删除 Windows 目录里的临时文件甚至去删C:\ProgramData下面看着很大的文件。这种方式风险很高一旦删掉系统组件或软件运行所需的数据可能导致系统崩溃或软件无法启动。更安全的做法是像本文一样先定位再备份再迁移。8.5 自动化环境迁移前先做小范围验证自动化项目往往有固定的 CI 流程迁移 Jenkins 工作区或 Playwright 浏览器目录时最好先在本地开发环境验证再同步到 CI 机器。不要第一次迁移就在生产 Jenkins 上操作否则构建任务大面积失败后排查成本会很高。9. 总结C 盘从红色告急恢复到绿色核心不是靠删文件而是把那些“持续增长的数据”引导到能长期容纳的 D 盘。Codex 数据目录用目录联接迁移npm 和 Playwright 通过环境变量迁移IDE 插件和 JetBrains 缓存则使用 robocopy 加 mklink 组合处理。这次迁移之后我不但解决了磁盘不足的问题还顺手摸清了 Codex 配置目录、CC Switch 切换报错和自动化依赖路径之间的关联。以后再遇到 C 盘爆满我基本上会按照“先定位、再备份、后迁移、最后验证”的顺序来处理而不是重启电脑赌运气。如果你也在被 C 盘空间不足困扰可以对照本文的目录和命令选一个占用最大的项目先迁移。动手之前记得备份动手之后记得验证剩下的就是 D 盘空间的持续健康管理了。