Agent Sandbox 技术原理：本地客户端与 Web 云端执行环境的双重实现

1.1 沙箱隔离的不是推理，而是副作用#

一个完整 Agent 系统通常可以拆成三个角色：

1
LLM Provider
2
  负责生成推理结果和 Tool Call
3
          ↓
4
Agent Harness
5
  负责循环、规划、上下文和工具编排
6
          ↓
7
Sandbox Runtime
8
  负责真正执行命令并限制副作用

LLM Provider 只负责计算下一步应该做什么；Agent Harness 把模型输出组织成任务状态和工具调用；真正危险的部分发生在最后一层，因为 Shell、Python、Git、编译器、浏览器和包管理器都要通过操作系统完成真实动作。

所以，大多数情况下并不需要把模型推理服务本身塞进沙箱。真正要进入沙箱的是模型触发的执行单元，包括：

• Shell 与脚本解释器；
• Python、Node.js、JVM 等语言运行时；
• Git、Maven、npm、pip 等开发工具；
• 编译器、测试进程和后台服务；
• 浏览器自动化环境与 Computer Use 进程；
• 可能包含第三方代码的 MCP Server 或插件运行时。

Agent Harness 可以位于沙箱外，但它启动的每一个命令、子进程和孙进程都必须从出生起就处于同一条安全边界内。否则，限制了最外层 bash，却放任它启动的 python 或 node 逃到宿主权限中，沙箱就只剩一张纸门。

1.2 Sandbox 与 Approval 是两套不同控制#

Agent 产品经常把“沙箱”和“用户审批”放在同一个界面中，容易让人误以为二者是一回事。实际上，它们回答的是两个不同问题：

1
Sandbox：
2
操作系统技术上允许这个进程做什么？
3

4
Approval：
5
当 Agent 想超出当前权限时，是否需要暂停并询问用户？

例如，一个本地 Coding Agent 可以被允许在项目目录内读写，但默认不能访问网络：

1
读取 /workspace/src                 → Sandbox 内允许
2
修改 /workspace/src                 → Sandbox 内允许
3
读取 ~/.ssh/id_rsa                  → Sandbox 拒绝
4
访问 package registry              → 触发 Approval
5
访问云元数据服务                    → 永久拒绝

审批通过也不应该等价于“关闭全部限制”。更稳妥的方式是只扩大一项具体能力，例如在本次命令中允许访问 pypi.org，而不是把 Agent 瞬间变成拥有整台机器权限的超级用户。

OpenAI 对 Codex 的公开定义也明确区分了两层：Sandbox 决定技术边界，Approval Policy 决定越过边界前何时询问；同时，Git、包管理器、测试运行器等派生命令会继承相同的沙箱限制。¹

1.3 Agent Sandbox 的五类控制目标#

从技术角度看，沙箱至少需要回答五个问题：

这五类控制不是互相独立的。例如，文件权限阻止 Agent 读取密钥，网络权限阻止已读取的数据被送出去，凭证代理则避免真实密钥从一开始就进入进程环境。真正可靠的沙箱往往来自多层限制的叠加，而不是某个“开启安全模式”的按钮。

2.1 本地客户端沙箱#

本地客户端包括 CLI、IDE 插件和桌面应用。它们的典型链路是：

1
用户本地项目
2
      ↓
3
CLI / IDE / Desktop Agent
4
      ↓
5
本地 Agent Harness
6
      ↓
7
操作系统沙箱
8
      ↓
9
本地 Shell、Git、编译器和测试工具

这种模式最大的优势是 Agent 可以直接使用用户现有开发环境：本地未提交修改、编译缓存、语言工具链、IDE 配置以及项目附近的依赖服务都触手可及。

但它的风险半径也非常现实。Agent 与用户的 SSH Key、云凭证、浏览器 Cookie、公司 VPN、Docker Daemon 和私人文件处于同一台机器上。沙箱的中心任务是：

允许 Agent 深入项目目录工作，同时阻止它横向进入用户电脑的其他区域。

2.2 Web 入口下的云端沙箱#

Web 模式通常不是让 Shell 在浏览器标签页里运行。主流云端 Agent 的浏览器页面只是任务入口和观察界面，真正的执行发生在服务端隔离环境中：

1
Browser
2
   ↓ HTTPS / Task API
3
Cloud Agent Service
4
   ↓
5
Cloud Sandbox
6
   ↓
7
远端仓库副本、Shell、编译器和测试进程

云端沙箱通常先创建容器或虚拟机，再 Clone 仓库、准备依赖、启动 Agent。用户最后看到的是日志、Diff、Commit、Pull Request 或构建制品，而不是云主机本身。

以 Codex 为例，当前环境模式明确区分 Local、Worktree 和 Cloud。Local 与 Worktree 都在用户电脑上运行，Cloud 则在配置好的远端环境中运行。²

2.3 浏览器原生沙箱是第三种概念#

还有一类技术确实在浏览器内部执行代码，例如：

1
iframe sandbox
2
Web Worker
3
WebAssembly / WASI
4
Pyodide
5
WebContainers
6
浏览器 Origin 隔离

它们依赖浏览器进程模型和 Web 权限体系，适合运行受限 JavaScript、Wasm 或部分语言环境。但对于需要完整 Linux 工具链、Docker、系统编译器或复杂后台服务的 Coding Agent，浏览器通常只承担控制平面，重执行仍然放在服务器端。

因此，本文后续使用“Web 云端沙箱”这个称呼，特指：

由 Web 页面发起，但在服务端容器、gVisor 或虚拟机中执行的 Agent Sandbox。

2.4 同一个 Sandbox，城墙朝向不同#

本地和云端沙箱共享很多底层积木，但它们的首要保护对象不同：

1
本地客户端沙箱：
2
防止 Agent 越过项目边界，进入用户真实电脑
3

4
Web 云端沙箱：
5
防止任务越过租户边界，进入云宿主、控制面或其他任务

本地沙箱包裹的是“真实工作区”；云端沙箱包裹的是“任务工作副本”。这一区别会一路影响文件挂载、进程身份、凭证来源、网络策略和状态保存方式。

图 2：本地沙箱从真实用户权限中做减法，重点保护用户设备；云端沙箱从临时任务身份开始做加法，同时保护平台和其他租户。

3.1 Command Runner：沙箱真正落地的边界#

错误的执行方式是让 Harness 直接调用宿主进程 API：

1
Tool Call
2
   ↓
3
ProcessBuilder / subprocess / exec
4
   ↓
5
Host Shell

此时 Agent 生成的命令与普通用户进程拥有同样的视野和权限。更合理的结构是加入一个专门的 Sandbox Launcher 或 Command Runner：

1
Tool Call
2
   ↓
3
Policy Check
4
   ↓
5
Sandbox Launcher
6
   ├── 创建 Namespace
7
   ├── 设置挂载和身份
8
   ├── 加入 cgroup
9
   ├── 移除 Capabilities
10
   ├── 加载 Seccomp / LSM
11
   └── 清理环境变量
12
   ↓
13
Restricted Child Process

沙箱不是命令执行后的补丁，而是命令启动前就确定好的出生环境。理想情况下，进程从 execve() 的第一条指令开始便没有机会接触宿主完整权限。

从实现上看，Policy Layer 不应直接输出一句模糊的“允许执行”，而应编译成一份可交给操作系统执行的 Launch Plan：

1
Executable       /usr/bin/python3
2
Argv             [python3, scripts/check.py]
3
WorkingDir       /workspace/project
4
WritableRoots    [/workspace/project, /tmp]
5
ReadableRoots    [/usr, /lib, /workspace/project]
6
DeniedPaths      [~/.ssh, **/.env]
7
Network          off / proxy-policy-id
8
ResourceGroup    cgroup-agent-run-42
9
Timeout          300s
10
Environment      allowlisted variables only

这个区分非常重要。模型收到的权限说明、Harness 做出的策略判断和内核真正执行的约束属于三层：

1
Prompt 中的权限说明     帮助模型少发出越权动作
2
Policy Engine           判断本次请求应允许、拒绝还是审批
3
OS Sandbox              即使模型或策略层出错，也负责最后强制执行

只把“不要读取某目录”写进 Prompt，属于行为引导，不属于安全边界；只在 Harness 中检查一次路径，也可能被子进程、符号链接或替代工具绕开。最终权限必须被翻译为挂载、身份、ACL、网络和系统调用等操作系统原语。

3.2 Namespace：给进程制造一套局部世界#

Linux Namespace 会虚拟化一部分全局系统资源，使不同进程看到不同的系统视图。常见类型包括 PID、Mount、Network、User、IPC、UTS 和 Cgroup Namespace。³

1
宿主看到：PID 24631
2
沙箱看到：PID 1

