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用户，但项目目录属于root，Codex 想写文件时就会触发 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 u+w src/index.ts chmod u+rwx .codex如果是整个项目目录缺少写权限，可以谨慎处理：
chmod -R u+rwX /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/app：
cd /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 u+rwX . # 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 操作，效率会高很多。