1. 从一次误删说起Codex Full Access 到底在什么条件下会出事GPT-5.6 误删文件这件事真正值得关注的不是“模型会不会发疯”而是它在什么组合下会把错误命令的影响面放大。我梳理了公开报告和官方回应风险集中出现在三个条件同时成立时Codex 以 Full Access 运行、没有沙箱保护、没有自动审查。部分案例还涉及模型错误处理$HOME临时目录把本该清理的临时文件路径展开成了用户主目录下的真实文件。换句话说问题不是“一开 Codex 就删库”而是“模糊目标 大权限 无人确认”三者叠加。你让 Agent 帮你“清理一下旧文件”它拿到 Full Access 后可能把~/Downloads里三个月前的文件全当成旧文件处理。这不是模型恶意而是权限边界没画清楚。所以这篇不讨论“要不要用 Codex”而是回答一个更具体的问题Full Access 还能不能开我的结论是——可以开但必须先把 AGENTS.md 的行为约束和 config.toml 的沙箱审批策略配好让“能碰哪里”和“碰之前要不要问”这两件事有明确答案。下面给出可直接复制的配置骨架以及一次误删复现验证动作帮你判断自己的场景是否值得开全权限。2. 前置准备TaoToken 接入 Codex 的 Key 与端点在动配置之前先把模型接入这一层理顺。Codex 这类编码 Agent 需要稳定的模型端点我用的是 TaoToken 的 API 接入方式。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时直接写这个。你需要先拿到 API Key。进入控制台创建密钥https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 然后在 API Keys 页面生成https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。生成后复制那串sk-开头的密钥后面写进环境变量。如果你还没决定用哪个模型可以先在模型对话页试一下 GPT-5.6 的指令遵循表现https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。这一步不是必须但能帮你确认模型对“只改当前目录”这类约束的响应质量。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的端点说明和参数格式。我实测下来Codex 的配置文件和 TaoToken 的 OpenAI 兼容端点对接很直接关键是别把 Key 硬编码进仓库用环境变量注入。3. 可复制配置AGENTS.md 行为护栏 config.toml 沙箱审批骨架这一节是全文核心。分两个文件AGENTS.md 负责“告诉 Agent 什么该问”config.toml 负责“从系统层面限制它能碰什么”。两者缺一不可AGENTS.md 不是沙箱它拦不住一个已经拿到 Full Access 的进程但它是第一道行为护栏。3.1 AGENTS.md 文件系统安全段把下面这段放进项目根目录的 AGENTS.md。核心思路不是堆禁止词而是要求危险操作走同一套确认流程## 文件系统安全 - 工作区内的正常修改及用户明确点名的少量文件删除可直接执行递归、批量、目录、未跟踪文件或未明确涉及的删除必须确认。 - 跨工作区修改仅限用户明确指定的目标删除、递归移动或覆盖前必须展示真实绝对路径、影响数量和相关 git status并获得单独确认。 - 禁止递归删除 /、$HOME 本身、~/.codex 及系统目录不得通过环境变量、符号链接或挂载点绕过工作区边界。 - rm -rf、git clean、git reset --hard、find -delete、xargs rm 及通配符删除仅在用户明确要求并确认具体目标后执行。 - 不得为通过构建或测试而擅自删除文件也不得削弱沙箱、审批或权限配置。这段看着啰嗦但它把“清理一下”“重新生成一下”这类模糊词翻译成了可检查的动作。Agent 看到“清理旧文件”现在得先把旧文件是哪几个、在哪里、删完能不能恢复摆到你面前。3.2 config.toml 沙箱与审批策略Codex 的配置文件通常在~/.codex/config.toml。下面是一个收紧后的骨架重点是sandbox_mode和approval_policy两个字段# ~/.codex/config.toml # 默认使用工作区写入沙箱越界时请求批准 sandbox_mode workspace-write approval_policy on-request [sandbox_workspace_write] # 允许写入的目录只列当前项目 writable_roots [/Users/yourname/projects/current-project] # 网络访问按需开启默认关闭 network_access false [history] # 保留会话历史便于回溯 Agent 做过什么 persistence save-all [model] # 通过 TaoToken 接入 provider openai-compatible base_url https://taotoken.net/api model gpt-5.6关键参数对照参数作用建议值sandbox_mode限制文件系统访问范围workspace-writeapproval_policy越界操作是否弹窗确认on-requestwritable_roots显式声明可写目录只写当前项目路径network_access是否允许沙箱内联网默认false如果你确实需要 Full Access不要全局常开。我的做法是分析代码用只读日常改项目用workspace-write只有任务确实要访问工作区外文件时才临时提升任务结束立刻切回。这不是绑住 AI 手脚而是给它一张只能刷当前订单的卡而不是把银行卡和保险柜钥匙全塞给它。4. 验证请求一次误删复现与拦截确认配置写完不验证等于没写。下面这个动作能帮你确认 AGENTS.md 和沙箱是否真的生效。准备一个临时测试目录里面放几个假文件mkdir -p /tmp/codex-safety-test/keep /tmp/codex-safety-test/old touch /tmp/codex-safety-test/keep/important.txt touch /tmp/codex-safety-test/old/temp1.log /tmp/codex-safety-test/old/temp2.log cd /tmp/codex-safety-test git init git add . git commit -m init然后在 Codex 里发一条模糊指令比如“帮我清理一下旧文件”。观察它的行为如果配置生效它应该先列出old/下的文件、说明影响数量、请求你确认而不是直接执行rm。如果它直接删了说明 AGENTS.md 没被读取或沙箱没生效。再测一次越界场景。让它“把~/Downloads里的临时文件清掉”在workspace-write模式下这个操作应该被沙箱拦截并弹出审批请求。你可以拒绝然后检查~/Downloads是否原封不动。验证成功后你会看到类似这样的输出结构[Codex] 检测到删除操作目标/tmp/codex-safety-test/old/ 影响文件temp1.log, temp2.log共 2 个 当前 git statusclean 是否确认执行(y/N)这一步的意义在于你亲眼确认了“模糊指令 大权限”被拦在了确认环节。如果拦截没出现回到第 3 节检查approval_policy是否写成了never。5. 本篇常见错排查配置过程中容易踩几个坑我逐个列出来。AGENTS.md 没生效确认文件放在项目根目录且 Codex 启动时的工作目录就是项目根。有些朋友在子目录里放 AGENTS.mdAgent 读不到。另外检查文件名大小写必须是AGENTS.md。沙箱模式写了但还能越界sandbox_mode和approval_policy要配合使用。只写workspace-write但approval_policy never越界操作会被直接拒绝而不是请求批准体验上像“没反应”。建议用on-request。writable_roots 路径写错这个字段要写绝对路径不能用~或相对路径。写错了会导致工作区内也无法写入Agent 报权限错误。API 端点配错TaoToken 的 API 地址是https://taotoken.net/api不要带 UTM 参数也不要漏掉/api。如果报 401先检查 Key 是否复制完整、环境变量是否注入成功。误删后想恢复Git 是第一层回退远端仓库是第二层系统备份是第三层。如果文件没提交过 GitGit 救不了如果生产库被清空备份是唯一出路。所以最小权限和备份要放在前面别等出事再找后悔药。Full Access 下 AGENTS.md 形同虚设这是最需要记住的一点。AGENTS.md 是行为约束不是系统沙箱。Full Access 意味着进程层面没有限制AGENTS.md 只能靠模型自觉遵守。所以 Full Access 必须配合“临时提升 任务结束切回”的使用习惯。6. 长期编码与 Agent 场景的权限管理建议如果你只是偶尔用 Codex 改改脚本上面的配置够用了。但如果你把 Codex 或 Claude Code 当成日常编码主力甚至跑长时间 Agent 任务权限管理需要再升一级。第一把 Agent 的工作放在干净的 Git 仓库或 worktree 里。需要试错就建临时项目需要迁移就先连测试库需要处理真实数据就先导副本。这件事升级的不是权限设置而是工作边界——不是让 Agent 记住哪些东西重要而是让它默认碰不到。第二长期高频使用建议走 Coding Plan把模型调用和额度管理集中起来https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。这样你不用每次手动配 Key也能统一看到用量。第三如果你用 Claude Code 做 Agent 任务接入方式参考https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-codeutm_campaignrewrite 。它的权限模型和 Codex 类似同样需要沙箱加审批的组合。每次准备让 Agent 干稍微大的活先过一遍这 6 个问题这次真的需要 Full Access 吗工作目录是不是只有当前项目是否会碰到生产库、密钥、主目录或备份删除覆盖迁移前有没有列出目标和数量Git 状态是否干净、重要改动有没有提交真删错了从哪里恢复花不了一分钟但能把“AI 帮我省半小时”和“我花半天救数据”隔开很远。GPT-5.6 这次讨论不必靠恐慌收场更该升级的是使用方式。AI Agent 可以更主动但主动不等于拥有一切权限。真正成熟的 AI Coding是让它只在该做的范围里把事情做好。