1
/
2
├── /usr          read-only
3
├── /bin          read-only
4
├── /etc          read-only
5
├── /tmp          private tmpfs
6
└── /workspace    writable

1
Sandbox netns
2
     eth0
3
       │
4
      veth
5
       │
6
Host bridge / firewall / proxy

1
Sandbox UID 0
2
       ↓ uid_map
3
Host UID 100000

3.3 cgroups：限制这套局部世界能吃多少资源#

Namespace 解决“看见什么”，cgroups 解决“最多能用多少”。cgroup v2 可以把一个任务的所有进程组织进同一层级，并使用控制器限制 CPU、内存、进程数和块设备 I/O。⁵

常见接口包括：

1
cpu.max        CPU 时间配额
2
cpu.weight     竞争时的调度权重
3
memory.high    内存软压力阈值
4
memory.max     内存硬上限
5
pids.max       最大进程数量
6
io.max         块设备 I/O 限制

Agent 场景中，pids.max 尤其重要。Fork Bomb 可以在超时机制来得及反应前快速创建大量进程，耗尽系统 PID 和调度资源。执行超时控制的是“运行多久”，pids.max 控制的是“能长出多少枝杈”，两者不能互相替代。

所有后代进程都应留在同一个 cgroup 中：

1
bash
2
 └── npm
3
      └── node
4
           └── child_process

任务取消时，系统需要终止整个 cgroup，而不是只杀最外层 Shell。否则后台服务可能已经脱离父进程，继续占用端口和资源。

内存限制也不只是设置一个 memory.max。比较完整的控制通常会同时观察：

1
memory.current     当前使用量
2
memory.high        进入回收与节流的压力线
3
memory.max         硬上限
4
memory.events      high、max、oom、oom_kill 计数
5
memory.oom.group   OOM 时是否按任务组整体处理

如果只让内核随机杀死进程树中的某个测试 Worker，父进程可能把它当作普通失败并持续重启，形成“被杀死又复活”的资源震荡。把 OOM 结果映射成任务级错误，并在必要时终止整个资源组，才符合 Agent Run 的语义。

同理，RLIMIT_NOFILE、RLIMIT_FSIZE 和文件系统 Quota 仍然有价值。cgroups 主要控制资源组，传统 rlimit 控制单进程或进程继承上限；二者叠加可以阻止 Agent 用大量文件描述符、超大单文件或无限日志绕过粗粒度 CPU、内存配额。

3.4 Capabilities 与 no_new_privs#

Linux 把传统 root 权限拆成多个 Capability，例如：

1
CAP_SYS_ADMIN
2
CAP_NET_ADMIN
3
CAP_SYS_PTRACE
4
CAP_SETUID
5
CAP_SETGID
6
CAP_DAC_OVERRIDE

其中 CAP_SYS_ADMIN 覆盖的能力极广，经常被称作“新的 root”。Agent 沙箱通常应从 Drop All Capabilities 开始，仅在确有必要时补回极少数能力。

no_new_privs 只保证调用线程及其随后创建的后代在后续 execve() 时，不能因为 setuid/setgid 位、文件 Capability 或 LSM 的执行转换获得新权限；现有的兄弟线程不会自动同步该属性，它也不代表进程的所有权限状态都会单调收紧。多线程 Runner 应在创建不可信线程前设置，或逐线程确保覆盖。它是阻断“执行新程序时提权”的关键棘轮，仍要与 Capability 删除、Namespace 和 LSM 等机制叠加。

3.5 Seccomp-BPF：缩小系统调用入口#

即使文件视图和身份已经隔离，进程仍然要调用宿主内核。Seccomp Filter 可以在系统调用入口根据 syscall 编号及参数返回 ALLOW、ERRNO、TRAP、KILL 或 USER_NOTIF 等结果。过滤器会被之后创建的 fork()、clone() 子进程以及 execve() 继承；要覆盖整棵进程树，必须在启动不可信线程和子进程前安装过滤器，或用 SECCOMP_FILTER_FLAG_TSYNC 同步到现有线程。⁶

Agent 沙箱通常会重点限制：

1
mount / umount
2
ptrace
3
bpf
4
keyctl
5
perf_event_open
6
init_module / finit_module
7
open_by_handle_at
8
reboot

但 Seccomp 不是完整权限系统。它很难直接表达“允许读取 /workspace，禁止读取 ~/.ssh”这种对象级规则。Seccomp 更像门卫，决定能不能使用某类内核入口；至于进入后能访问哪个具体文件，还要交给挂载权限、传统 DAC 和 LSM。

SECCOMP_RET_USER_NOTIF 还允许把某些系统调用暂停并转交给用户态监督进程，主要用于由更高权限监督器委托、模拟 syscall 或伪造返回值。它不能作为安全授权边界：SECCOMP_USER_NOTIF_FLAG_CONTINUE 存在不可消除的 TOCTOU，目标线程可能在等待期间改写指针参数；只有另一个内核安全机制仍会拦住危险参数时，监督器才应让原调用继续。把大量 syscall 都绕到用户态还会迅速放大性能与竞态复杂度。⁷

Seccomp Profile 还要考虑兼容性。编译器、JVM、浏览器和包管理器调用的内核接口差异很大，过窄会让正常工具随机报错，过宽又会把攻击面重新撑开。常见策略是从经过验证的基线 Profile 出发，只为明确的工具链补充调用，并把 mount、ptrace、内核模块、BPF 等高风险能力继续留在边界外。

3.6 LSM 与 Landlock：控制具体对象#

AppArmor、SELinux 和 Landlock 都属于 Linux Security Module 体系。它们可以在传统文件权限之外，再叠加一层强制访问控制。

Landlock 对本地 Agent 特别有价值，因为普通非特权线程可以主动限制自身及随后创建的后代，并且规则只能继续收紧。现有兄弟线程默认不会自动进入同一 Landlock Domain：ABI v8 及以上可使用 LANDLOCK_RESTRICT_SELF_TSYNC 同步，旧 ABI 上则应在创建其他线程前施加规则。非特权调用者通常需要先设置 no_new_privs；ABI v11 及以上也可用 LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS 把两步原子化。Landlock 可以限定允许读取或写入的目录，并与系统原有安全策略叠加。⁸

把这些机制放在一起，它们的分工非常清楚：

1
Namespace       隔离系统视图
2
cgroups         限制资源数量
3
Capabilities    拆分和移除特权
4
no_new_privs    阻止 execve 新增权限
5
Seccomp         缩小系统调用面
6
LSM             限制具体对象访问

强沙箱不是一堵厚墙，而是一组前后错位的闸门。某一层出现缝隙时，下一层仍有机会把动作挡住。

图 3：Linux 沙箱不是单一机制，而是由可见性、资源、特权、系统调用和对象访问五层控制共同组成。

3.7 文件系统：只读 RootFS、OverlayFS 与安全路径解析#

云端沙箱和容器环境常把基础系统层设为只读，再叠加每个任务独立的可写层：

1
LowerDir    基础镜像，只读
2
UpperDir    当前沙箱的修改
3
WorkDir     OverlayFS 内部工作目录
4
MergedDir   Agent 实际看到的视图

当 Agent 修改来自 LowerDir 的文件时，OverlayFS 会把对象 Copy Up 到 UpperDir，再在上层修改；删除下层文件时则通过 Whiteout 表达“在合并视图中不可见”。基础镜像仍保持原样，不同任务可以共享同一份只读层。⁹

OverlayFS 只提供写层和 Copy-on-Write 状态隔离，本身不是租户安全边界。每个沙箱应拥有独立的 UpperDir 与 WorkDir，并继续依赖身份、挂载、LSM 或虚拟化约束。

本地沙箱更常把用户项目目录以 Bind Mount 或平台 ACL 的方式映射进沙箱，同时让其他目录只读或不可见。

仅在应用层判断路径字符串是不够的：

1
if (path.startsWith("/workspace")) {
2
    allow();
3
}

../、符号链接、Magic Link 和 TOCTOU 都可能让“检查时安全”的路径在打开时指向边界之外。更可靠的做法是先打开工作区目录，再围绕目录文件描述符调用 openat2()：根据所需语义选择 RESOLVE_BENEATH 或 RESOLVE_IN_ROOT，并叠加 RESOLVE_NO_MAGICLINKS、RESOLVE_NO_SYMLINKS，必要时再加 RESOLVE_NO_XDEV。如果只能使用普通 openat()，则要逐级解析目录 FD 并配合 O_NOFOLLOW。Hard Link 属于同一 inode 的别名风险，需要通过挂载/文件系统权限、LSM 以及限制创建链接单独治理。¹⁰

