先搞懂 Codex 的沙箱和审批，再让它碰你的数据

先讲结论：两个开关，分开配

Codex 的安全边界由两个东西决定，它们是分开的：

• 沙箱模式：它能碰到什么
• 审批策略：它什么时候停下来问你

很多人把这两个混成一个「权限」概念，结果配出奇怪的组合。分开理解就清楚了：**沙箱是围墙，审批是门卫。**墙决定范围，门卫决定要不要放行。

还有一件事值得先说：这层边界是操作系统在执行，不是靠指令约束。也就是说，即使你在对话里说「你可以改这个文件」，只要沙箱不允许，它也改不了。

这个性质很实在——**安全边界不会因为提示词写得不好而失效。**这和「在提示词里写一句不要删文件」是完全不同量级的保障。

沙箱模式：三档

workspace-write 是默认值，也是最常用的

日常干活基本都在这一档。它允许的范围是「当前工作区」，而工作区就是你启动 Codex 的那个目录。

这一点值得单独强调，因为它意味着：「在哪启动」和「它能改什么」是同一件事。

在家目录裸跑 codex，等于把整个家目录设成了可写范围——你的文档、下载、各种配置文件，全在里面。这不是危言耸听，这是默认行为。

所以最该养成的习惯不是配置技巧，而是：每类活一个目录，进目录再启动。

read-only 被低估了

只读这一档常被跳过，觉得「什么都改不了那还要它干嘛」。

实际上跨境运营里有一大半的活只读就够：算指标、找异常、对比差异、分类邮件。这些活的输入是你导出来的文件，输出是一份分析结论——它不需要改任何东西。

用只读的好处是你几乎不用担心它做错什么。最坏结果是分析得不对，你看一眼就发现了，而不是数据被改掉了。

建议把只读当默认起手式，确实需要写文件了再往上调。

danger-full-access 只在容器里用

官方标了高风险，说明写得很直白：没有沙箱、没有审批，能访问主机的任何部分，一个恶意项目可以把机器上能拿到的东西都带走，包括凭据。

跨境团队的机器上通常有什么？平台账号的登录态、API 密钥、客户数据导出、供应商合同、财务表格。这些一旦被带走，损失不是「AI 改错了个文件」的量级。

所以规则很简单：**要用全权限，就在容器里用。**在 Docker 之类的隔离环境里，最坏结果被限制在容器内。不要在日常办公的机器上直接开。

审批策略：两档

never 最常被误解成「什么都能干」。不是的——它只是不问你，沙箱该拦的还是拦。

所以 read-only 加 never 反而是个很安全的组合：不打扰你，也改不了东西。这正是定时任务和脚本该用的档位。

还有一种细粒度策略，可以对某几类审批保持交互、其余自动拒绝。做复杂流程时用得上，入门阶段用不到。

另外要知道一个历史变化：早期有个 untrusted 策略，现在已经不再支持。如果你在网上看到的老教程里提到它，那份教程大概率还有别的地方也过时了。

常用组合

命令行写法：

codex --sandbox read-only --ask-for-approval on-request

非交互跑的时候：

codex exec --sandbox read-only --ask-for-approval never

--ask-for-approval never 有个简写是 -a never。全权限那个参数还有个别名叫 --yolo，名字本身就是提醒。

审批弹出来的时候，怎么判断

配好之后，实际用起来最常遇到的场景是：它停下来请求批准。这时候该看什么？

**先看它要干什么，而不是急着批。**审批请求会说明它想执行的操作。三类最常见：

• 要写工作区外的文件：先想清楚为什么它需要动那个位置。多数情况说明你启动的目录不对，应该换个目录重来，而不是批准它越界
• 要联网：确认这次任务确实需要联网。如果你以为这是个纯本地的分析任务，它却要联网，那值得停下来问清楚
• 要跑一条受限命令：看清楚这条命令做什么。删除、覆盖、批量操作类的要特别留意

**批准一次不等于长期放开。**遇到某类操作反复要批，说明你的权限档位和任务类型不匹配，该去改配置，而不是每次点确认——点习惯了就等于没有审批。

网络默认是关的

这是跨境场景最容易踩的一条，值得单独成节。

默认情况下，Codex 跑的命令没有网络。所以你让它抓竞品页面、查关键词、调平台接口，它会失败——不是它不会，是沙箱不让。

打开方式，写进配置：

[sandbox_workspace_write]
network_access = true

或者命令行临时开一次：

codex -c 'sandbox_workspace_write.network_access=true'

**建议用后者。**理由是网络一开，风险模型就变了。

