第一次使用 Codex，先守住这 5 条安全边界

Codex 的不同，不在于回答更像程序员

普通聊天窗口给你一段建议，Codex 在获得权限后可以直接读取文件、修改代码、运行命令、访问网络或调用外部工具。价值来自这一步，风险也来自这一步。

任务边界没有写清时，问题不只是“答案不好”。它可能打开错误目录、改到范围外文件，或者把本地完成误认为已经部署。

OpenAI 的公开安全说明把 sandbox 和 approvals 分开：sandbox 约束技术执行范围，approvals 决定哪些越界动作需要明确同意。这两层能帮助控制执行，却不会替你定义任务目标。

第一次使用 Codex，我更关心它能否在一个很小的范围内停得住、说得清、退得回，而不是一次改多少代码。

第一步：只把当前项目当作工作区

最容易犯的错，是为了方便把整个主目录交给 Agent。这样项目代码、个人文档、下载文件、浏览器数据和密钥目录都可能进入可见范围。

第一次任务应该满足：

• 工作区是一个明确项目目录。
• 项目里没有真实生产密钥。
• 示例数据可以丢弃。
• 修改范围能被几眼看完。
• 即使任务失败，也不会影响其他项目。

如果只是练习，可以新建一个最小 HTML 页面或使用可丢弃的示例仓库。先观察 Codex 会读取哪些文件、提出哪些命令、怎样描述改动，再进入真实项目。

第二步：把“能做什么”拆成权限矩阵

权限不是只有允许和禁止两种。可以按风险分层：

只读：查看文件、搜索代码、解释结构。

工作区写入：修改当前项目内已约定文件。

执行命令：运行构建、测试或本地脚本。

网络访问：下载依赖、查文档、调用 API。

系统修改：安装全局软件、修改 shell、服务或权限。

外部动作：提交、推送、部署、发消息、发布或扣费。

一项任务通常只需要前两到三层。不要因为最终可能部署，就一开始开放所有权限。

OpenAI 的安全说明强调网络也应受到边界控制：熟悉、低风险的目标与开放式出站访问不是一回事。对新手来说，最简单的做法是任务里明确“不要联网”“不要安装依赖”或“只允许查官方文档”。

第三步：密钥和生产数据单独处理

不要把 API Key、Cookie、OAuth Token、私钥和密码粘进提示词、源码或聊天截图。

如果任务必须调用服务，优先使用：

• 测试账号。
• 临时或低权限密钥。
• 脱敏数据。
• 只允许当前项目读取的环境变量。
• 不会进入日志的凭证通道。

还要检查代码本身是否会打印环境变量、请求头或完整错误对象。Agent 没有主动“偷密钥”，也可能因为调试输出把它写进文件。

如果真实生产凭证不是任务必需，就让它完全离开工作区。

第四步：危险命令必须带范围和后果

删除、覆盖、批量替换、数据库迁移和 Git 历史操作都可能不可逆。

一个可靠的执行请求至少说明：

• 命令要改变什么。
• 影响哪些文件或数据。
• 为什么当前任务需要。
• 是否有更小范围的替代方案。
• 怎样回退。
• 执行后看什么判断结果。

尤其不要把“帮我修好项目”理解成可以清理所有未提交文件。工作区里的改动可能来自你、其他工具或另一个并行任务。

当出现意外变化时，正确动作是停止并确认来源，不是用破坏性命令把整个目录恢复到某个历史点。

第五步：外部动作永远单独授权

本地代码能运行，不等于可以提交 Git。

测试通过，不等于可以推送。

预览页面正常，不等于可以部署生产。

接口返回成功，不等于平台已经出现结果。

把这些动作拆开有两个好处：你清楚知道风险何时从本地进入外部世界；每一步也能使用对应证据验收。

一次授权只覆盖当前明确动作。上次允许部署，不代表后续修改可以自动上线。

第一个任务应该怎样写

一个可执行任务包含五部分。

目标

用户最终应该看到什么，而不是只说“优化一下”。

范围

允许读取和修改哪些文件。

边界

不能安装、不能联网、不能改配置、不能发布或不能触碰什么。

验收

用页面、命令、测试或输出文件判断成功。

停止条件

遇到缺文件、冲突、权限不足或意外变化时应该停下并报告什么。

例如：

目标：
让示例首页在 390 像素宽度下不出现横向滚动。

范围：
只读取 index.html 和 styles.css，只允许修改 styles.css。

边界：
不要安装依赖，不要访问网络，不要执行 Git 或部署动作。

验收：
使用现有预览方式打开页面，确认正文、图片和按钮都在视口内。

停止条件：
如果问题来自其他文件，先指出文件，不扩大修改范围。

这比“帮我把网站改好看一点”更容易得到可控结果。

第一次协作的安全流程

执行前

1. 确认当前工作目录。
2. 备份不可替代数据。
3. 查看是否有自己尚未保存的修改。
4. 明确允许触碰的文件。
5. 移走不必要的凭证。
6. 写下禁止的外部动作。

执行中

1. 让 Codex 先说明准备读取什么。
2. 修改保持在约定范围。
3. 高风险动作先解释后果。
4. 出现意外文件变化立即停止。
5. 同一种方式连续失败时缩小问题，不扩大权限碰运气。

执行后

1. 阅读实际改动，而不是只看总结。
2. 用与目标对应的方法验收。
3. 检查没有新增密钥、临时文件和内部地址。
4. 区分本地完成与外部完成。
5. 决定是否需要下一步提交或部署。

怎样理解 sandbox 和 approvals

sandbox 是技术边界，例如允许写当前项目、保护其他路径、限制网络。

approvals 是决策边界，例如某个动作超出默认范围时，需要你明确允许。

两者都重要，但它们不替代备份、代码审查和目标定义。一个命令即使在 sandbox 内，也可能删掉当前项目的重要文件；一个获得批准的网络请求，也可能把不该发送的数据交给外部服务。

不要把“系统允许”理解成“业务上正确”。

Codex 声称完成时，要问证据属于哪一层

不同证据只能证明不同事实：

• 文件存在：证明本地写入发生。
• 构建通过：证明当前构建条件满足。
• 测试通过：证明这些测试覆盖的行为通过。
• 页面截图：证明某个视口下看到的结果。
• Git 提交：证明变更进入本地历史。
• 推送回执：证明远程仓库收到提交。
• 生产 URL 回读：证明公开环境返回结果。

任何一项都不能自动代表后面的全部完成。最常见的误会是把“本地构建成功”说成“已经上线”。

出现问题时不要急着一键回退

如果 Codex 修改了范围外文件：

1. 停止继续执行。
2. 记录哪些文件发生变化。
3. 区分本轮改动和原有未提交改动。
4. 只处理能确认属于本轮的部分。
5. 不使用会覆盖整个工作区的破坏性命令。

如果它连续两次用同一种方式失败，换验证路径或缩小任务。失败两次并不意味着要给更高权限。

如果它说完成却没有证据，状态就是未确认。要求它指出文件、命令结果或外部回读；拿不到时不要替它补结论。

第一次任务到这里就够了

不是 Codex 写了多少代码，而是：

• 改动只发生在约定范围。
• 你能说明为什么这样改。
• 验收证据与用户目标对应。
• 没有暴露凭证和生产数据。
• 没有未经授权的 Git、部署、发布或扣费动作。
• 出现问题时知道怎样停。

先在可丢弃的小项目里完成一次受控协作。等你能指出它读了什么、改了什么、怎样验收、哪里没有越界，再把同样的规则带进真实仓库。