文件描述符本身也是能力。父进程如果在进入沙箱前打开了敏感文件、目录或 Socket，再把 FD 继承给子进程，那么路径即使在 Mount Namespace 中不可见，子进程仍可能通过已有 FD 继续访问对象。因此 Command Runner 需要关闭非白名单 FD，或使用 close_range()、FD_CLOEXEC 等机制保证 execve() 后只留下标准输入输出和显式控制通道。

对 Coding Agent 而言，文件系统还承担结果边界。平台可以在任务前记录 Git 状态、OverlayFS UpperDir 或文件清单，任务后生成：

1
Created Files
2
Modified Files
3
Deleted Files
4
Mode Changes
5
Symlink Changes
6
Git Diff

这不是为了替代沙箱，而是让“沙箱内发生了什么”变成可审查输出。文件隔离负责限制动作，文件差异负责解释动作。

3.8 网络与凭证：两条必须分开的控制链#

只设置 HTTP_PROXY 并不等于断网。程序可以忽略环境变量，直接创建 Socket。真正的网络隔离应该发生在 Network Namespace、路由、防火墙或云网络策略层：

1
Sandbox Process
2
      ↓
3
Network Namespace
4
      ↓
5
Default Deny Firewall
6
      ↓
7
Egress Proxy
8
      ↓
9
Allowed Domain / API

代理可以做域名白名单、最终 IP 校验、HTTP 方法限制、重定向复检和流量审计。还要显式阻止回环地址、私有网段、宿主网关、云元数据服务、Kubernetes API 和其他沙箱网段。

凭证则应沿另一条链路处理。把真实 GitHub Token、AWS Key 或数据库密码放进环境变量，并不会让它们变安全；Agent 启动的第三方脚本可以通过环境变量或 /proc 读取它们。更稳妥的结构是：

1
Sandbox
2
  ↓ 语义操作请求
3
Credential Broker / MCP Gateway
4
  ↓ 身份、目标与操作校验
5
短期凭证或代理执行
6
  ↓
7
External Service

授权可以绑定到 sandbox_id、仓库、分支、操作、有效期和最大使用次数。这样，沙箱得到的是“向指定分支 Push 一次”的能力，而不是一把长期万能钥匙。

4.1 本地执行面应该如何分层#

一个较完整的本地 Agent 不应让 UI 进程或 Agent Harness 直接调用宿主 Shell，而应拆成几层：

1
CLI / IDE / Desktop UI
2
          ↓
3
Local Agent Harness
4
  规划、上下文、Tool Call
5
          ↓
6
Policy Broker
7
  判断路径、网络和审批规则
8
          ↓
9
Sandbox Launcher
10
  建立 OS 级边界
11
          ↓
12
Command Runner
13
  启动并管理受限进程树
14
          ↓
15
Git / Python / Maven / npm / Tests

Harness 可以继续以普通用户身份运行，因为它需要读取对话状态、渲染界面并调用模型。但模型生成的命令不能直接继承 Harness 的全部权限。Command Runner 是两者之间的“减压舱”：它把高层 Tool Call 翻译成一个从出生起就被限制的操作系统进程。

这种拆分还有一个安全收益。真正需要接触高权限配置的代码只集中在 Sandbox Launcher 或一次性 Setup Helper 中；日常推理循环、网络客户端和 UI 不必长期持有管理员权限。

本地客户端内部最好再把三类流量分开：

1
Model Traffic
2
  Harness 与模型服务之间的推理请求
3

4
Command Traffic
5
  Harness 向 Command Runner 发送 argv、cwd、timeout 和权限引用
6

7
Result Traffic
8
  Runner 返回 stdout、stderr、exit code、Diff 与审批事件

模型服务的网络连接不应因为“本地命令禁网”而中断，命令进程也不应复用 Harness 的认证连接绕过网络策略。换言之，本地 Agent 不是一个进程里既做推理又随手 exec()，而更像两个安全域通过窄协议连接：外侧负责思考和交互，内侧负责执行和承受风险。

Runner 接口也应传结构化参数，而不是拼接一整段 Shell 字符串。argv=["git","status"] 能减少二次解析和转义歧义；只有确实需要 Shell 语义时才显式启动 bash -lc、PowerShell 或 cmd.exe。这不会消除命令风险，但能让策略层准确识别可执行文件、参数和工作目录。

4.2 一个 Linux 本地命令是怎样被关进沙箱的#

在 Linux 上，命令启动顺序本身就是安全设计的一部分。典型流程可以拆成：

1
1. 创建 User Namespace
2
2. 写入 UID / GID 映射
3
3. 创建 Mount、PID、Network Namespace
4
4. 将挂载传播改为 private
5
5. 组装只读 RootFS 与可写 Workspace
6
6. 挂载独立 /proc、/tmp 和必要设备
7
7. 把进程加入专属 cgroup
8
8. 完成仍需特权的挂载与 LSM 准备
9
9. Drop 不再需要的 Capabilities
10
10. 按所用 LSM 语义安装或准备策略
11
11. 设置 no_new_privs，并应用 Landlock 等自限规则
12
12. 安装 Seccomp Filter
13
13. 清理环境变量和非白名单 FD
14
14. execve() 目标命令；如适用，在此完成 LSM Domain Transition

先后顺序不能随意颠倒。例如，挂载文件系统和写入部分 Namespace 映射可能需要在权限完全丢弃前完成；Landlock 通常要求先设置 no_new_privs，某些 AppArmor / SELinux 的 exec Domain Transition 又可能受 no_new_privs 影响。因此实现必须按实际 LSM 语义安排顺序，不能把“LSM、no_new_privs、Seccomp”硬编码为所有平台通用的一条固定链。无论采用哪种组合，沙箱边界都必须在目标程序第一条用户态指令运行之前闭合。

chroot() 可以改变进程看到的根目录，但它本身并不是完整安全边界。可靠实现还需要 Mount Namespace、User Namespace、权限删除和系统调用过滤共同参与。否则，一个仍拥有高权限的进程可能重新挂载文件系统或逃出目录视图。

图 4：安全边界必须在目标程序第一条用户态指令前闭合，并由子进程与孙进程继承；LSM 与 no_new_privs 的具体顺序取决于实现语义。

4.3 本地真实工作区怎样挂入沙箱#

本地 Agent 必须修改用户真实项目，常见做法是只把项目目录 Bind Mount 到沙箱内：

1
宿主：/home/user/projects/order-service
2
                    ↓ bind mount
3
沙箱：/workspace/order-service

沙箱内部可以形成这样的文件视图：

1
/
2
├── /usr                 read-only
3
├── /bin                 read-only
4
├── /etc                 read-only 或最小化版本
5
├── /tmp                 private tmpfs
6
├── /home/agent          临时 HOME
7
└── /workspace/project   writable

系统工具和 SDK 可以只读暴露，工作区允许读写，其余用户目录不挂载。对于无需执行的素材目录，还可以叠加 noexec；对不应出现设备节点的挂载使用 nodev；对不需要 setuid 语义的挂载使用 nosuid。

有些客户端希望在真正写入用户目录前提供“预览修改”或快速回滚，可以在真实工作区之上增加 OverlayFS：

1
真实项目或其快照      LowerDir
2
任务临时修改          UpperDir
3
Agent 看到的项目      MergedDir

Agent 先在 UpperDir 中修改，用户接受后再转换为 Patch 或应用到真实工作区。这样减少了模型直接污染当前目录的机会。不过，OverlayFS 解决的是写入落点，不会替代路径权限、网络隔离或进程限制。

4.4 工作区内部也需要二次分区#

“允许写项目目录”仍然过于粗糙。仓库中存在一些会影响未来执行行为的敏感位置：

1
.git/hooks
2
.git/config
3
.env
4
.npmrc
5
.pypirc
6
CI 配置
7
Agent 配置目录
8
Shell 启动脚本

例如，Agent 修改 .git/hooks/pre-commit 后，恶意命令可能在未来某次人工提交时才被触发。更细的本地文件策略可以表达：

1
src/、tests/              可读写
2
构建输出目录              可读写
3
.git/objects              只读或由 Git 代理管理
4
.git/hooks                禁止写入
5
用户级配置与凭证目录       不可见

对于 Agent 提供的文件 API，不能只检查字符串前缀。更安全的方式是预先打开工作区目录，后续围绕目录文件描述符调用 openat2()，根据语义选择 RESOLVE_BENEATH 或 RESOLVE_IN_ROOT，再叠加 RESOLVE_NO_SYMLINKS、RESOLVE_NO_MAGICLINKS 等解析约束。这样路径边界由内核在真正打开文件时验证，而不是在应用层先检查、稍后再使用。

4.5 本地执行身份如何从用户权限中做减法#