原本它只能读你的文件，出不去；开了网络之后，它既能读你的本地文件，又能往外发请求。这两个能力单独看都还好，叠加起来才是真正需要警惕的组合——尤其当工作区里放着客户数据、财务表格或者带密钥的配置文件时。

所以推荐做法：**全局保持关闭，只在明确需要联网的那一类任务里临时开，做完就没了。**并且那个目录里只放调研数据，别放别的。

跨境活该配哪一档

按需要的权限，跨境团队的活正好分三类。

只读就够的

• 广告报表诊断：按口径算 ACoS、ROAS，找出花费超阈值零订单的词，输出否定词候选
• 库存盘点：按销速算断货天数，标出补货紧急和长期滞销的 SKU
• 毛利核查：把售价、成本、运费放一起算，找出毛利为负的。促销改过价、运费调整过、汇率变了，都可能让某几个 SKU 变成卖一件亏一件，而后台不会提醒你
• 合同和平台政策：抽关键字段，新旧两版做差异对比，出风险清单
• 客服邮件分类：按类型分流，把需要升级处理的挑出来

配 read-only。

要写文件的

• 生成 Listing 草稿和多站点版本
• 批量生成或修订商品页 SEO 信息
• 生成周报月报
• 整理和重组资料

配 workspace-write，并且把工作区限定在专门的目录里。工作区越小，边界越清楚。

要联网的

• 选品调研，抓竞品页面和评论
• 竞品价格和库存监控
• 调平台接口取数据

在 workspace-write 基础上临时开网络。

另外提醒一句：抓取要守目标站点的规则，只抓公开可见的内容，控制频率，不绕登录和验证。技术上能抓，不等于抓了没风险。

沙箱管不了什么

最后说清楚边界的边界，这部分最容易被忽略。

沙箱管的是「它能碰到什么」，管不了「这个决定对不对」。

它拦不住一份口径算错的报表——数据没被改，报表也是新写的文件，完全合规，但结论是错的。

它拦不住一段有合规风险的 Listing 文案——写进文件而已，沙箱不会觉得有问题。

它拦不住一个不该发给客户的承诺——只要那句话最后是人发出去的。

所以下面这些动作，无论沙箱怎么配，都要留人：

• 对客户发出的承诺：退款、赔付、补发
• 改价格、改库存、上下架
• 改广告预算和竞价
• 上架 Listing、发布页面、发社媒
• 涉及客户个人信息和平台账号凭据的操作

做法是让它把草稿和依据准备好，最后一步由人点头。

**技术边界靠沙箱，业务边界靠规则和流程，两个都要有。**下一篇讲业务边界那一半怎么写。

非交互跑的时候，边界怎么定

前面讲的都是你坐在终端前的情况。真正省时间的用法是让它跑在脚本或定时任务里，那时候没人守着，边界要另外想。

用 codex exec 跑非交互任务：

codex exec --sandbox read-only --ask-for-approval never "按 AGENTS.md 的口径分析 data/ads/ 下最新的广告报表，把诊断报告写到 reports/"

这里有个矛盾要处理：read-only 不能写文件，但你要它输出报告。两个解法：

• 让它把结果打到标准输出，由外面的脚本重定向到文件。权限最小，推荐
• 用 workspace-write，但工作区严格限定在只放报表和报告的目录里

选哪个看你的谨慎程度。第一种更干净——Codex 全程碰不到写权限，写文件这件事由你自己的脚本做。

三条非交互场景的额外规则：

**第一，绝对不要在非交互任务里用全权限。**没人看着的时候出问题，等你发现可能已经跑了很多轮。

**第二，--ask-for-approval never 要配合收紧的沙箱用。**这两个是一对：不弹审批，就得靠沙箱兜底。如果既不审批、沙箱又开得大，等于没有边界。

**第三，让它在数据缺失时明确失败。**这条要写进规则文件：今天的报表文件不存在就直接报错停止，不要用昨天的数据代替，也不要估算。

没有第三条，你可能某天发现连着一周的报告其实都是拿同一份旧数据算的——而报告本身看起来完全正常。

codex exec 还支持 --json 输出，方便外面的脚本解析结果做后续处理。

一个简单的决策表

拿不准的时候按这个走：

下一步

沙箱决定它能干到什么程度，规则决定它按什么标准干。下一篇讲 AGENTS.md：怎么把你们的指标口径、报告格式和禁止事项写成它每次都会读的文件。

参考资料

• Agent approvals & security
• Sandbox
• Config basics
• Developer commands