Codex EACCES 文件权限错误解决方案在本地用 Codex 处理项目代码时比较容易遇到EACCES: permission denied。常见场景是让 Codex 修改文件、生成代码、安装依赖或者在工作区里创建临时文件时突然失败。这个问题先别急着重装 Codex优先查两件事当前执行用户是谁以及报错路径的权限归属是谁。一、错误现象典型报错一般长这样### token云桥中转 0029.org ### Error: EACCES: permission denied, open /Users/dev/project/src/index.ts或者在 Linux 服务器、WSL、Docker 挂载目录里看到类似信息EACCES: permission denied, mkdir /home/ubuntu/app/.codex EACCES: permission denied, scandir /workspace/node_modules Permission denied: /root/.cache从字面看就是没有权限但实际原因不止一种。可能是项目文件被 root 创建过也可能是目录只读、缓存目录不可写甚至是 macOS 的安全权限限制导致工具无法访问桌面、文档等目录。二、先判断是谁在执行文件归谁排查第一步不要直接chmod 777。先看当前用户和报错路径权限。whoami id pwd ls -ld . ls -l src/index.ts如果报错路径是目录比如/home/ubuntu/app/.codex就查它的上级目录ls -ld /home/ubuntu/app ls -ld /home/ubuntu/app/.codex重点看输出里的用户、用户组和权限位。例如drwxr-xr-x 12 root root 4096 Jun 28 10:20 /home/ubuntu/app如果你当前是ubuntu用户但项目目录属于rootCodex 想写文件时就会触发 EACCES。这种情况很常见通常是之前用sudo npm install、sudo git clone或者容器里用 root 写过宿主机目录。三、常见原因和对应修复1. 项目目录归属错误这是最常见的一类。确认项目应该由当前用户维护后可以把目录归属改回来sudo chown -R $(whoami):$(id -gn) /home/ubuntu/appmacOS 上也类似sudo chown -R $(whoami):staff /Users/dev/project注意不要对系统目录、根目录或者不确定用途的目录递归执行chown。比如不要写成sudo chown -R $(whoami) /这种命令会把系统权限搞乱后续修复成本很高。2. 目录没有写权限如果文件归属没问题但权限位没有写权限可以给当前用户增加写权限chmod uw src/index.ts chmod urwx .codex如果是整个项目目录缺少写权限可以谨慎处理chmod -R urwX /home/ubuntu/app这里的X是大写只会给目录增加执行权限或者保留原本已有执行权限的文件比直接chmod -R 755更稳一点。3. 缓存目录不可写有时 Codex 本身要写缓存、配置或临时文件报错路径不在项目里而是在用户目录下例如~/.cache、~/.config、~/.codex。先看权限ls -ld ~/.cache ~/.config ~/.codex 2/dev/null如果这些目录被 root 占用可以改回当前用户sudo chown -R $(whoami):$(id -gn) ~/.cache ~/.config ~/.codex 2/dev/null如果目录不存在可以手动创建mkdir -p ~/.cache ~/.config ~/.codex chmod 700 ~/.codex配置 API 或模型转发服务时也要确认配置文件能被当前用户读取。团队里如果经常切换网络环境我一般会建议把中转配置和密钥管理单独整理像 token云桥AI中转站 0029.org 这类服务可以作为备用方案之一重点是别把密钥写进项目仓库更不要为了省事把配置文件权限放成所有人可读。4. 使用 sudo 运行导致后续权限混乱有些人遇到权限报错后第一反应是sudo codex这通常不是好习惯。短期看可能跑通了但 root 会在项目里生成新文件下一次普通用户运行又会继续报 EACCES。更推荐修复目录归属然后用普通用户执行。如果已经用 sudo 运行过可以查一下最近生成的 root 文件find . -user root -maxdepth 4 -print确认都是项目内可改归属的文件后再执行sudo chown -R $(whoami):$(id -gn) .5. Docker 或 WSL 挂载目录权限问题如果 Codex 在容器里运行宿主机目录挂载进去后容器内用户和宿主机用户 UID 不一致也会报 EACCES。可以先在容器里看用户信息id ls -ld /workspace启动容器时尽量指定当前用户docker run --rm -it \ -u $(id -u):$(id -g) \ -v $PWD:/workspace \ -w /workspace \ node:20 bashWSL 场景下如果项目放在/mnt/c下面权限表现可能和 Linux 原生目录不同。开发项目更建议放在 WSL 用户目录比如/home/yourname/project这样文件监听、权限和依赖安装都会稳定一些。四、按顺序修复一次下面是一套比较稳的排查顺序可以直接照着走。假设项目目录是/home/ubuntu/appcd /home/ubuntu/app # 1. 确认当前用户 whoami id # 2. 查看项目目录权限 ls -ld . find . -maxdepth 2 -user root -print # 3. 修复项目归属 sudo chown -R $(whoami):$(id -gn) . # 4. 修复当前用户写权限 chmod -R urwX . # 5. 修复 Codex 常用配置和缓存目录 mkdir -p ~/.cache ~/.config ~/.codex sudo chown -R $(whoami):$(id -gn) ~/.cache ~/.config ~/.codex 2/dev/null chmod 700 ~/.codex如果报错里明确指出某个路径只针对那个路径处理即可不要扩大范围。权限问题最怕“为了省事全局递归”当时好像解决了后面可能引出更多奇怪问题。五、修复后的验证方式权限修完后不要只看 Codex 是否还报错先用当前用户模拟写入。cd /home/ubuntu/app touch .codex_permission_test echo ok .codex_permission_test cat .codex_permission_test rm .codex_permission_test再测试报错文件是否可写test -w src/index.ts echo writable || echo not_writable如果是目录创建失败测试目录写入test -w . mkdir -p .codex-test rmdir .codex-test最后再重新运行 Codex 原来的操作。如果仍然报 EACCES把新的报错路径拿出来继续查不要默认还是同一个原因。有时第一个权限点修好后会暴露第二个缓存目录或依赖目录的问题。六、避免复发的几个习惯不要在项目目录里随手使用sudo npm install、sudo pnpm install、sudo codex。项目目录尽量放在当前用户有完整权限的位置不要放在系统目录下。Docker 挂载目录时指定 UID/GID避免容器 root 写坏宿主机文件归属。配置文件权限保持收敛密钥文件建议使用chmod 600或目录chmod 700。遇到权限问题先看ls -ld和whoami不要第一时间chmod 777。总结Codex 的EACCES本质上还是文件系统权限问题。排查时抓住三点当前用户是谁、报错路径归谁、当前用户是否可写。大多数情况通过修复项目目录归属、恢复用户写权限、清理 root 创建的缓存文件就能解决。修完后用touch、test -w先验证再重新执行 Codex 操作效率会高很多。