本地 Agent 通常从一个权限很大的真实用户会话出发。执行前需要构造更窄的身份：

1
Linux
2
  User Namespace + 非特权 UID 映射
3

4
macOS
5
  Seatbelt Profile 限制文件与网络能力
6

7
Windows
8
  专用 Sandbox User 或 Restricted Token
9
  + 文件 ACL
10
  + Firewall

关键不是让 Agent “换一个用户名”这么简单，而是确保文件访问检查、网络规则和子进程身份都绑定到这个受限主体上。命令再启动 python、git 或 node 时，后代进程不能自动回到用户原始 Token 或宿主完整 UID。

Windows 上还可以使用 Job Object 把一组相关进程纳入同一个生命周期和资源控制单元；Linux 则主要依赖 cgroup。Job Object 或 cgroup 负责“把进程树装进同一个笼子”，Restricted Token、Namespace 和 ACL 负责“笼子里的进程拥有什么权限”，两者职责不同。¹¹

4.6 环境变量与本地 Socket 也是权限通道#

即使文件挂载已经很干净，进程仍可能从父进程继承敏感能力：

1
SSH_AUTH_SOCK
2
GIT_ASKPASS
3
AWS_PROFILE
4
AWS_ACCESS_KEY_ID
5
KUBECONFIG
6
DOCKER_HOST
7
DOCKER_CONFIG
8
NPM_TOKEN
9
代理账号
10
数据库连接串

尤其是 SSH_AUTH_SOCK。进程不需要读取私钥文件，只要能够连接 SSH Agent 的 Unix Domain Socket，就可能请求其代为签名。Docker Socket 的风险更直接，把 /var/run/docker.sock 暴露给 Agent 通常接近于把宿主容器控制权交出去。

因此，Command Runner 应从白名单重新构造环境，而不是继承后再零散删除：

1
设置临时 HOME
2
重建 PATH
3
清除 Credential Helper 与 AskPass
4
不挂载 SSH Agent、Docker 和桌面会话 Socket
5
只注入任务需要的普通变量
6
将敏感操作交给外部 Broker

这一步经常被低估。文件路径和环境变量是两条独立的能力通道，堵住其中一条并不意味着另一条自动安全。

4.7 本地网络隔离必须覆盖公网、内网与本机服务#

用户电脑的网络面比“能否访问互联网”复杂得多。它可能同时连接：

1
公网
2
家庭或办公局域网
3
公司 VPN
4
localhost 服务
5
Docker Bridge
6
本地 Kubernetes
7
数据库与消息队列

Linux 可以为命令建立独立 Network Namespace，通过 veth 接入受控出口；macOS 可以用 Seatbelt 和系统网络策略；Windows 可以把 Firewall 规则绑定到专用 Sandbox User。无论平台如何实现，网络策略都应作用于整棵子进程树，而不是只禁止 Harness 的 HTTP 工具。

还要注意 localhost 的含义取决于隔离方式：

1
独立 Network Namespace：
2
127.0.0.1 指向沙箱自己的回环接口
3

4
共享宿主网络：
5
127.0.0.1 可能直接命中用户电脑上的数据库或调试服务

IP 防火墙也不会自动控制 Unix Domain Socket。对于 Docker、SSH Agent、桌面总线和本地代理等能力，必须从文件挂载和 Socket 权限层面单独阻断。

需要联网安装依赖时，较稳妥的做法是只给本次命令开放包仓库或 Git 目标，而不是临时放开整个公网。Approval 产生的应该是一项短期网络能力，而不是全局关闭沙箱。

网络“已开启”和“域名规则已强制执行”也应分开理解。允许进程联网，只代表路由层存在出口；要让 pypi.org=allow、其他域名拒绝这样的策略生效，还需要确保命令无法绕过代理直连。一个常见错误是配置了域名列表，却没有启动强制代理，此时策略文件看起来很精细，实际 Socket 仍可直接出网。

本地代理还应默认保护私有目标。域名最终解析到 127.0.0.1、RFC1918、VPN 网段或链路本地地址时，应再次校验；对于 Unix Socket，也要建立独立 Allowlist。因为 /var/run/docker.sock 并不是“一个文件”，而是一条能够命令宿主 Docker Daemon 的控制通道。

4.8 进程树、PTY、超时与强制回收#

一条表面简单的命令可能展开成很深的进程树：

1
bash
2
 └── mvn
3
      └── JVM
4
          ├── compiler
5
          └── test worker

或：

1
npm
2
 └── node
3
      └── child_process
4
          └── background server

所有后代必须继承相同的文件、网络、身份、Seccomp 和资源边界。任务取消时不能只终止父 Shell。Linux 上可以先发送 SIGTERM，等待 Grace Period，再使用 SIGKILL 和 cgroup.kill 清理整个 cgroup；Windows 可调用 TerminateJobObject() 终止整个 Job，也可设置 JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE，在最后一个 Job Handle 关闭时终止成员进程。安全实现还应禁止 Breakaway，并在目标进程开始执行前将其纳入 Job。

执行通道通常有两种：

1
普通 Exec
2
  适合编译、测试、脚本和批处理
3

4
PTY
5
  适合 Shell、REPL、调试器和需要 TTY 的 CLI

PTY 需要管理 master/slave、前台进程组、窗口尺寸和终端信号。它改善交互兼容性，但不会自动带来更强隔离，真正的安全边界仍由启动 PTY 内命令时使用的身份和 OS 策略决定。

4.9 Local 与 Worktree 解决的是不同问题#

本地 Agent 可以直接修改当前项目，也可以创建独立 Git Worktree：

1
Repository
2
  ├── 用户当前 Worktree
3
  └── Agent 独立 Worktree

Worktree 能隔离并发修改、分支和未提交文件冲突，却不能阻止进程读取用户主目录、访问 VPN 或创建大量子进程。因此：

Worktree 是代码状态隔离；OS Sandbox 是进程能力隔离。

Codex 当前也把 Local、Worktree 和 Cloud 作为不同环境模式，其中 Local 与 Worktree 都在用户设备上执行。²

4.10 本地命令的完整技术链路#

把前面的技术拼起来，一条本地测试命令会经过：

1
模型生成 Tool Call
2
        ↓
3
Harness 解析 argv、cwd 与所需能力
4
        ↓
5
Policy Broker 判断文件、网络与审批规则
6
        ↓
7
Launcher 构造 Namespace / Token / ACL / cgroup
8
        ↓
9
Command Runner 清理环境和本地 Socket
10
        ↓
11
execve / CreateProcess 启动受限命令
12
        ↓
13
所有后代继承同一边界
14
        ↓
15
stdout、stderr、exit code 流回 Harness
16
        ↓
17
超时或取消时回收整个进程树

stdout 与 stderr 应使用有界缓冲和分块事件。测试日志过快时，需要背压、截断或落盘；构建产物和二进制文件应走独立 Artifact 通道，不能塞进文本流中。

图 5：本地执行以真实工作区为目标，但文件身份、网络、进程树和结果回传仍分别经过约束与审计。

5.1 浏览器只属于控制平面#

典型结构是：

1
Browser / Web UI
2
        ↓ HTTPS
3
Task API / Session Service
4
        ↓
5
Cloud Agent Harness
6
        ↓ Control RPC
7
Sandbox Command Runner
8
        ↓
9
Shell / Git / Compiler / Tests

浏览器负责提交任务、显示事件、处理 Approval 和审查结果。Shell、编译器和测试程序位于远端执行平面。即使任务由桌面客户端发起，只要选择 Cloud 模式，它也不会自然继承本机文件、浏览器登录态或 VPN 权限。

控制平面和执行平面之间通常至少存在三类通道：

1
Command Channel
2
  下发 argv、cwd、环境引用和超时
3

4
Event Channel
5
  返回 stdout、stderr、状态和工具事件
6

7
Artifact Channel
8
  传输 Diff、报告和二进制制品

把三者分开，可以避免大文件阻塞命令控制，也能让文本事件流维持清晰的背压语义。

图 6：浏览器属于可重连控制平面，Shell、Git 和编译器运行在服务器端执行平面；图中上层箭头表示概念职责流，不要求所有实现严格串行。

5.2 云端 Sandbox 从什么状态启动#

一个任务环境通常不是从宿主根文件系统直接复制出来，而是由几个独立层拼成：

1
只读 Base Image 或 VM Snapshot
2
           +
3
任务独立 Writable Layer
4
           +
5
Repository Workspace
6
           +
7
Private /tmp
8
           +
9
按需只读 Cache

启动过程可以概括为：

