Codex 这类终端 AI 编程助手用起来很顺手但很多人在 C 盘爆红之后才发现问题Codex 的缓存、会话历史、调试日志以及配套使用的插件和自动化脚本默认都落在系统盘用户目录下。连续运行几次大型重构、批量生成任务或自动化测试后C 盘空间会快速下降直到磁盘已满Codex 会话写入失败、插件加载异常系统也开始卡顿。这篇文章不讨论“删除哪些文件续命”而是把 Codex 缓存、VS Code 插件目录、npm/pip 等依赖缓存和自动化脚本相关数据完整迁移到 D 盘同时说明每一步为什么这样做、迁移后如何验证、后续怎么防止问题复发。这篇文章适合三类读者长期使用 Codex CLI 做编码任务的开发者本地跑自动化脚本、自动化测试并安装了大量 VS Code 插件的人C 盘剩余空间紧张希望一劳永逸解决问题而不是反复清理磁盘的人。文章以 Windows 环境为例因为 C 盘、D 盘本身就是 Windows 场景最常见的表述macOS 和 Linux 的思路相同只是路径和环境变量写法略有差异。1. 先弄清 Codex 缓存、插件和自动化数据到底写在 C 盘哪里很多人的第一反应是重装 Codex 到 D 盘但实际上安装目录从来不是问题的主要来源。CLI 工具、编辑器扩展和包管理器的用户数据目录才是占空间的“重灾区”。如果连数据落在哪里都没搞清直接搬目录很容易搬错导致 Codex 打开后像换了一台机器。1.1 Codex CLI 默认目录不是安装目录Codex CLI 安装后可执行文件可能位于 npm 全局目录、Homebrew 目录或自定义安装目录这部分通常只占几百 MB。真正的用户数据在独立的主目录里。在 Windows 上Codex CLI 默认把配置、认证信息、会话历史和日志放在用户根目录下的.codex文件夹完整路径是C:\Users\你的用户名\.codex这个目录里常见的内容包括文件或目录作用增长特点config.toml主配置文件记录模型、审批策略、模型服务商等信息基本不变auth.json认证凭据文件基本不变sessions/每次会话的历史记录通常按日期归档高频增长logs/调试日志、错误日志高频增长history.jsonl历史操作记录随使用量增长这里要注意安装 Codex 时无论选择 npm 还是安装包方式用户数据目录都独立存在。所以“重装到 D 盘”解决不了缓存和会话历史继续写 C 盘的问题。1.2 插件与自动化脚本的落盘位置除了 Codex 自身日常开发里“看起来没占多少”的插件目录其实非常庞大。以 Windows 为例常见占位位置如下VS Code 扩展C:\Users\用户名\.vscode\extensionsVS Code 用户数据C:\Users\用户名\AppData\Roaming\Codenpm 全局包和缓存C:\Users\用户名\AppData\Roaming\npm以及npm-cachepnpm 存储目录C:\Users\用户名\AppData\Local\pnpmpip 缓存C:\Users\用户名\AppData\Local\pip\Cacheuv 缓存C:\Users\用户名\AppData\Local\uv\cache自动化脚本所在目录很多人随手放在C:\Users\用户名\scripts或C:\Tools自动化脚本的问题往往比缓存更隐蔽。脚本本身很小但运行后生成的测试报告、截图、日志、临时数据库、下载产物都会落在脚本目录或系统临时目录。一次自动化冒烟测试可能产生几十 MB 的截图跑一个月就是几个 GB。1.3 C 盘告急的典型增长路径C 盘空间不是瞬间消失的通常是几条增长路径叠加Codex 长任务产生大量会话 JSONL 和历史记录。连续跑一整天后单个会话文件可能达到几十 MB。npm、pip 等缓存持续累积。每次安装依赖都会写入缓存缓存失效后旧版本并不会自动清除。插件无故变大。部分插件会内置语言服务、静态检查器和下载工具链例如 C/C 插件、Python 插件单个就能占几百 MB。自动化测试报告和日志没有清理策略每天新增但没有定期删除。系统临时目录被安装包、解压产物、崩溃转储文件占满。理解了这几条路径就知道迁移方案不能只搬 Codex 一个目录而是要把“主目录、缓存、插件、自动化数据”四类一起处理。2. 搬移前的盘点能搬什么、不能搬什么、用什么方案搬迁移前先做两件事确认环境、盘点占用。不要一上来就mklink否则目录搬了环境变量没跟上或者遗漏了一半数据反而更难排查。2.1 环境前提与最少工具清单本方案在 Windows 10 和 Windows 11 上测试过常规路径需要以下条件工具作用是否必须Windows 10/11支持mklink /J目录联接必须robocopy复制目录结构和权限系统自带PowerShell 或 cmd执行脚本和配置命令系统自带setx写用户环境变量系统自带Codex CLI 当前版本确认版本支持的配置方式必须建议迁移前先记录当前 Codex 版本方便查阅对应文档codex --version如果输出异常说明 Codex 进程还在运行或 PATH 配置有问题先处理完再继续。2.2 盘点清单先看每个目录真实占用不要凭感觉判断哪些目录占空间。用 PowerShell 写一个简单的扫描脚本把上面提到的目录全部扫一遍$paths ( $env:USERPROFILE\.codex, $env:USERPROFILE\.vscode\extensions, $env:APPDATA\Code, $env:LOCALAPPDATA\npm-cache, $env:LOCALAPPDATA\pnpm, $env:LOCALAPPDATA\pip\Cache, $env:LOCALAPPDATA\uv, $env:LOCALAPPDATA\Temp ) foreach ($p in $paths) { if (Test-Path $p) { $size (Get-ChildItem $p -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum {0,-60} {1,10:N1} MB -f $p, ($size / 1MB) } }运行结果会给出每个目录的近似大小。接下来可以按下面这张表决定迁移优先级目录通常占用能不能搬迁移方式C:\Users\用户名\.codex几百 MB 到几 GB可以CODEX_HOME或目录联接C:\Users\用户名\.vscode\extensions几百 MB 到数 GB可以--extensions-dirnpm 缓存1 到 10 GB可以npm config set cachepnpm store1 到 10 GB可以pnpm config set store-dirpip 缓存几百 MB 到几 GB可以pip config set global.cache-diruv 缓存1 到 5 GB可以UV_CACHE_DIR系统 TEMP/TMP视使用习惯可以用户环境变量自动化脚本目录通常较小建议搬直接复制到 D 盘2.3 三种搬移方案怎么选迁移有环境变量、目录联接、启动参数三条路线适合不同场景。方案原理优点缺点适用场景环境变量应用读取CODEX_HOME等变量把数据目录指到 D 盘干净、符合应用设计依赖应用支持旧版本不一定生效新版本 Codex、npm、pip、uv目录联接把 C 盘原路径做成一个“快捷映射”目标在 D 盘应用无感知老软件也能用迁移失败时容易出现路径指向错误应用不支持自定义目录时启动参数每次启动时传参例如--extensions-dir精确、不改变系统全局不适用于后台运行和所有工具VS Code 等支持启动参数的软件对于 Codex 主目录优先尝试CODEX_HOME如果版本不支持再用目录联接保证兼容。对于 VS Code 插件推荐启动参数因为 VS Code 本身对这种场景支持最成熟。3. 实操把 Codex 主目录迁到 D 盘假设目标目录是D:\CodexData\codex。下面按“停止进程、复制数据、建立联接、配置环境变量、验证”的顺序操作。3.1 先停止 Codex 相关进程避免文件占用Windows 下目录被占用时robocopy会复制失败mklink也无法对非空目录创建联接。所以先关闭正在运行 Codex 的终端窗口关闭 VS Code 里的集成终端再检查进程tasklist | findstr /I codex如果有进程先尝试正常退出再强制结束taskkill /IM codex.exe /F这一步的主要目的不是“杀掉进程”而是确保文件句柄释放。复制时如果遇到“另一个程序正在使用此文件”的错误大概率就是这一步没做完。3.2 用 robocopy 复制数据保留目录属性和时间戳robocopy是 Windows 下最可靠的复制工具之一比xcopy更适合处理深目录和长路径。复制命令robocopy C:\Users\你的用户名\.codex D:\CodexData\codex /E /COPY:DAT /R:2 /W:2 /LOG:D:\CodexData\migrate-codex.log参数含义参数作用/E复制所有子目录包括空目录/COPY:DAT复制数据、属性、时间戳/R:2文件复制失败时重试 2 次/W:2两次重试之间等待 2 秒/LOG:把复制日志写到 D 盘方便排查复制完成后查看日志确认没有失败项。注意robocopy的返回值不是 Windows 常规的 0/1 逻辑0 到 7 都算成功8 及以上才是失败很多人第一次用都会在这个细节上踩坑。3.3 Windows 下用 mklink /J 建立目录联接数据复制到 D 盘后先把 C 盘原始目录改名再创建目录联接。这里推荐使用 junction 而不是 symbolic link因为 junction 不需要管理员权限并且对大多数应用兼容性更好。ren C:\Users\你的用户名\.codex .codex_bak mklink /J C:\Users\你的用户名\.codex D:\CodexData\codex执行成功后访问C:\Users\你的用户名\.codex就等同于访问D:\CodexData\codex。Codex 完全无感知仍然会读写原来的路径但实际数据在 D 盘。验证联接是否生效dir C:\Users\你的用户名\.codex输出中如果能看到config.toml、sessions等内容说明联接正常。3.4 不依赖联接通过 CODEX_HOME 设置自定义目录如果你希望方案更干净不保留 C 盘路径那么使用环境变量是最优解。不同版本 Codex CLI 对主目录的支持程度不同落地前先确认当前版本是否读取CODEX_HOME。setx CODEX_HOME D:\CodexData\codexsetx只影响之后新开的终端当前窗口不会立即生效。重新打开一个 cmd 或 PowerShell 窗口后执行echo %CODEX_HOME%能看到D:\CodexData\codex就说明配置成功。如果启动 Codex 后发现会话历史为空把环境变量和正文里提到的主目录方案对照检查并查阅你当前版本的官方文档确认变量名版本兼容性。3.5 迁移后的目录结构长什么样完成迁移后D 盘的结构应该类似D:\CodexData\codex ├── config.toml ├── auth.json ├── history.jsonl ├── sessions\ │ ├── 2025-06-25\ │ ├── 2025-06-26\ │ └── ... └── logs\ ├── codex-20250626.log └── ...只要 C 盘联接指向这个目录Codex 启动后读到的就是你原来的会话和配置不会出现“配置全部丢失”的情况。3.6 验证 Codex 能继续读取会话与配置迁移完成后开一个终端先跑一个简单命令确认可执行codex --version再进入交互模式发起一个简短任务确认会话文件确实写到了 D 盘。检查方式dir D:\CodexData\codex\sessions目录里出现了新的文件或子目录说明 Codex 写路径正常。如果出现认证失败检查auth.json是否完整复制并在新的 Codex 窗口中重新登录一次。注意不要只验证“程序能启动”。必须确认历史会话能打开、新会话能写入、认证信息有效这三点都成立才算迁移成功。4. 实操把 Node、Python 和系统临时文件缓存搬到 D 盘Codex 主目录搬完后缓存依然是 C 盘的大头。npm、pnpm、pip、uv 默认缓存都在用户目录下不处理的话过几周 C 盘又会亮红灯。4.1 npm、pnpm、yarn 缓存重定向npm 默认缓存目录在 Windows 上是%LocalAppData%\npm-cache改成 D 盘npm config set cache D:\Cache\npm npm config get cache这里要解释一下为什么要改缓存目录。npm 每次安装依赖都会优先查询本地缓存命中时直接解压不命中时下载并写入缓存。如果缓存放在 C 盘任何项目安装都会持续向 C 盘写入累计速度非常快。pnpm 的存储目录和 npm 不同需要单独配置pnpm config set store-dir D:\Cache\pnpm-store pnpm store pathyarn 使用 cache-folderyarn config set cache-folder D:\Cache\yarn yarn cache dir喜欢用哪个包管理器就配置哪个不需要全部配置但要注意同一个项目里不要混用 npm 和 pnpm 缓存容易出现安装结果不一致的问题。4.2 pip、uv 缓存重定向Python 生态同样是大户。pip 配置缓存的命令pip config set global.cache-dir D:\Cache\pip pip cache dirpip cache dir输出确认新路径后后续 pip 安装就会使用 D 盘缓存。uv 是新一代 Python 包管理器缓存目录可以通过环境变量指定setx UV_CACHE_DIR D:\Cache\uv新开终端后验证uv cache dir如果输出还是 C 盘路径检查环境变量是否加载或者在当前终端手动执行一次set UV_CACHE_DIRD:\Cache\uv用于当前会话立即生效。4.3 Windows TEMP/TMP 与 Codex 日志目录Codex 运行过程中临时文件、日志、崩溃转储都会写入系统临时目录。把用户 TEMP/TMP 指到 D 盘能减少 C 盘持续写入setx TEMP D:\Cache\Temp setx TMP D:\Cache\Temp同样新开终端后验证echo %TEMP%注意不要修改系统级的 TEMP/TMP只修改用户级变量避免影响其他系统服务。4.4 缓存参数速查表工具默认位置配置方式验证命令npm%LocalAppData%\npm-cachenpm config set cache D:\Cache\npmnpm config get cachepnpm%LocalAppData%\pnpmpnpm config set store-dir D:\Cache\pnpm-storepnpm store pathyarn%LocalAppData%\Yarn\Cacheyarn config set cache-folder D:\Cache\yarnyarn cache dirpip%LocalAppData%\pip\Cachepip config set global.cache-dir D:\Cache\pippip cache diruv%LocalAppData%\uv\cachesetx UV_CACHE_DIR D:\Cache\uvuv cache dirTEMP/TMP%LocalAppData%\Tempsetx TEMP D:\Cache\Tempecho %TEMP%配置完成后建议把旧的 C 盘缓存目录原样保留一周等确认所有项目安装正常再删除避免缓存损坏后无法回退。5. 实操插件目录与自动化脚本迁到 D 盘缓存处理完后还需要处理 VS Code 插件和自动化脚本。这两部分如果不迁移插件更新时依旧写 C 盘自动化测试报告和日志也会持续增长。5.1 VS Code 扩展目录用 --extensions-dir 指定先复制现有扩展到 D 盘robocopy C:\Users\你的用户名\.vscode\extensions D:\VSCodeData\extensions /E /COPY:DAT /R:2 /W:2然后在 VS Code 启动参数里指定扩展目录。直接使用命令行启动code --extensions-dir D:\VSCodeData\extensions --user-data-dir D:\VSCodeData\user如果平时用桌面快捷方式启动需要修改快捷方式的“目标”D:\Microsoft VS Code\Code.exe --extensions-dir D:\VSCodeData\extensions --user-data-dir D:\VSCodeData\user这里的关键点是--user-data-dir和--extensions-dir最好一起指定。user-data-dir保存用户设置、快捷键、窗口布局如果只搬扩展不搬用户数据可能会出现扩展和设置不在同一状态的情况。验证方式code --list-extensions能看到原有扩展列表说明扩展目录读取正常。需要注意部分扩展在安装时会额外下载语言工具链到用户目录这部分不在extensions目录内例如 C/C 扩展的额外组件。这类扩展需要在设置里单独指定下载位置或者在安装后观察 C 盘占用再处理。5.2 自动化脚本统一结构代码、缓存、日志分离自动化脚本迁移的核心不是把脚本文件夹从 C 盘挪到 D 盘而是让脚本运行产物不再依赖 C 盘。推荐建立这样一个目录结构D:\Automation ├── projects\ │ └── demo\ │ ├── src\ │ └── config\ ├── prompts\ │ └── build.txt ├── data\ └── logs\ ├── 20250626\ │ ├── codex-demo-102030.log │ └── test-report.html └── 20250627\结构设计思路projects放自动化任务对应的项目代码。prompts放 Codex 任务的提示词文件方便批量调用。data放任务产生的固定数据文件。logs按日期分目录保存日志和测试报告。这样做的原因是把“可执行代码”和“运行产物”完全分开。代码可以进版本库产物只留在本地配合日志清理策略就能长期稳定运行。5.3 一个可复用的自动化启动示例下面是一个 PowerShell 示例封装了环境变量设置、日志落盘和 Codex 调用逻辑。实际项目请替换项目名、提示词路径和日志根目录。# D:\Automation\scripts\Run-CodexTask.ps1 param( [string]$Project default, [string]$PromptFile ) # 统一指定 D 盘缓存目录 $env:CODEX_HOME D:\CodexData\codex $env:NPM_CONFIG_CACHE D:\Cache\npm $env:PIP_CACHE_DIR D:\Cache\pip $env:UV_CACHE_DIR D:\Cache\uv # 按日期生成日志目录 $date Get-Date -Format yyyyMMdd $time Get-Date -Format HHmmss $logDir D:\Automation\logs\$date $logFile D:\Automation\logs\$date\codex-$Project-$time.log New-Item -ItemType Directory -Force -Path $logDir | Out-Null if ($PromptFile -ne ) { codex exec 请依据 $PromptFile 中的要求完成 $Project 任务 *1 | Tee-Object -FilePath $logFile } else { codex exec 请完成 $Project 的自动化任务 *1 | Tee-Object -FilePath $logFile } Write-Host 日志已写入: $logFile调用方式.\Run-CodexTask.ps1 -Project demo -PromptFile D:\Automation\prompts\build.txt脚本里*1把所有输出流合并Tee-Object同时把输出显示在终端并写入日志文件。这样即使任务在后台执行也能留下完整日志。5.4 日志增长控制按日期拆分和清理策略日志目录按日期拆分后清理策略就非常简单保留最近 30 天即可。将下面的命令保存为Clean-Logs.ps1并用 Windows 任务计划程序每周执行一次$root D:\Automation\logs $cutoff (Get-Date).AddDays(-30).ToString(yyyyMMdd) Get-ChildItem $root -Directory | Where-Object { $_.Name -lt $cutoff } | Remove-Item -Recurse -Force Write-Host 已清理 $cutoff 之前的日志目录这里用目录名与日期字符串直接比较逻辑简单且稳定。不要写成“找到 30 天前修改的文件再删除”因为日志目录里的文件可能被脚本持续读取修改时间不一定能准确反映业务日期。注意自动化脚本里的CODEX_HOME和系统环境变量可能不一致运行时以脚本里设置为准。这样团队内其他人拿到脚本后即使没配置全局变量也能稳定输出到 D 盘。6. 迁移后的验证、排查与日常保养迁移完成后不要直接删除 C 盘旧目录。先按验证清单逐项确认再进入正常使用阶段最后把防止 C 盘再次爆红变成日常习惯。6.1 迁移后验证清单检查项验证方式预期结果Codex 可执行codex --version正常输出版本号Codex 主目录生效echo %CODEX_HOME%目录联接方案看dir C:\Users\用户\.codex指向 D 盘或能看到 D 盘内容历史会话可读打开 Codex 查看过往会话列表能看到迁移前的会话记录新会话写入 D 盘运行一次codex exec 输出 OK后查看D:\CodexData\codex\sessions出现新文件npm 缓存位置npm config get cache输出 D 盘路径pip 缓存位置pip cache dir输出 D 盘路径VS Code 扩展code --list-extensions或打开扩展面板扩展列表完整自动化脚本运行运行一次Run-CodexTask.ps1日志写入 D 盘日志目录C 盘剩余空间打开设置查看磁盘容量空间较迁移前明显回升建议复制这份清单到项目 Wiki 或团队文档里后续任何同事遇到相同问题可以直接按表执行。6.2 常见问题排查表迁移过程中大概率会遇到下面这些问题按表排查能少走弯路。问题现象常见原因检查方式处理建议Codex 启动后找不到历史会话CODEX_HOME未生效或联接指向错误目录echo %CODEX_HOME%dir C:\Users\用户\.codex重新在新终端验证确认 junction 目标路径正确环境变量改了但 Codex 仍读写旧目录当前终端还保留旧环境另开一个全新终端再试用setx后重启终端当前会话临时用set覆盖npm 安装时缓存仍然增长使用的是旧缓存配置npm config get cache重新执行配置命令确认项目本地.npmrc没覆盖VS Code 扩展部分丢失--extensions-dir只在某次启动生效快捷方式没有同步检查快捷方式目标是否包含参数修改快捷方式或使用固定的启动脚本Codex 写入 D 盘后权限报错robocopy复制的目录权限不完整查看 C 盘.codex_bak的 ACL用icacls对比权限或重新以当前用户身份 chown旧数据删除后 Codex 异常删除过快认证信息或会话还在旧目录恢复.codex_bak名称并检查内容确认验证清单全部通过后再删除备份其中权限问题最容易忽略。robocopy带/COPY:DAT复制了属性和时间戳但不带/B或/DCOPY:T时某些隐藏属性和安全描述符可能不一致。如果在多用户环境下使用建议复制命令升级为robocopy C:\Users\你的用户名\.codex D:\CodexData\codex /E /COPY:DAT /DCOPY:T /R:2 /W:26.3 防止 C 盘再次爆红的日常习惯迁移不是终点日常习惯才决定 C 盘能否长期保持健康。不要手动往C:\Users\用户名下放项目代码项目全部放到 D 盘或代码盘避免node_modules悄悄长到几 GB。每季度执行一次缓存清理npm cache verify、pip cache purge、uv cache clean。安装软件时选择“仅当前用户”或自定义安装目录避免安装器默认写入 Program Files 后再复制到 D 盘。日志清理脚本纳入定期任务日志目录超过 30 天自动删除。使用WinDirStat或SpaceSniffer这类磁盘分析工具每月扫一次 C 盘找出隐藏的大文件。休眠文件和系统还原点会占用大量 C 盘空间如果 C 盘实在紧张可以在电源设置中关闭休眠但会影响快速启动需要根据需求权衡。这套习惯不一定每天都做但每季度做一次就能有效避免“C 盘突然爆红”的紧急状态。6.4 扩展方向把迁移方案变成可复用的脚本前面的步骤可以整理成一个一键脚本放进公司的工程技术文档仓库团队成员直接运行即可。脚本里至少包括以下操作扫描 C 盘各数据目录占用。把 Codex、VS Code 扩展、依赖缓存复制到 D 盘。根据用户选择配置环境变量或建立目录联接。输出验证清单提示用户确认后删除旧目录。如果你的 Codex 配置里使用了model_providers接入 OpenAI 兼容的模型服务商配置和认证信息都保存在config.toml和auth.json中迁移主目录后这些配置会被原样带过去。但要注意auth.json属于敏感文件不要把整个 D 盘数据目录共享给他人也不要提交到 Git 仓库。更进一步如果团队开始容器化开发环境可以把 Codex 数据和缓存目录映射到 Docker Volume 或 WSL 的挂载路径这样宿主机上不再产生任何用户级缓存。不过容器方案的前提是网络、存储和资源限制都明确普通本地开发场景下本文的方案更直接、更容易排查。完整的迁移流程跑通后C 盘不再需要频繁手工清理。Codex 会话、插件、依赖缓存和自动化日志都在 D 盘按目录管理后续扩容、备份、重装系统时只需要重新执行验证清单就能快速恢复到正常状态。这也是文章最终希望达成的效果把“C 盘告急”从偶发事故变成可预防、可迁移、可自动化的常规工程问题。