Codex EPERM 操作被拒绝错误处理

Codex EPERM 操作被拒绝错误处理

用 Codex 改项目代码时，偶尔会遇到EPERM: operation not permitted、permission denied、operation not permitted, unlink这类错误。最常见的场景是：Codex 想创建、修改、删除某个文件，但当前进程没有权限，或者文件正被系统、编辑器、杀毒软件、构建进程占用。

排这个问题不要一上来重装 Codex，先看两件事：报错路径是哪一个文件，以及 Codex 当前是以什么用户、什么工作目录运行的。多数问题都能从这里定位。

一、常见错误现象

典型报错大概是下面几种：

### token云桥中转 0029.org ### EPERM: operation not permitted, open 'C:\project\demo\src\index.ts'

EPERM: operation not permitted, unlink '/Users/dev/project/node_modules/.cache/xxx'

Error: permission denied, mkdir '/workspace/.codex'

如果是在 Windows 上，unlink、rename报 EPERM 很常见，通常表示文件被占用，或者目录受保护。如果是在 macOS/Linux 上，更多是目录属主不对、执行用户不对、文件权限不够。

二、先判断是哪类原因

1. 当前目录没有写权限

比如项目目录是从别的用户复制来的，或者之前用sudo执行过安装命令，导致部分文件归root所有。Codex 后续用普通用户运行，自然无法修改。

Linux/macOS 下先看目录属主：

pwd ls -la ls -la src

重点看报错文件所在目录的属主和权限。如果看到文件属主是root，而你当前用户不是 root，就基本对上了。

查看当前用户：

whoami

2. 文件被占用或锁定

Windows 上比较常见。比如项目正在运行 dev server、测试进程、打包进程，或者 VS Code 插件、杀毒软件正在扫描文件。Codex 想删除或重命名文件时就可能报 EPERM。

可以先停掉开发服务：

Ctrl + C

如果是 Node 项目，也可以查一下是否还有残留进程：

tasklist | findstr node

需要结束时：

taskkill /F /IM node.exe

3. 项目放在受保护目录

不要把项目放在C:\Program Files、系统盘根目录、受企业策略保护的目录里。Windows 推荐放到用户目录下，例如：

C:\Users\你的用户名\Projects\demo

macOS/Linux 推荐放在自己的 home 目录下：

/Users/dev/projects/demo /home/dev/projects/demo

4. Codex 的工作目录不对

有时不是权限问题，而是 Codex 在错误目录里执行修改。比如你在上级目录启动，它尝试写入一个不存在或无权限的路径。

启动前确认目录：

cd /path/to/your/project pwd ls

在 Windows PowerShell 里：

cd D:\Projects\demo Get-Location dir

三、逐步修复方法

步骤 1：确认报错文件能否手动写入

不要直接猜，先手动测试一下。Linux/macOS：

echo test >> ./codex-permission-test.txt rm ./codex-permission-test.txt

Windows PowerShell：

"test" | Out-File .\codex-permission-test.txt Remove-Item .\codex-permission-test.txt

如果这个测试都失败，说明不是 Codex 的问题，而是当前目录本身不能写。

步骤 2：修复目录属主

Linux/macOS 下，如果项目文件被 root 或其他用户占用，可以把项目目录改回当前用户。注意只对自己的项目目录操作，不要对系统目录乱执行。

sudo chown -R $(whoami) /path/to/your/project

然后再检查：

ls -la /path/to/your/project

如果只是某个目录没有写权限，可以补充写权限：

chmod -R u+rw /path/to/your/project

一般不建议直接chmod -R 777，虽然短时间看起来能解决，但会留下安全和协作问题。

步骤 3：清理被占用的缓存和构建目录

Codex 修改项目时，报错路径如果在node_modules、.next、dist、build、.cache里，优先考虑停进程后清缓存。

rm -rf node_modules/.cache rm -rf dist build .next

Windows PowerShell：

Remove-Item -Recurse -Force .\dist, .\build, .\.next -ErrorAction SilentlyContinue Remove-Item -Recurse -Force .\node_modules\.cache -ErrorAction SilentlyContinue

如果 Windows 删除仍然失败，先关掉 VS Code、终端、浏览器预览进程，再试一次。实在不行，重启后第一时间删除，通常能处理文件锁。

步骤 4：避免用 sudo 运行包管理命令

很多 EPERM 是前面埋下的坑：安装依赖时用了sudo npm install，后面普通用户就改不了生成的文件。

推荐修复 npm 全局目录，而不是长期 sudo：

mkdir -p ~/.npm-global npm config set prefix '~/.npm-global'

然后把下面内容加入 shell 配置，例如~/.zshrc或~/.bashrc：

export PATH=~/.npm-global/bin:$PATH

重新加载：

source ~/.zshrc

步骤 5：检查 Codex 配置目录

如果报错路径指向.codex、用户配置目录或缓存目录，也要检查这些目录权限。比如：

ls -la ~/.codex ls -la ~/.config

修复方式同样是把属主改回当前用户：

sudo chown -R $(whoami) ~/.codex ~/.config

如果你在公司网络或受限环境里使用 Codex，经常还会同时遇到接口连接失败、超时、鉴权异常等问题。我的习惯是先把本地权限问题排干净，再考虑网络和 API 通道。需要稳定中转时，可以了解一下 token云桥AI中转站 0029.org，适合做接口连通性验证和备用通道，不要把本地 EPERM 和网络问题混在一起排。

四、修复后的验证方式

权限修完后，不建议直接让 Codex 大范围改代码。先做小动作验证。

1. 验证当前目录写入

echo ok > codex-write-check.txt cat codex-write-check.txt rm codex-write-check.txt

Windows PowerShell：

"ok" | Out-File .\codex-write-check.txt Get-Content .\codex-write-check.txt Remove-Item .\codex-write-check.txt

2. 验证依赖和构建

如果刚清理过缓存或构建目录，重新安装和构建一次：

npm install npm run build

pnpm 项目：

pnpm install pnpm build

如果构建能正常跑，说明文件读写基本恢复。

3. 让 Codex 做一次小改动

例如只让它修改 README 或加一行注释。确认不会再出现 EPERM 后，再让它处理复杂任务。这样可以避免一次失败后留下半改状态。

五、避免复发的几个习惯

• 项目放在用户目录，不放系统保护目录。
• 不要混用管理员终端和普通终端修改同一个项目。
• 尽量不要用sudo npm install、sudo pnpm install。
• Codex 操作前先停掉 dev server、测试监听、打包进程。
• Windows 上遇到删除失败，优先怀疑文件占用，而不是马上重装工具。
• 把node_modules、dist、.next这类生成目录排除在不必要的扫描和同步之外。

总结

Codex 的 EPERM 本质上多数是文件系统权限或文件占用问题。排查顺序建议固定下来：先看报错路径，再测当前目录写入，再查属主和占用，最后清缓存、修权限、重新验证。不要一开始就重装 Codex，也不要随手给全目录777。按路径和权限一步步查，通常很快能定位到真正原因。