1
1. 创建任务身份与资源组
2
2. 准备 RootFS 或恢复 VM Snapshot
3
3. 创建任务独立写层
4
4. 建立 PID、Mount、Network 边界
5
5. 挂载 Workspace 与必要 Cache
6
6. 启动沙箱内 Init / Guest Agent
7
7. 建立控制通道
8
8. Clone 仓库并 Checkout 指定版本
9
9. 进入 Setup Phase

云端 Workspace 应来自 Clone、上传或受控存储，而不是把宿主机某个真实目录直接作为可写 Volume 暴露给不可信任务。即使多个任务复用依赖缓存，缓存也更适合只读挂载，任务写入应落在自己的 Copy-on-Write 层。

从启动状态看，云端 Sandbox 通常存在三种来源：

1
Cold Image
2
  从基础镜像完整创建，状态最干净，启动最慢
3

4
Prepared Template
5
  已包含语言运行时和常用工具，但没有具体仓库数据
6

7
Cached / Snapshot State
8
  复用已安装依赖或已初始化运行时，再为当前任务切出私有写层

复用不能破坏隔离。缓存内容应可验证、可失效，并与用户 Secret、仓库工作区和任务身份分开。恢复一个缓存容器时，最危险的不是依赖版本旧，而是上一个任务的凭证文件、后台进程或可写缓存被悄悄带进来。因此“缓存命中”仍要经过工作区重置、身份重建、进程清空和权限重新应用。

5.3 RootFS、OverlayFS 与任务写层#

容器型沙箱常使用 OverlayFS：

1
LowerDir    只读镜像层
2
UpperDir    当前任务修改
3
WorkDir     OverlayFS 工作目录
4
MergedDir   Agent 看到的根文件系统

Agent 安装依赖或修改系统层文件时，变化进入 UpperDir，不会污染 Base Image。任务完成后，平台可以删除 UpperDir，或只从 Workspace 中导出 Git Diff 和 Artifact。

MicroVM 则可能使用 Copy-on-Write 块设备：基础磁盘镜像只读共享，每个任务拥有独立增量块。两种方案的共同原则是：

基础环境可以共享，任务写入必须私有。

/tmp、运行时缓存和进程 PID 文件也应属于任务自己的临时空间。否则，即使源码目录彼此隔离，任务仍可能通过共享临时目录互相观察或污染。

5.4 容器、gVisor 与 MicroVM 在执行面中如何工作#

云端 Sandbox 的运行时区别，核心在于不可信程序的系统调用最终落在哪里。

1
Agent Process
2
     ↓ syscall
3
Host Linux Kernel

1
Agent Process
2
     ↓ syscall
3
gVisor Sentry
4
     ↓ limited host syscall
5
Host Kernel

1
Agent Process
2
     ↓ syscall
3
Guest Linux Kernel
4
     ↓ virtio / VMM
5
KVM / Host Kernel

1
Container：Application → Host Kernel
2

3
gVisor：Application → User-space Kernel → Host Kernel
4

5
MicroVM：Application → Guest Kernel → VMM → Host Kernel

5.5 Harness 放在沙箱内还是沙箱外#

云端 Agent 常见两种结构。

1
Agent Harness
2
     ↓ RPC
3
Sandbox Runner
4
     ↓
5
Command Process

1
Sandbox
2
  ├── Agent Harness
3
  ├── Shell
4
  ├── Git
5
  └── Tests

5.6 Setup Phase 与 Agent Phase 怎样完成权限单向收缩#

云端环境往往需要联网下载依赖，但真正由模型生成的命令不应长期拥有同样权限。于是任务被拆成两个阶段。

1
运行预先配置的 Setup Script
2
访问允许的包仓库
3
使用安装所需的临时 Secret
4
构建依赖与缓存

1
撤销 Setup Secret
2
终止 Setup 进程树
3
清理环境变量与临时凭证文件
4
收紧 Egress Policy
5
Drop 额外 Capabilities
6
固定挂载边界
7
启动 Agent Runner

1
执行模型动态生成的命令
2
默认离线或仅访问白名单
3
只使用任务级短期能力
4
持续产生审计与事件流

5.7 云端网络是怎样被迫经过 Egress Proxy 的#

仅在容器内设置 HTTP_PROXY 仍然可以被绕过。可靠方案应从路由层保证 Sandbox 没有直接公网出口，只能连接受控代理：

1
Sandbox netns / VM NIC
2
          ↓
3
Default Deny Route / Firewall
4
          ↓ only allowed path
5
Egress Proxy
6
          ↓
7
DNS、目标 IP、域名与协议校验
8
          ↓
9
Internet

代理至少需要处理四次校验：

1
请求域名是否允许
2
DNS 最终 IP 是否属于禁止网段
3
TCP 实际连接目标是否与解析结果一致
4
HTTP 重定向后的新目标是否仍然允许

默认禁止的目标通常包括：

1
127.0.0.0/8
2
RFC1918 私网
3
宿主网关
4
云元数据服务
5
Kubernetes API
6
控制面服务
7
其他任务网段
8
内部数据库和消息队列

若代理只允许 HTTPS CONNECT 而不终止 TLS，它通常只能验证连接目标，无法可靠检查加密后的 HTTP 方法与路径。要实施细粒度 HTTP 方法限制，需要由应用层代理终止 TLS，或让任务使用平台提供的受控 HTTP 工具。网络策略能够看见什么，取决于代理位于协议栈的哪一层。

Codex Cloud 当前在 Agent 阶段默认关闭互联网；开启后可以限制域名和 HTTP 方法，外部 HTTP/HTTPS 流量通过受控代理。^{16 14}

5.8 任务身份与 Credential Broker#

云端平台可能拥有 Git、包仓库、对象存储和企业系统的长期身份，但这些身份不能复制进任务环境。更合理的链路是：

1
Sandbox 发出语义操作请求
2
          ↓
3
Credential Broker / Git Proxy / MCP Gateway
4
          ↓
5
校验 user_id、task_id、sandbox_id
6
          ↓
7
校验 repository、branch、operation
8
          ↓
9
签发短期 Token 或在代理外部完成操作

能力可以被压缩到：

1
主体：sandbox-123
2
资源：org/order-service
3
分支：agent/fix-timeout
4
操作：push
5
有效期：60 秒
6
最大次数：1

如果采用代理执行，真实凭证从头到尾都不会进入沙箱；如果必须签发 Token，也应尽量缩短有效期、Scope 和使用次数。任务结束或沙箱身份变化时，Broker 必须立即撤销关联能力。

5.9 云端 Command Runner 与事件流#

Command Runner 通常通过 gRPC、Unix Socket 或 VM vsock 接收执行请求：

1
{
2
  "argv": ["mvn", "test"],
3
  "cwd": "/workspace/order-service",
4
  "timeoutSeconds": 300,
5
  "envRefs": ["JAVA_HOME"],
6
  "networkCapability": "maven-central-only"
7
}

Runner 在沙箱内创建进程组，捕获 stdout、stderr 和 exit code，并把执行状态转换成事件：

1
command.accepted
2
command.started
3
stdout.delta
4
stderr.delta
5
process.spawned
6
command.completed
7
command.killed

事件通道必须有背压。若浏览器或任务服务消费速度下降，Runner 不能无限占用内存。可采用有界 Ring Buffer、批量发送、日志截断和落盘；断线恢复时从持久化事件偏移继续读取。大体积测试报告和二进制构建产物进入 Artifact Store，事件流只携带引用。

为了支持 Web 页面刷新、移动端接管和长任务继续运行，事件不能只依赖一条活着的 WebSocket。更稳妥的语义是：Runner 把事件提交到任务级日志，Gateway 再按 task_id + sequence 向不同客户端投递。浏览器掉线只丢失实时连接，不会中断沙箱，也不会改变命令执行事实。

1
Sandbox Runner
2
   ↓ append
3
Durable Task Event Log
4
   ↓ subscribe from sequence N
5
SSE / WebSocket Gateway
6
   ↓
7
Desktop / Web / Mobile

控制命令也要幂等。例如用户连续点击两次“停止”，控制面可以携带同一个 request_id；Runner 只执行一次终止，并返回同一最终状态，避免重复清理和状态机乱跳。

5.10 任务结束时怎样真正清空环境#

云端沙箱的可销毁性来自明确的资源边界。任务结束时应按顺序执行：

1
停止接受新命令
2
撤销任务 Credential
3
终止完整进程树或销毁 VM
4
关闭控制与网络通道
5
导出 Diff、日志和 Artifact
6
卸载 Workspace 与临时挂载
7
删除任务 UpperDir 或增量磁盘
8
释放任务身份与网络地址

只删除工作目录并不够。后台进程、挂载点、网络连接和短期身份都可能继续存活。容器环境应清理整个 cgroup 与 Namespace；MicroVM 环境可以直接销毁 Guest，将进程和内核状态一起抹去。

