使用 npm 安装 Codex CLI 时遇到 EPERM、EACCES、operation not permitted 或 access denied，说明 npm 在创建、删除或替换文件时被系统拒绝了。报错看起来都像“权限不足”，实际可能是文件正被占用、全局目录归属混乱、安全软件拦截，或者旧安装残留没有释放。正确处理顺序是先读清报错路径，再处理对应目录，不要一开始就用管理员权限覆盖所有问题。

一、从报错路径判断故障位置

npm 错误通常会给出 syscall、path 和 errno。先找到失败路径：如果位于 npm 缓存目录，重点检查缓存和占用；如果位于全局 prefix，检查目录写权限；如果指向 codex.cmd 或 codex.ps1，可能是旧进程仍在使用启动文件；如果是项目目录，问题可能来自当前仓库权限，而不是全局安装。

把完整日志保留在本机，只摘录错误前后几十行用于分析。不要只复制最后一句 EPERM，因为同一个错误码可以由 rename、unlink、mkdir 等不同操作触发。操作类型不同，修复方式也不同。

二、先关闭占用文件的进程

退出所有正在运行的 Codex CLI、PowerShell、命令提示符和使用同一 Node 环境的编辑器终端。打开任务管理器检查残留的 node、npm 或 codex 进程。Windows 对正在执行的脚本和可执行文件会保持锁定，npm 更新时无法替换，就会报 EPERM。

关闭后重新打开一个普通 PowerShell，再执行安装。不要同时开两个安装窗口，也不要让包管理器和自动更新程序并发操作同一目录。若重启电脑后错误暂时消失，几乎可以确定此前存在文件锁，但仍应确认是哪个程序长期占用，避免下次更新重复发生。

三、检查 npm 全局目录是否属于当前用户

运行 `npm config get prefix` 和 `npm root -g`，确认全局目录。正常的个人开发环境应让当前用户能够写入自己的全局目录。若 prefix 指向受保护的系统目录，或者目录由另一个账号创建，普通 PowerShell 就可能得到 EACCES。

不要直接给整个磁盘或 Program Files 添加 Everyone 完全控制。更稳妥的做法是把 npm 全局 prefix 调整到当前用户可写的专用目录，并将该目录加入用户 PATH。调整后重新安装 Codex CLI，再用 `Get-Command codex -All` 确认命令来源。

四、谨慎处理 npm 缓存

先运行 npm 自带的缓存验证，确认索引和内容是否一致。只有日志明确指向缓存损坏，或验证结果显示异常时，才清理相关缓存。盲目删除全部缓存会增加重新下载时间，也可能让公司网络和离线环境更难恢复。

清理前关闭 npm 相关进程，并确认路径确实是 npm 缓存目录。不要把用户主目录或项目目录作为“缓存”递归删除。完成后重新执行一次安装，观察失败路径是否变化。路径变化往往说明第一层问题已解决，可以继续处理下一层。

如果大家想体验一线 AI 编程模型 codex 和 claude，用它们帮助完成代码修改、测试和审查，可以参考以下教程文档进行接入配置，接入配置好后即可使用。文档教程：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg

五、区分管理员运行与长期修复

临时以管理员身份运行安装，有时能证明问题确实是目录权限，但不应成为日常方案。管理员安装生成的文件可能归管理员上下文所有，后续普通用户升级又会失败，形成反复提权的循环。更合理的结果是普通用户在自己的目录内安装和更新。

企业电脑如果由 IT 统一部署 Node 和 npm，应遵守组织策略。不要自行修改系统 ACL 或关闭终端防护。把错误路径、npm prefix、Node 来源和日志交给管理员，通常比强制接管目录更安全，也更容易在多台电脑上统一修复。

六、检查安全软件和同步工具

实时防护可能在新可执行文件落盘时短暂扫描，云盘同步工具也会锁定正在变化的目录。如果错误具有偶发性，并且重试后路径不固定，可以查看安全软件事件记录和同步状态。不要直接永久关闭防护；可以让管理员为可信的开发目录设置合适策略。

不建议把 npm 全局目录放在 OneDrive 等同步目录。大量小文件和频繁重命名容易触发冲突。开发工具目录放在本地用户路径，项目代码再按团队方式备份，通常更稳定。

七、处理旧安装残留

如果卸载失败或命令文件残留，先用 npm 正常卸载，再检查全局包列表和 codex 命令来源。只有确认包已卸载、进程已退出，才删除明确属于旧 Codex 安装的残留文件。不要删除整个 node_modules 全局目录，因为里面可能还有其他工具。

多套 Node 环境也会造成残留错觉。运行 `where.exe node`、`where.exe npm` 和 `where.exe codex`，确认它们来自同一套环境。你可能在 A 环境卸载，却仍从 B 环境启动旧命令。先统一命令来源，再谈权限修复。

八、安装成功后的验证

先运行版本或帮助命令，再进入一个临时目录启动最小任务。随后关闭终端重新打开，确认 PATH 持久生效。最后再测试一次升级或重新安装流程，确保普通用户具备写入权限，不会只成功这一次。

建议记录 Node 版本、npm prefix、缓存路径、codex 命令路径和最终修复动作。EPERM 与 EACCES 的排查核心，是根据失败路径找到被占用或不可写的具体对象。关闭占用、修正用户目录、验证缓存和清理精准残留，比长期使用管理员终端更稳定。