Codex 权限和沙箱怎么理解：什么时候该批准，什么时候该停

Codex 能读项目、改文件、运行命令，所以安全边界很重要。你看到“是否允许执行某个命令”的时候，不应该机械点同意，而要判断它是否和任务目标一致。

为什么会有审批

审批的意义是防止越界操作。常见需要你确认的场景包括：

这些不是 Codex “不够自动化”，而是把关键风险留给人确认。

如果命令满足三点，通常可以批准：

1. 和当前任务直接相关 2. 作用范围清楚 3. 失败后容易回滚

例如，为了验证前端页面而安装 Playwright 浏览器，范围明确；为了部署模板而重启对应 Halo 容器，也属于目标相关。

看到这些命令要停下来问清楚：

rm -rf ...
git reset --hard
docker compose down -v
chmod -R 777 ...
curl ... | sh

它们可能删除数据、丢弃本地改动、清空卷、扩大权限或执行未知脚本。除非你明确知道后果，否则不要批准。

线上修改建议按这个顺序：

1. 先读当前配置 2. 备份目标文件 3. 只改一个小范围 4. 重启单个相关服务 5. 验证健康状态 6. 验证页面或接口 7. 保留回滚路径

例如改 Halo 主题模板时，应该先备份 archives.html，再上传新模板，最后只重启 halo 服务，而不是重启整台机器。

涉及线上服务器时，请先说明要执行的命令、影响范围和回滚方式。
不要执行破坏性命令，除非我明确批准。
每次改配置前先备份原文件。

不要因为命令看起来“像开发命令”就批准。npm install 会改 lockfile，docker compose up 可能重建容器，git clean 会删除未跟踪文件。

不要把私钥、token、数据库密码粘贴到聊天里。需要使用密钥时，让 Codex 使用本机已有路径或服务器环境变量，不要把内容写进仓库。