平台若要保存状态，也应显式区分：

1
Agent Checkpoint
2
  messages、tool calls、plan、observation
3

4
Sandbox Snapshot
5
  filesystem、memory、process、runtime state

逻辑状态和操作系统状态不是同一回事，不能只保存对话 Checkpoint 就假设编译环境能够原地恢复。

5.11 Web 云端任务的完整技术链路#

1
用户在 Web 页面提交任务
2
        ↓
3
Task Service 创建任务身份
4
        ↓
5
准备容器 RootFS 或恢复 MicroVM Snapshot
6
        ↓
7
建立文件、cgroup、网络和内核边界
8
        ↓
9
Clone 仓库并挂载任务写层
10
        ↓
11
Setup Phase 安装依赖
12
        ↓
13
撤销 Setup Secret 并收紧网络
14
        ↓
15
启动 Agent Harness / Sandbox Runner
16
        ↓
17
执行修改、编译和测试
18
        ↓
19
事件经 SSE / WebSocket 返回页面
20
        ↓
21
Diff、报告和制品进入 Artifact 通道
22
        ↓
23
撤销身份与 Secret，回收环境或按隔离策略缓存 / 快照

Web 页面只是远程观察窗。真正的云端沙箱，是一套围绕任务身份重新组装出来的临时操作系统边界。

图 9：云端任务在受控网络、临时身份和独立工作区内完成；结果被导出后，环境按策略销毁或进入受限缓存。

6.1 Codex Local：上层策略如何映射到不同操作系统#

Codex Local 的核心不是“在本地直接跑命令”，而是把用户已有的一大团权限拆成多个互不等价的能力面。ChatGPT 桌面端可能同时拥有以下工具：

1
Local Shell / Code Tool
2
  运行 Git、Python、npm、Maven 和测试进程
3

4
Built-in Browser / Browser Extension
5
  读取网页、现有标签页或单独浏览器 Profile
6

7
Computer Use
8
  截图、点击、输入和操作桌面应用
9

10
Connected Apps / Plugins / MCP
11
  通过各自的身份和传输访问外部系统

这些能力并不共享一个万能沙箱。OpenAI 的本地安全说明明确把文件访问、Computer Use、浏览器和连接应用视为不同权限与审批面；Codex 的公开 Agent Loop 也指出，Codex 提供的 Sandbox 描述只约束内置 Shell Tool，MCP Server 需要为自己的执行和数据访问承担独立 Guardrail。^{18 20}

这意味着，设计 Agent 安全时不能说“Shell 已经被沙箱，所以整个 ChatGPT 桌面端都安全了”。更准确的结构是：

1
ChatGPT Desktop Agent
2
        │
3
        ├── Shell Sandbox Policy
4
        ├── Browser Profile / Site Approval
5
        ├── Computer Use OS Permission
6
        ├── Connector Account Scope
7
        └── MCP Server Guardrail

每条工具通道都拥有自己的身份、数据源和越权方式。

第一层：Local、Worktree 与 Cloud 是执行位置，不是聊天界面。

在 ChatGPT 桌面应用中选择 Codex 后，Local 直接工作于当前项目目录，Worktree 在本机创建独立 Git Worktree，Cloud 则运行在远端环境。Local 与 Worktree 都在用户电脑上执行。^{2 21}

1
Local
2
  当前真实工作区 + OS Sandbox
3

4
Worktree
5
  独立 Git 工作树 + OS Sandbox
6

7
Cloud
8
  远端工作副本 + Cloud Sandbox

Worktree 只隔离 Git 修改，不隔离操作系统权限。它可以避免两个 Agent 同时改坏同一 Checkout，却不能阻止命令读取 ~/.ssh、连接公司 VPN 或访问 Docker Socket。因此 Worktree 和 OS Sandbox 必须叠加，而不能互相替代。

第二层：Permission Profile 把文件与网络规则编译成一次本地执行边界。

Codex 当前提供 :read-only、:workspace 和 :danger-full-access 等内置权限 Profile，也允许自定义文件路径和网络目标。:workspace 的语义是允许在活动 Workspace Root 和系统临时目录中写入，而不是自动授予整个用户目录。自定义 Profile 还可以在可写工作区内部继续拒绝读取 .env 等敏感文件。²²

1
[features]
2
network_proxy = true
3

4
[permissions.project-edit.filesystem.":workspace_roots"]
5
"." = "write"
6
"**/*.env" = "deny"
7

8
[permissions.project-edit.network]
9
enabled = true
10

11
[permissions.project-edit.network.domains]
12
"pypi.org" = "allow"
13
"*.pythonhosted.org" = "allow"

这里有一个非常关键的双开关：

1
network.enabled = true
2
  只表示命令允许联网
3

4
features.network_proxy = true
5
  才让域名 Allowlist 通过代理被强制执行

如果网络开启但代理未启用，命令可能获得直接且不受域名列表约束的网络连接。反过来，当代理真正生效时，本地和私有网络目标默认会受到额外保护，用来抵御 DNS Rebinding 和意外访问 localhost、VPN 网段或内网服务。Unix Socket 又是另一条独立路径，需要单独配置。²²

第三层：模型知道权限，但真正强制权限的是操作系统。

Codex 在构造 Agent 输入时，会注入一段描述 Sandbox、网络、可写目录和审批时机的 Developer Message，让模型提前知道边界，从而减少无意义的越权尝试。²⁰

1
Model Prompt
2
  “当前只允许写 Workspace，网络关闭”
3
        ↓
4
模型尽量生成边界内命令
5
        ↓
6
Policy / Approval 再判断请求
7
        ↓
8
OS Sandbox 最终强制执行

这是一种“认知约束 + 技术约束”的双层设计。Prompt 让模型更聪明地使用权限，但 Prompt Injection 可能影响模型判断，所以安全性不能依赖模型是否听话。Seatbelt、Bubblewrap、Seccomp、ACL 与 Firewall 才是最后的硬门。

第四层：同一个上层 Profile 映射为不同平台原语。

当前跨平台路径可以概括为：

1
macOS
2
  Seatbelt Profile + sandbox-exec
3

4
Linux / WSL2
5
  Bubblewrap + User / Mount / PID Namespace + Seccomp
6
  兼容路径可使用 Landlock
7

8
Native Windows
9
  elevated：Sandbox User + Restricted Token + ACL + Firewall
10
  unelevated：当前用户派生的 Restricted Token + ACL + 环境级离线控制

在 macOS 上，Codex 根据选择的权限模式生成 Seatbelt Profile；如果所选策略无法被平台沙箱可靠执行，当前文档描述的原则是拒绝运行，而不是静默降级成无沙箱命令。在 Linux 与 WSL2 上，bwrap 负责重新组装文件和进程视图，Seccomp 缩小 syscall 面，User Namespace 提供非特权身份边界。Windows 的 elevated 模式使用专用低权限用户和用户级 Firewall，unelevated 模式则从当前用户派生 Restricted Token，并以环境级离线控制替代专用 Offline User 的防火墙规则，隔离强度更弱。^{1 22 15 23}

第五层：浏览器与 Computer Use 不是 Shell Sandbox 的附属功能。

ChatGPT Work Local 的内置浏览器使用与用户常规浏览器分开的 Profile；Chrome 扩展在获批后可以接触现有标签页和登录状态；Computer Use 则依赖操作系统的屏幕录制、辅助功能和应用审批。在 macOS 上，屏幕可见性和点击能力分别依赖 Screen Recording 与 Accessibility 权限；在 Windows 上，Computer Use 操作的是当前可见桌面。¹⁸

因此，一次本地任务可能同时跨过几道边界：

1
读取项目文件       → Shell / Filesystem Policy
2
运行测试           → OS Sandbox + Process Tree
3
打开内网页面       → Browser Approval + Existing Account
4
点击桌面应用       → Computer Use + OS Permission
5
调用 CRM Connector → Connected Account Scope
6
调用 MCP Tool      → MCP Server 自身 Guardrail

这也是 ChatGPT 本地端比传统“命令行沙箱”更复杂的原因。它不是只有一只被关在笼子里的 Shell，而是一组各自带锁的工具舱。

一条完整的 ChatGPT / Codex Local 执行链可以写成：

1
用户在 ChatGPT Desktop 选择 Local 或 Worktree
2
        ↓
3
桌面端确定 Workspace Root 与可用工具
4
        ↓
5
Permission Profile 编译文件、网络和拒绝规则
6
        ↓
7
Sandbox 描述进入 Agent Context
8
        ↓
9
模型生成 Shell Tool Call
10
        ↓
11
Policy 判断 Allow / Deny / Ask
12
        ↓
13
平台 Command Runner 创建 OS Sandbox
14
        ↓
