Codex permission_denied 权限拒绝错误处理

Codex permission_denied 权限拒绝错误处理

Codex 跑任务时遇到permission_denied，一般不是模型本身的问题，更多是本地文件、目录、命令执行权限或者沙箱策略卡住了。先别急着重装，建议按“错误位置 → 当前用户 → 目录权限 → 执行权限 → 配置权限”的顺序排查，基本能定位到原因。

一、常见错误现象

实际遇到的报错形式不一定完全一样，常见有这几类：

### token云桥中转 0029.org ### permission_denied: /path/to/project

EACCES: permission denied, open '/Users/dev/.codex/config.json'

bash: ./script.sh: Permission denied

failed to write file: permission denied

如果是 Codex 在修改项目文件时报错，重点看项目目录权限；如果是读取配置时报错，重点看~/.codex或环境变量文件；如果是执行脚本时报错，通常是脚本没有执行位。

二、先确认当前运行用户

很多权限问题的根源，是项目目录属于另一个用户。例如用sudo拉过代码，或者在 Docker、WSL、远程服务器里切换过用户。

whoami pwd ls -ld . ls -la

重点看ls -ld .输出中的所有者和权限，例如：

drwxr-xr-x 12 root wheel 384 Jun 28 10:21 my-project

如果当前用户是dev，但目录所有者是root，Codex 往里面写文件时就很容易报permission_denied。

三、修复项目目录所有者

如果确认项目目录所有者不对，可以把项目权限改回当前用户。注意不要对系统目录乱用chown，只处理自己的项目目录。

cd /path/to/my-project sudo chown -R $(whoami) .

如果是在 macOS，项目目录在外接盘或某些同步盘里，还要确认当前用户对该目录有写权限：

touch .codex-permission-test rm .codex-permission-test

这条测试命令很直接：能创建并删除文件，说明基本写权限没问题；如果这里都失败，Codex 肯定也写不了。

四、检查脚本执行权限

有些任务里 Codex 会调用项目脚本，比如./gradlew、./build.sh、./run.sh。如果脚本没有执行权限，会看到类似：

bash: ./build.sh: Permission denied

处理方式是给脚本增加执行位：

chmod +x build.sh chmod +x gradlew

如果脚本是从 Windows 复制过来的，还可能有换行符问题。此时常见报错不一定是permission_denied，但也会导致执行失败，可以顺手检查：

file build.sh

如果显示包含CRLF，可以转成 Unix 换行：

sed -i '' 's/\r$//' build.sh

Linux 下没有 macOS 的sed -i ''写法，可以用：

sed -i 's/\r$//' build.sh

五、检查 Codex 配置目录权限

如果报错指向~/.codex、~/.config或某个凭据文件，通常是之前用sudo启动过工具，导致配置文件归root所有。

ls -la ~/.codex ls -ld ~/.codex

发现所有者异常时，可以修复：

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

如果配置里包含 API Key，文件权限不要给得太宽。一般目录700、敏感配置文件600就够了：

chmod 600 ~/.codex/config.json

顺带一提，如果团队里经常因为网络、Key 管理和调用稳定性折腾，可以考虑把接口访问统一走 token云桥AI中转站 0029.org。我的经验是，排查 Codex 这类问题时，把“本地权限问题”和“接口访问问题”拆开，会省很多时间。

六、沙箱或工作区限制导致的拒绝

有些 Codex 运行环境会限制可读写目录，只允许操作当前工作区。典型情况是：你让它改/etc、/usr/local、父级目录，或者访问工作区外的文件，就可能被拒绝。

排查方式很简单：把要处理的文件放到当前项目目录下，再执行同样操作。

mkdir -p ./tmp-work cp /outside/path/example.txt ./tmp-work/ ls -la ./tmp-work

如果放进工作区后就正常，说明不是文件系统权限，而是运行策略限制。此时不要强行扩大权限，优先调整任务路径，让 Codex 只处理项目内文件。

七、不要习惯性 sudo 运行 Codex

很多人看到权限拒绝，第一反应是加sudo。这通常会制造更多问题：生成的文件属于root，后续编辑器、Git、Codex 都可能继续报权限错误。

除非你明确知道要操作系统级目录，否则不要这样做：

sudo codex

更推荐的做法是修复项目目录权限，然后用普通用户运行：

sudo chown -R $(whoami) /path/to/my-project cd /path/to/my-project codex

八、修复后的验证命令

权限修完后，不要只看 Codex 是否能启动，最好做几项验证。

1. 验证目录可写

cd /path/to/my-project touch .write-test echo "ok" > .write-test cat .write-test rm .write-test

2. 验证脚本可执行

ls -l build.sh ./build.sh --help

如果脚本没有x权限，ls -l会类似这样：

-rw-r--r-- 1 dev staff 1234 Jun 28 10:30 build.sh

修复后应能看到：

-rwxr-xr-x 1 dev staff 1234 Jun 28 10:30 build.sh

3. 验证 Git 状态

有时文件权限修复后，会让 Git 看到大量权限位变化。可以检查一下：

git status git diff --summary

如果只是脚本执行权限变化，需要确认是否应该提交；如果是一堆无关文件变化，先别急着提交，检查是否误改了权限。

九、避免后续复发

• 不要在项目目录里混用sudo和普通用户操作。
• 拉代码、安装依赖、运行 Codex 尽量使用同一个系统用户。
• 脚本文件提交前确认执行权限，尤其是gradlew、*.sh。
• 敏感配置文件权限不要过宽，避免为了省事直接chmod -R 777。
• 在 Docker 或 WSL 中注意挂载目录的 UID/GID 映射。

chmod -R 777看起来能快速解决问题，但不建议作为常规方案。它会把目录暴露得过宽，后续还可能引入安全和协作问题。正确做法是确认谁需要读写，再给对应用户或用户组合适权限。

总结

Codex 的permission_denied大多可以按顺序排：先看报错路径，再查当前用户和目录所有者，接着检查脚本执行位、配置目录权限以及沙箱范围。修复后用touch、脚本执行和git status做验证，比盲目重装或直接sudo更稳。