15
Git / Python / npm / Tests 在受限进程树中运行
16
        ↓
17
stdout、stderr、Diff 与审批事件返回桌面端
18
        ↓
19
本地文件保留，必要上下文发送给云端模型继续推理

图 10：同一组上层权限语义会映射为不同操作系统原语。Windows 栏是概念性原语合集：Sandbox User 与用户级 Firewall 仅属于 elevated 模式；unelevated 使用当前用户派生的 Restricted Token、ACL 与较弱的环境级离线控制。图中的 Job Object 是 Windows 通用的可选进程树原语，并非当前公开资料已确认的 Codex 组件。

6.2 Codex Windows：为什么需要多层原语拼成一个沙箱#

Windows 案例最有技术价值，因为它展示了：当操作系统没有一个与 Linux Namespace 或 macOS Seatbelt 完全同构的“开放式 Agent Sandbox”时，如何把身份、文件 ACL、Restricted Token、Firewall 和多个专用进程拼成一条可用边界。^{23 24}

以下重点讨论官方 Windows 文档中的 Elevated 主路径；当前也存在不需要管理员初始化、但隔离更弱的 Unelevated Fallback，两者不能视为同一安全强度。

OpenAI 需要满足的不是“运行一款固定应用”，而是允许 Agent 动态驱动：

1
PowerShell
2
Git
3
Python
4
Node.js
5
包管理器
6
编译器
7
任意项目测试程序

这些工具的系统调用和文件需求无法在安装时完全枚举，因此很多经典 Windows 隔离方案都不合身。

为什么没有直接使用 AppContainer、Windows Sandbox 或低完整性级别。

AppContainer 的 Capability 模型适合提前知道资源需求的窄应用，但 Coding Agent 会动态调用大量传统 Win32 程序，能力面过于开放且变化频繁。Windows Sandbox 提供更强的轻量 VM 隔离，却位于独立、可销毁的桌面中，不适合直接操作用户真实 Checkout、现有工具和开发环境，而且并非所有 Windows 版本都可用。Mandatory Integrity Control 可以让低完整性进程无法写中完整性对象，但把真实工作区标记为低完整性会改变该目录对整台主机的信任语义，影响范围不只限于 Codex。²⁴

于是工程问题被拆成两个更具体的目标：

1
文件目标：命令可以读到开发环境，但只能写显式 Workspace
2
网络目标：Offline 命令及其所有后代都不能直接出站

1
检查一：Sandbox User Token 的正常 SID 是否允许写入
2
检查二：Restricted SID 列表中是否也有主体被允许写入
3
                         ↓
4
                    两次都通过
5
                         ↓
6
                       写成功

1
HTTPS_PROXY=http://127.0.0.1:9
2
ALL_PROXY=http://127.0.0.1:9
3
GIT_HTTPS_PROXY=http://127.0.0.1:9
4
GIT_SSH_COMMAND=cmd /c exit 1
5
PATH 前置 denybin

1
CodexSandboxOffline
2
  被用户级 Firewall 规则阻止全部出站连接
3

4
CodexSandboxOnline
5
  不受 Offline Firewall 规则约束

1
创建 sandbox-write Synthetic SID
2
创建 Online / Offline Sandbox User
3
使用 DPAPI 加密并保存用户凭证
4
保证 Sandbox User 无法读取自身保存的凭证
5
创建并校验 Offline 用户的出站 Firewall 规则
6
向必要系统目录和用户目录补充只读 ACL

1
codex.exe
2
  → LogonUserW(sandbox user)
3
  → CreateRestrictedToken(...)
4
  → CreateProcessAsUserW(child)

1
codex.exe（真实用户、非提权）
2
        ↓ CreateProcessWithLogonW
3
codex-command-runner.exe（Sandbox User）
4
        ↓ OpenProcessToken
5
        ↓ GetTokenInformation，取得 Sandbox Logon SID
6
        ↓ CreateRestrictedToken
7
        ↓ CreateProcessAsUserW
8
Child Process（Sandbox User + Write-restricted Token）

1
codex.exe
2
  负责 Harness、对话与策略
3

4
codex-windows-sandbox-setup.exe
5
  负责 UAC 后的用户、ACL、DPAPI 与 Firewall 初始化
6

7
codex-command-runner.exe
8
  负责在 Sandbox User 一侧铸造受限 Token
9

10
Child Process
11
  真正运行 PowerShell、Git、Python 和测试

6.3 Work Cloud 与 Codex Cloud：并列的托管执行路径#

在用户视角下，ChatGPT Work Cloud 可以从 Web、移动端或桌面端发起，并在用户离开当前界面后继续执行；但任务始终运行在 OpenAI 管理基础设施上，不会因为用户从桌面应用打开它就获得本地文件、已安装应用、浏览器会话或私有网络权限。^{17 19 25}

公开资料需要把两条路径并列区分：ChatGPT Work Cloud 当前运行在 VM-backed Sandbox 中，可以跨任务复用或替换环境并保留符合条件的状态；Codex Cloud 编码聊天则会创建或恢复隔离 Container，组织仓库、Setup 和 Agent Phase。两者共享核心 Harness 与部分隔离机制，但工具、权限和管理控制并不完全相同；公开资料没有说明 Codex Container 嵌套在 Work Cloud VM 内。并非所有 Work Cloud 任务都绑定 Git 仓库，也不都遵循 Codex Cloud 的容器生命周期。^{19 14}

从架构上看，这意味着 Cloud Task 的生命周期必须归属于服务端任务身份，而不是归属于某条浏览器连接：

1
Browser / Desktop / Mobile
2
       ↓ submit / subscribe
3
Cloud Task Service
4
       ↓ owns lifecycle
5
Isolated Execution Environment

这是根据“任务可跨端同步并在用户离开后继续”的产品行为作出的架构推断：客户端是可重连控制器，Sandbox 才是持续运行的执行实体。

第一层：Work Cloud 与本地设备之间存在天然断点。

云任务不会自动继承：

1
本地文件与未上传修改
2
桌面应用
3
本地浏览器 Profile、标签页和登录态
4
密码管理器与浏览历史
5
公司 VPN 与私有网络路由
6
本地 SSH Agent、Docker Socket 和环境变量

需要使用的数据必须通过上传、Project、Library、连接应用或受控仓库进入云端。连接应用使用的是已授权账号的权限，它提供一条服务侧访问路径，但不会把整台设备或 VPN 网络挂进 Sandbox。¹⁹

第二层：Cloud Browser、Web Search、Connector 与 Shell Network 是四套不同通道。

ChatGPT Work Cloud 中，Hosted Browser 不继承用户本地浏览器的 Cookie、标签页、密码和历史；如需登录，使用单独的托管登录流程。更重要的是，关闭 Code/Shell 的公网访问，并不会自动关闭 Cloud Browser、Web Search 或 Connected Apps。它们各自有独立权限与网络面。¹⁹

1
Cloud Browser
2
  托管浏览器 Profile + 网站审批
3

4
Web Search
5
  托管搜索服务与结果策略
6

7
Connected Apps
8
  服务侧连接 + 授权账号 Scope
9

10
Work Cloud Code / Shell Network
11
  独立网络策略 + Managed Destination Allowlist

这和本地端的多工具边界形成呼应：一个 Agent 可以同时拥有多条“看起来都能访问互联网”的通道，但每条通道的身份、协议和审计点不同。只关掉其中一条，不等于 Agent 完全离线。

第三层：Codex Cloud 环境从容器、仓库和 Setup 开始。

下面的流程特指 Codex Cloud 编码任务，而不是所有 Work Cloud 任务：

官方公开流程是：

1
1. 创建隔离 Container
2
2. Checkout 选定 Repository、Branch 或 Commit SHA
3
3. 执行 Setup Script
4
4. 缓存恢复时可执行 Maintenance Script
5
5. 应用 Agent Internet Access 设置
6
6. Agent 循环运行终端命令、编辑代码和校验结果
7
7. 返回最终回答与文件 Diff

默认 universal 镜像预装常用语言、包和工具，环境还可以固定 Python、Node.js 等版本。¹⁴

Cloud Environment 中的普通 Environment Variable 和 Secret 有不同生命周期：

1
Environment Variable
2
  Setup 与 Agent Phase 都可用
3

4
Secret
5
  仅在任务执行时解密
6
  只提供给 Setup Script
7
  Agent Phase 开始前移除

Setup Script 在独立 Bash Session 中运行，因此普通 export 不会自动持久化到 Agent Phase。这个细节防止 Setup Shell 变成一条隐蔽的父进程继承链；确实需要长期存在的非敏感变量，应通过环境配置显式声明。¹⁴

第四层：权限在 Setup 与 Agent 之间单向收缩。

1
Setup Phase
2
  可联网安装依赖
3
  可使用 Setup Secret
4
  执行预配置脚本
5
        ↓
6
Security Handoff
7
  删除 Secret
8
  结束 Setup Shell
9
  应用 Agent 网络策略
10
        ↓
11
Agent Phase
12
  运行模型动态命令
13
  默认关闭公网
14
  必要时只开放受控目标

Agent 阶段默认无互联网；开启后，可以使用域名 Allowlist 和 HTTP Method 限制。官方文档还允许把请求收紧为 GET、HEAD、OPTIONS，阻止 POST、PUT、PATCH、DELETE 等更容易产生外部副作用或数据外传的方法。所有外部 HTTP/HTTPS 流量经过平台代理。^{16 14}

HTTP Method 限制并不是万能 DLP。敏感数据仍可能被编码进 URL Query、请求头或允许的下载协议中，但它能明显缩小“把仓库内容直接 POST 到外部站点”的通道。真正的保护仍来自默认断网、窄域名列表、无长期 Secret 和结果审查的组合。

第五层：容器缓存加速启动，但任务写入与身份必须重新切开。

Codex Cloud 会缓存容器状态以加快新任务和后续对话。当前公开文档说明，缓存可保留至多 12 小时；首次缓存时 Clone 默认分支并运行 Setup，恢复时 Checkout 当前任务分支并可执行 Maintenance Script。Setup、Maintenance、环境变量或 Secret 发生变化时，缓存会失效。¹⁴

缓存的是“准备好的环境状态”，不是“把上一个任务继续交给下一个用户”。以下是从安全语义推导出的参考设计要求，并非 OpenAI 对内部恢复流程的逐项披露：

1
重新绑定当前 Repository / Branch
2
重新建立 Task Identity
3
确认旧进程已经清空
4
重新应用 Network Policy
5
重新注入当前环境变量
6
不恢复上一个任务的 Secret
7
创建当前任务自己的工作写层

对于 Business 与 Enterprise 环境，某些缓存可以被同一环境的授权用户共享，这更要求缓存内容不包含个人 Token、任务私有文件或后台进程。¹⁴

第六层：云端状态不等于聊天记录。

ChatGPT Work Cloud 的 Conversation、Hosted Execution State、Snapshot、Library File 和 Connected App 内容具有不同存储与生命周期。技术上，这说明一个长任务至少存在两类状态：

1
Agent Logical State
2
  messages、tool calls、plan、approval、event sequence
3

4
Hosted Execution State
5
  sandbox filesystem、runtime state、snapshot、artifact

删除或结束聊天，不应被简单理解为所有执行快照和文件立刻同时消失；相反，执行平台需要通过明确的资源引用和回收策略关联这些对象。¹⁹

基于公开产品行为，可以推导出一条 Codex Cloud 编码任务的参考执行链：

1
用户从 Web、Desktop 或 Mobile 提交 Cloud Task
2
        ↓
3
服务端校验 Workspace 权限并绑定临时任务身份
4
        ↓
5
创建隔离 Container 或恢复安全缓存
6
        ↓
7
Checkout 指定 Repository 与 Commit
8
        ↓
9
Setup Script 联网安装依赖并使用 Setup Secret
10
        ↓
11
结束 Setup Session，移除 Secret
12
        ↓
13
应用 Agent Phase 的 Egress Policy
14
        ↓
15
Codex Harness 循环生成与执行终端命令
16
        ↓
17
Shell 状态和输出进入服务端任务事件通道（架构推断）
18
        ↓
19
Web / Desktop / Mobile 从事件序列订阅进度
20
        ↓
21
输出回答、Diff、Commit、PR 或 Artifact
22
        ↓
23
保留显式结果，回收或缓存执行环境

6.4 同一个任务在 Codex Local 与 Cloud 中如何执行#

假设用户在 ChatGPT 中提出：

修复订单查询接口的超时问题，运行完整测试，并给出一份可以审查的修改。

这条自然语言目标不决定任务在哪里运行。真正决定安全边界的是用户选择 Local、Worktree 还是 Cloud，以及任务获准使用哪些工具。

在 Local 中，任务从用户已有状态出发。

1
ChatGPT Desktop 打开本地 order-service
2
        ↓
3
Codex 读取当前 Checkout 和未提交修改
4
        ↓
5
Permission Profile 允许写 Workspace，默认禁网
6
        ↓
7
OS Sandbox 启动 ripgrep、Maven、JVM 和测试 Worker
8
        ↓
9
若 Maven 缓存不足，请求访问指定依赖域名
10
        ↓
11
用户批准一次受限网络能力
12
        ↓
13
修改直接落在 Local Workspace 或 Agent Worktree
14
        ↓
15
IDE 立即看到 Diff，用户继续手工调试

本地模式的上下文最丰富，因为它能看到未提交代码、现有构建缓存和本机服务；同时风险也最贴近用户设备。Permission Profile、环境清理、网络代理和 OS Sandbox 必须共同阻止任务顺手读取 SSH Key、访问 VPN 内网或控制 Docker Daemon。

在 Cloud 中，任务从显式提供的上下文重新构造环境。

1
用户提交 Cloud Task 并选择仓库与分支
2
        ↓
3
服务端创建独立 Container 和任务身份
4
        ↓
5
Checkout 远端仓库，不包含本机未提交修改
6
        ↓
7
Setup 使用 Secret 拉取私有依赖
8
        ↓
9
Secret 被移除，Agent 网络默认关闭
10
        ↓
11
Codex 修改代码、运行测试并生成 Diff
12
        ↓
13
事件持续返回 Web / Desktop / Mobile
14
        ↓
15
用户审查结果并选择创建 PR

云端模式天然无法看见用户电脑上的临时文件、浏览器登录态和本地数据库，除非用户通过上传、连接工具或网络配置显式提供能力。它的环境更可复制，也更容易在用户离开设备后继续运行。

双端切换最容易产生的错误假设，是把 UI 位置当成执行位置。

1
在桌面应用里查看 Cloud Task
2
  不代表 Cloud Task 已迁移到本机
3

4
在移动端继续 Cloud Task
5
  不代表命令在手机上执行
6

7
在 Web 页面提交任务
8
  不代表代码运行在浏览器 JavaScript Sandbox

真正应该追踪的是：

1
execution_location
2
workspace_source
3
command_identity
4
network_policy
5
credential_source

只要这五个值清楚，用户从哪个屏幕观察任务就只是控制面的变化。

图 12：Local/Worktree 在本地受限边界内修改真实工作区；Cloud 在远端隔离环境中执行并返回 Diff、PR 或 Artifact。浏览器本身不承载 Shell。

6.5 从 Codex 案例提炼的技术原则#

从 ChatGPT Work 与 Codex 的双端实现中，可以提炼出十条更完整的技术原则：

1. 执行位置是安全模型的一部分。 同一个聊天界面可以承载本地和云端任务，不能根据 UI 判断命令在哪里运行。
2. 本地执行不等于本地推理。 文件和命令可以留在设备上执行，但模型推理仍可能使用云服务，必要上下文需要跨边界传输。
3. Sandbox 描述不等于 Sandbox 强制。 Prompt 中的权限说明用于约束模型行为，最终文件和网络边界必须由操作系统执行。
4. 一个 Agent 拥有多条工具通道。 Shell、Browser、Computer Use、Connector 和 MCP 必须分别建模，关闭 Shell 网络不等于其他通道离线。
5. Worktree 不是安全沙箱。 它隔离 Git 修改并支持并行工作，但仍需叠加 OS Sandbox 才能限制文件、网络和进程能力。
6. 本地端以权限做减法。 从真实用户身份、文件、Socket、浏览器和 VPN 能力中，只保留当前任务需要的最小集合。
7. 云端以权限做加法。 从空白任务身份开始，显式加入仓库、工具、网络、连接应用和短期凭证。
8. 进程树需要稳定可识别的身份。 Windows 的专用 Sandbox User、Linux 的 cgroup/Namespace，都是为了让限制覆盖 Git、Python、Node 等任意后代进程。
9. 环境准备与动态 Agent 执行必须分阶段。 Setup 可以拥有安装依赖所需的网络和 Secret，Agent 接管前要单向撤销这些能力。
10. 客户端连接与任务生命周期必须解耦。 云任务可跨 Web、Desktop 和 Mobile 继续，说明实时连接只是订阅通道，任务事实和执行状态必须保存在服务端。

Codex 案例最重要的价值，不是证明某个产品使用了哪一种沙箱，而是展示了一套统一语义怎样落到两种完全不同的世界：本地端围绕真实设备构造最小权限，云端围绕临时任务构造最小能力。两边的砖块不同，但砌的是同一堵墙。