沙箱与网络

agentrun 用沙箱限制 agent 能写的文件、能读的敏感文件和命令能访问的主机，用运行时参数限制它能读到的配置与账号。本页写 --sandbox、--network 与 --deny-read 三组选项、各运行时分别怎么关进沙箱，以及每种组合剩下的风险。

代码位置

过滤代理在 agentrun 进程里的独立线程上运行，每个连接一个处理线程，建立转发后再加一个复制下行数据的线程，线程数没有上限；Policy 只做放行判断，不知道连接来自哪个运行时。理由：所有运行时共用同一份判定规则与同一种 network 事件。普通 HTTP 请求的转发、CONNECT 与 SOCKS5 的隧道都设了空闲时限：客户端关闭发送方向以后，上游从最后一次发来数据起 30 秒（proxy.rs 的 UPSTREAM_IDLE_TIMEOUT）内没有再发来数据，复制下行数据的线程就结束，所以上游一直不回复也不关闭时，处理线程与复制线程不会留到 agentrun 退出。客户端没有关闭时，上游停顿多久都不中断转发。

沙箱模式

沙箱由操作系统决定：macOS 用 Seatbelt，Linux 用 bubblewrap（bwrap）；codex 在两个系统上都用它自己的沙箱，它在 Linux 上也是用 bwrap 实现的。--sandbox（环境变量 AGENTRUN_SANDBOX，选项优先）决定沙箱做不到时怎么办。

默认 on 的理由：本机 Linux 没装 bwrap 时，agent 不会在没有隔离的情况下运行而无人察觉；docker 里的结果也不会取决于镜像碰巧装了什么。名字用 on 与 relax，是有意鼓励调用方使用 on。off 给明确知道自己在容器里的启动方用。

沙箱与网络共用这一个选项，因为网络限制本身靠沙箱执行：沙箱没有运行，网络限制也一定落空。分成两个选项会出现「沙箱放宽、网络严格」这类说不清的组合。

判断沙箱能不能用

只看 bwrap 是否存在不够：docker 容器、关闭了非特权用户命名空间的系统、被 AppArmor 限制的系统里，bwrap 装了也启动不了。所以 on 与 relax 在每次运行前都实际检查一次：

• macOS：执行一次 /usr/bin/sandbox-exec -p '(version 1)(allow default)' /usr/bin/true，最多等 5 秒。与 Linux 一样按能否实际启动判断，本机耗时约 25 毫秒。sandbox-exec 只用 /usr/bin/sandbox-exec 这个绝对路径，不在会话 PATH 里查找，因为 Seatbelt 是系统组件，PATH 里同名的程序不是它。macOS 上不查找 socat：claude-code 在 macOS 上不用它，pi 与 dsh 直接连接过滤代理的端口。
• Linux：会话 PATH 里有 bwrap；claude-code、pi 与 dsh 还要有 socat。然后执行一次 bwrap --ro-bind / / --dev /dev --proc /proc --die-with-parent --unshare-net -- /bin/true，最多等 5 秒。耗时通常是毫秒级。检查创建的命名空间与 pi 和 dsh 的包裹相同，网络命名空间也在检查之内。
• Linux 上的 codex 同样执行这条检查，不要求 socat。查找 bwrap 时跳过工作目录之内的 PATH 项，找不到时报缺少 bwrap。理由：codex 的沙箱启动失败时，codex exec 仍以退出码 0 结束并输出 turn.completed，没有失败事件，运行中发现不了（codex 0.160.0 在本机 Linux 与 docker 实测）。codex 用 PATH 上第一个不在工作目录之内的 bwrap，找不到时才用 npm 包里自带的 bwrap；agentrun 按同样的规则查找，检查的就是 codex 会用的那一个，并且不让 codex 退回到没有检查过的自带 bwrap。运行中的附加信号见codex 的失败判定。

启动前发现的沙箱问题按 rejected 处理（退出码 2）；运行中才发现的，例如 pi 或 dsh 的包裹命令启动失败，按 failed 处理（退出码 1）。--dry-run 也做这些检查，--debug 写出每项检查的结果。

这些检查由 sandbox::check 执行。检查期间它通过 checking 回调把检查进程交给信号处理，收到信号时检查进程按进程、信号与超时清理。沙箱可用时，检查的结果是 Sandbox，它的 wrapper 字段是 Wrapper，记录用哪种方式包裹命令，用 bubblewrap 时还记录找到的 bwrap 与 socat 的路径。沙箱不可用时，--sandbox on 下 check 返回错误，这次运行按 rejected 拒绝；--sandbox relax 下结果仍是 Sandbox，wrapper 为 Wrapper::None，不可用的原因记在 reason 字段。

bwrap 启动失败的常见原因

检查失败时，报错写出 bwrap 的第一行报错，并提示 In a docker container use --sandbox off. On Ubuntu 23.10 or later, allow bwrap to create user namespaces with an AppArmor profile，后面附本节的链接。bwrap 的报错文字随调用者身份变化，所以提示同时写出两种情况，不按报错文字区分。

# 这项限制由 sysctl kernel.apparmor_restrict_unprivileged_userns=1 打开
# /etc/apparmor.d/bwrap
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
}

写入后运行 sudo apparmor_parser -r /etc/apparmor.d/bwrap 加载（Ubuntu 24.04 实测）。只给 bwrap 放行，不把上表里的这项 sysctl 改成 0。理由：改成 0 会让所有程序都能创建用户命名空间。

agentrun 不自动安装 bwrap 与 socat。理由：安装需要 root 和各发行版不同的包管理器，运行 agent 时修改系统，出了问题不容易查清原因。报错信息与 agentrun doctor 给出安装命令。

没有沙箱时的提示

relax 下沙箱没有运行、或者 off 时，text 与 rich 格式在第一行输出：

jsonl 格式不加额外的行，由 start 事件的 sandbox 与 network.enforced 字段记录。理由：relax 不打断运行，但事后能查出这次运行没有隔离。沙箱没有运行时，读取限制只剩 claude-code 的权限规则，见读取限制。

各运行时怎么关进沙箱

四个运行时在沙箱里都只能写工作目录（--cwd）与会话临时目录（见会话临时目录），pi 另外能写用户 pi 状态目录里的五个条目。能读的范围见读取限制。

pi 状态目录的放行按平台实现，输入都是 src/sandbox/mod.rs 的 PiState：

• Linux：bwrap 把整个状态目录 --bind 为可写，再把目录里已有的其他条目（跟随符号链接后是目录或普通文件的）逐个 --ro-bind 只读覆盖；auth.json 是指向别处的符号链接时，最后再 --bind 链接目标。bwrap 不能只绑定一个还不存在的文件，而 pi 要在目录里新建锁目录，所以整目录可写。剩余风险：沙箱里的 agent 能在状态目录里新建原本没有的条目，例如 extensions/，用户下次在沙箱外运行 pi 时会加载它；已有的条目不能改写。
• macOS：Seatbelt 配置在默认放行的基础上禁止所有写入，再只放行工作目录、会话临时目录、状态目录里这五个条目的字面路径（literal，来自 PiState 的 writable，不存在的也写，pi 自己创建）、auth.json 是符号链接时的链接目标，以及 /dev/null、终端等几个设备文件；禁止所有网络，只允许连接过滤代理在本机监听的端口。pi 直接连接这个端口，不经过 socat。配置写在会话临时目录的 seatbelt.sb，权限 0600。状态目录里的其他条目不能新建也不能改写。

pi、dsh、doctor 的沙箱与网络检查、测试里的 FakeAdapter 都通过 sandbox::wrap 包裹，--dry-run 时不写 Seatbelt 配置。理由：包裹逻辑分开写时，改了 bwrap 参数、socat 转发或 Seatbelt 配置的一处，另外几处不会跟着变，doctor 与测试检查的就不再是运行时实际使用的包裹。

doctor 的沙箱与网络检查通过 runtime::model_service_host、runtime::service_hosts、runtime::sandbox_state、runtime::default_denied_reads、runtime::proxy_needed 与 codex::sandbox_command 取运行时的参数，沙箱检查里是否另在沙箱中启动运行时取自 runtime::starts_inside_wrapper。只属于 codex 自己沙箱的检查（需要 codex 可执行文件、不检查私有地址、fake-ip 提示）按 Wrapper::Codex 判断，不按运行时判断。理由：分开写时改了一个运行时的启动参数，doctor 检查的就不再是运行时实际使用的参数。

各运行时的完整参数见运行。几个容易被改坏的决定：

• pi 只放行五个条目，不放行整个状态目录：状态目录里有 pi 的启动脚本、bin/ 与扩展，沙箱里的 agent 能改写它们时，用户下次在沙箱外运行 pi 就会执行 agent 写进去的代码。放行的五个条目是 pi 刷新令牌、读写模型缓存与读设置文件时必须写的文件与锁目录，锁必须建在用户目录里才能与用户自己的 pi 互斥，理由见pi 使用用户的状态目录。
• codex 用 default_permissions 选择自定义权限配置，不传 --sandbox。理由：传了 --sandbox 时权限配置不生效；显式选择内置的 :workspace 时 codex 忽略 sandbox_workspace_write 的各项，/tmp 与 $TMPDIR 仍可写（codex 0.159.2 实测与源码）。
• dsh 关掉自己的沙箱，只用 agentrun 的包裹，理由见运行页的 dsh 一节：两层沙箱叠加时 bash 的 /tmp 在命令结束后消失，macOS 上每条 bash 命令都被拒绝。
• pi 与 dsh 的包裹不加 --unshare-pid，让 agentrun 能在宿主的 /proc 里找到 bwrap 的子进程并直接给它发信号；不加 --new-session，让进程组的 SIGKILL 能清理沙箱里的全部进程，见进程组与信号。代价是沙箱里的进程能看到宿主上的其他进程，写限制不受影响。
• macOS 上 Seatbelt 按真实路径匹配，/tmp 与 /var 指向 /private，所以可写路径先解析符号链接再写进配置。
• 沙箱打开时 claude-code 用 dontAsk，不用 auto。理由：Edit 与 Write 在 claude 进程里执行，不经过沙箱；auto 模式会放行写到工作目录以外的请求，即使放行规则只列了工作目录（claude 2.1.289 云端实测，Write 写成了 $HOME 与 /tmp 下的文件）。dontAsk 拒绝放行规则以外的所有调用，被拒绝的调用交还模型，Bash 仍由沙箱自动放行。被拒绝的调用记为 tool 事件的 denied。
• 被沙箱拦下的写入或联网不算 failed，也不设 tool 事件的 denied。denied 只表示运行时权限机制的拒绝。理由：命令失败的结果会交还模型，由模型决定下一步，和其他命令出错一样。

读取限制

agent 默认读不到下表的路径。--deny-read PATH 另外加一个文件或目录，可重复；--no-default-deny-read 去掉默认列表，只保留 --deny-read 给出的路径。目录的全部内容都读不到。

• ~ 与这四个变量取会话环境里的值（--env 与 --env-file 之后），相对路径按工作目录解析，与运行时自己查找登录文件的方式相同。运行 dsh 时会话环境里已经删除了 DSH_HOME（见会话环境），这时取调用方环境里原来的 DSH_HOME（Session 的 removed_values），没有时取 ~/.dsh。理由：用户自己运行 dsh 时，key 与会话记录在这个目录里。会话环境没有 HOME 时，主目录里的条目不加。用 --env HOME=... 或 --env-file 给 agent 另一个主目录时，默认列表只挡新主目录下的条目，调用方自己主目录里的 ~/.ssh、~/.aws 等不在列表里，agent 能读到；需要时用 --deny-read 加上这些路径。
• agent 的工具与命令不需要读这几个会话记录路径：codex 与 dsh 用私有目录（CODEX_HOME、DSH_HOME）；claude-code 沙箱里的 memory 目录在会话临时目录，没有 --session-dir 时用 --no-session-persistence 不写记录，给出时由 claude 进程在运行期间把记录写进 projects/、继续会话时从 --session-dir 读取，都在沙箱外，不受读取限制，见保存与继续会话。所以四个运行时都挡住它们。
• pi 的整个进程在沙箱里，要读写自己的登录文件来登录和刷新令牌，所以运行 pi 时不挡它。claude-code 与 codex 的进程在沙箱外读写自己的登录文件，只有它们的工具与命令受读取限制，所以运行它们时自己的登录文件也挡住。dsh 的整个进程在沙箱里，但用会话环境里的 DEEPSEEK_API_KEY 与私有 DSH_HOME，不读用户的 ~/.dsh，所以运行 dsh 时它自己的 .env 也挡住。
• --deny-read 的相对路径按 agentrun 的当前目录展开成绝对路径。以 ~ 开头的路径是用法错误（退出码 2），detail 为 --deny-read <路径>: ~ is not expanded, give the full path，因为 ~/.env 会被当成当前目录下名为 ~ 的目录，什么也挡不住。
• 路径等于或包含运行需要的目录时是用法错误，detail 为 --deny-read <路径>: contains the <名称> <目录>；默认列表里包含这些目录的项直接去掉。这些目录是工作目录（working directory）、会话临时目录所在的目录（temporary directory，调用方的 TMPDIR，未设时 /tmp），运行 pi 时还有 pi 的状态目录（pi state directory）。理由：工作目录读不到时 agent 无法工作；会话临时目录里有图片的副本、codex 的私有 CODEX_HOME 与 claude-code 的 memory 目录；pi 在沙箱里读自己的状态目录来登录。包含的判断：两个路径都存在时跟随符号链接展开后比较；有一个不存在时，按字面去掉 . 与 .. 后比较，所以 <工作目录>/../x 不算在工作目录之内。判断在 src/runtime/mod.rs 的 contains。
• 最终的列表按默认列表在前、--deny-read 在后的顺序去重，写进 start 事件的 deny_read 与 --dry-run、--debug 的 deny read: 一行。

路径在 sandbox::hidden 里解析成 Hidden（真实路径与是否目录），pi、dsh、doctor 与 codex 都用它。几个容易被改坏的决定：

• 不存在的路径在 bwrap、Seatbelt 与 codex 里跳过：bwrap 不能在只读的根目录上新建挂载点，而沙箱里的 agent 只能在可写目录里新建文件。claude-code 的规则按路径匹配，不存在的路径也写。
• claude-code 同时写权限规则与 denyRead。只写权限规则时，claude-code 会把 Read 的拒绝规则并入沙箱（claude 2.1.303 云端实测），显式写 denyRead 不依赖这项内部行为；Read、Grep、Glob 在 claude 进程里执行，只能靠权限规则。
• Read 被规则拒绝时 claude-code 不输出 permission_denied，只返回工具错误 <tool_use_error>File is in a directory that is denied by your permission settings.</tool_use_error>；沙箱没有运行时 Write 写这些路径返回 <tool_use_error>File is covered by a Read deny rule in your permission settings and cannot be written.</tool_use_error>。适配器按这两段文字把调用标为 denied，与 Grep、Glob 一致，见claude-code 的输出映射。只认以 <tool_use_error> 开头的结果，因为 Bash 命令的输出里也可能出现同样的文字。
• doctor 的沙箱与网络检查带上默认列表，检查的就是实际运行时的挂载与配置。沙箱检查另外把检查目录里的一个文件加进列表，确认沙箱里读不到它。

网络

--network 决定 agent 的命令与网页工具能访问哪些主机。它的限制只在沙箱运行时生效；沙箱没有运行时按沙箱模式处理。

--allow-host HOST[:PORT] 可重复。HOST 是完整主机名，或 *.example.com（匹配所有子域名，不匹配 example.com 本身）。不写端口时允许 443 与 80。以下情形是用法错误：custom 但没有 --allow-host；给了 --allow-host 但不是 custom；主机名里有 * 但不是以 *. 开头；单独一个 *；主机为空或端口不是 1 到 65535 的整数；主机是 IPv6 字面量（见不支持 IPv6）。理由：单独的 * 与 full 同义，只保留一种写法，start 事件里一眼能看出是否全开。

full 与 custom 默认拒绝解析到私有地址的主机，主机名或 IP 被逐字列在 --allow-host 里时放行；*.example.com 这类通配规则匹配到的主机仍然检查，因为允许用户自建子域名或泛解析的域名能让某个子域名解析到内网地址。私有地址是 0.0.0.0/8、10.0.0.0/8、100.64.0.0/10、127.0.0.0/8、169.254.0.0/16、172.16.0.0/12、192.168.0.0/16。198.18.0.0/15 不在其中：本机 DNS 由代理工具做 fake-ip 时，公网域名解析到这个网段，把它当作私有地址会让放行列表里的主机也被拒绝。

custom 不打开网页搜索的理由：claude-code 的网页搜索与 codex 的网页搜索在服务商的服务器上执行，无法按主机限制，而且搜索词本身可以带出文件内容。

过滤代理

沙箱打开且需要按主机放行时，agentrun 在启动运行时之前在自己的进程里启动一个过滤代理，会话结束时关闭。代理运行在沙箱外，沙箱里的进程只能连到它。

• 协议：HTTP 代理（CONNECT 隧道与普通 HTTP 转发）和 SOCKS5 CONNECT。不解密 HTTPS，只按目标主机名与端口判断。
• 目标主机名只接受字母、数字、-、_、. 组成、最长 253 个字节的名字与 IPv4 字面量，其他字节或更长的目标按请求格式错误处理（HTTP 400，SOCKS5 拒绝），不输出 network 事件，所以事件与发给上游的请求行里不会出现别的字符。
• 请求行的版本只接受 HTTP/1.0 与 HTTP/1.1，CONNECT 也一样。请求行或请求头格式错误时回复 400，不输出 network 事件，包括版本后面还有内容、以空格开头的续行头（obs-fold）、头名与冒号之间有空白、头名含有 token 以外的字符，以及请求头在第一个 \r\n\r\n 之前出现只用 \n 的空行。上游 HTTP 代理对 CONNECT 的回复接受头名后的空白与续行头，状态码是 2xx 时建立隧道。
• 普通 HTTP 每个连接只转发一个请求：请求体按 Content-Length 转发，带 Transfer-Encoding 的请求回复 411，之后客户端再写入的字节丢弃。请求行与 Host 头按判定过的主机与端口重写，客户端自己写的 Host 不转发，所以不能借一个放行的主机访问同一个 IP 上按 Host 区分的其他站点。
• 同时监听 127.0.0.1 上的随机端口与会话临时目录里的 Unix socket proxy.sock。Linux 的 bwrap 用 --unshare-net 断开网络，被包裹的 pi 与 dsh 由沙箱里的 socat 把同一个端口号接到这个 socket，做法与 claude-code 自己的沙箱相同；沙箱外不需要 socat。macOS 的 Seatbelt 配置只允许连接这个端口。
• 代理自己解析域名，判断私有地址，直接连接时只连解析出的地址。读请求头最多等 30 秒、最多 64 KB；连接目标时依次尝试解析出的每个地址，每个地址最多等 10 秒。
• 会话环境的 HTTPS_PROXY、HTTP_PROXY、ALL_PROXY 与它们的小写形式指向代理，NO_PROXY 与 no_proxy 清空。小写也要设，因为 pi 先读小写的 https_proxy，调用方环境里原有的小写变量会让 pi 绕过过滤代理（pi 1.0.1 实测）。
• 调用方环境里原有的代理变量改由过滤代理作为上游使用，所以 Cloud Managed 容器自带的出口代理仍然生效：CONNECT 与 SOCKS5 依次取 https_proxy、HTTPS_PROXY、all_proxy、ALL_PROXY，普通 HTTP 依次取 http_proxy、HTTP_PROXY、all_proxy、ALL_PROXY，第一个非空的值生效。只支持 http:// 上游，地址里的用户名与密码转为 Proxy-Authorization: Basic；其他协议的值当作没有上游。调用方原有的 no_proxy 或 NO_PROXY 匹配的主机直接连接。目标主机解析失败时，有上游则交给上游连接，没有上游则按连接失败处理。代理变量的值可能带凭据，不出现在任何输出里。
• 每个「主机、端口、放行或拒绝」组合第一次出现时输出一个 network 事件，见事件与输出。
• HTTP 代理拒绝请求时回复 403，响应体为 agentrun: <主机>:<端口> is not allowed (<reason>)。放行后连接失败时回复 502，响应体为 agentrun: <主机>:<端口> <原因>，让沙箱里的 agent 与调用方能看出连接为什么失败。原因是下面几种之一，括号里的错误是操作系统给出的错误描述：
  • could not be resolved：本机解析不到目标主机的 IPv4 地址，又没有上游代理。
  • connection failed (<错误>)：直接连接时每个地址都连接失败，错误取最后一个地址的。
  • upstream proxy connection failed (<错误>)：连不上上游代理，或者向上游代理写请求、读回复时出错。
  • upstream proxy did not answer in time：上游代理在 30 秒内没有回复完 CONNECT 的回复头。
  • upstream proxy closed the connection：上游代理在回复头结束之前关闭了连接。
  • upstream proxy answered <状态码>：上游代理对 CONNECT 回复了 200 到 299 以外的状态码。
  • upstream proxy answered an invalid response：上游代理的回复头超过 64 KB，或者读不出状态码。
  原因里不出现上游代理的主机、端口与凭据。SOCKS5 的回复只有回复码，没有原因文字；network 事件只记放行或拒绝，不记连接结果。

不支持 IPv6

过滤代理与网络限制只支持 IPv4：只在 127.0.0.1 监听；解析目标主机只取 IPv4 地址，没有 IPv4 地址时按连接失败处理；目标是 IPv6 字面量时拒绝，reason 为 not_allowed；--allow-host 的主机是 IPv6 字面量时是用法错误；SOCKS5 的 IPv6 地址类型回复「不支持的地址类型」。理由：Cloud Managed 容器的内核没有 IPv6，IPv6 的路径无法在云端验收。已知后果：在 localhost 先解析为 ::1 的主机上，claude-code 在沙箱外用 TCP:localhost:<端口> 连接过滤代理可能失败，由本机 Linux 实测确认。

没有直接用各运行时自带的网络设置，因为它们能力不一致：claude-code 沙箱的 allowedDomains 不接受单独的 *，表达不了 full（claude 2.1.289）；codex 按主机放行要开启它自带的实验性代理，而且这个代理拒绝解析到私有网段的主机；pi 没有任何网络控制，dsh 自带的沙箱不限制网络。各自的做法含义不同，也没有统一的连接记录可供排查。

各运行时的做法

claude-code 的 WebFetch 在 claude 进程里运行，不经过沙箱也不经过代理，只能靠权限规则限制主机。沙箱打开时权限模式是 dontAsk，放行规则以外的主机被拒绝；沙箱没有运行时权限模式是 auto，放行规则以外的主机由分类器判断，云端实测分类器放行了不在列表里的主机，所以这时 custom 下的 WebFetch 不受主机限制，见剩余风险。claude-code 进程本身不设置代理变量，它访问 Anthropic 的流量不经过过滤代理。

claude-code 的沙箱运行时，三种取值下会话环境都设置 SOCAT_DEFAULT_LISTEN_IP=4。理由：claude-code 在断网的网络命名空间里用 socat 把沙箱里的端口转发到它的代理 socket，没有指定地址族；内核没有 IPv6 时（Cloud Managed 容器），socat 1.8 选了 IPv6 而启动失败，claude-code 丢弃它的输出，沙箱里的命令连不上任何代理。这个变量让 socat 改用 IPv4 监听。

模型服务的主机

pi 的进程整个在沙箱里，它访问模型服务也要经过代理。pi 不输出服务商的地址（--list-models 与 auth check 都没有，pi 1.0.1），所以 agentrun 自带一张表，按 --model 的前缀判断服务商，没给 --model 时读 pi 设置里的 defaultProvider。pi 的 launch 与 doctor 的网络检查用同一个函数 pi::model_service 得到服务商与主机。模型服务的主机只在 443 端口放行，并且跳过私有地址检查：

服务商不在表里时，agentrun 不知道该放行哪个主机。none 下启动前报错（退出码 2），detail 为 cannot tell which host pi's model service uses (provider: <服务商或 unknown>). Use --network custom --allow-host <host of the model service>；没给 --model 且 pi 设置文件不存在、不是 JSON 或没有 defaultProvider 时服务商按 unknown 处理；custom 下只放行 --allow-host 列出的主机；full 不受影响。

dsh 的进程也整个在沙箱里，它的模型服务主机由 dsh::service_host 给出，launch 与 doctor 的网络检查都用它：会话环境里 DEEPSEEK_BASE_URL 不为空时取这个地址的主机（network::url_host：:// 之后、第一个 /、? 或 # 之前的部分，去掉用户信息后按过滤代理解析请求目标的同一规则取主机，即去掉端口、转成小写、去掉末尾的点），否则为 api.deepseek.com。与 pi 相同，这个主机只在 443 端口放行并跳过私有地址检查；模型服务用其他端口时，用 --network custom --allow-host HOST:PORT 放行。DEEPSEEK_BASE_URL 读不出主机时（没有 ://、主机为空、不是合法的主机名、端口为空、不是数字或大于 65535，或者主机是 IPv6 字面量，见不支持 IPv6），none 下启动前报错（退出码 2），detail 为 cannot tell which host dsh's model service uses from DEEPSEEK_BASE_URL. Use --network custom --allow-host <host of the model service>；custom 下只放行 --allow-host 列出的主机；full 不受影响。dsh 的网页搜索也只连 api.deepseek.com，这是关闭它的理由之一。

codex 的进程不在沙箱里，none 与 full 下它直接访问模型服务。custom 下 codex 进程的 HTTPS_PROXY 指向过滤代理，它自己的请求也经过过滤代理，所以过滤代理另外放行下面四个主机，不看用户用哪种方式登录：

后两个主机取自 codex 0.159.2 内置的地址，没有实测。只放行前两个时，令牌过期的那次运行刷新失败，API key 登录完全不能用。

配置与账号

agent 不应读到用户自己的运行时配置、插件、规则、MCP 服务器与会话记录，也不应把记录写进用户的会话。各运行时都用参数关闭这些来源，详见运行：

• claude-code：不加载用户、项目与本地设置，不加载 MCP 服务器，关闭 auto-memory，新会话每次传一个新生成的会话 id。沙箱打开时 auto-memory 目录改到会话临时目录，agent 不能写用户的 memory 目录。
• codex：使用私有的 CODEX_HOME，只带入用户的登录文件，见私有配置目录；不读工作目录里的 AGENTS.md 与 .codex/，不加载技能说明；关闭插件、连接器、hooks 等会给模型增加工具的功能。
• pi：不加载扩展、技能、提示模板、主题与上下文文件，不信任工作目录里的项目级配置，启动时不联网下载资源。用户状态目录里的设置、自定义模型与 bin/ 照常读取，见pi 使用用户的状态目录。
• dsh：使用会话临时目录里的私有 DSH_HOME 与空的 DSH_AGENTS_HOME，见dsh 的私有配置目录；补丁关闭指令文件、技能、会话记录随请求上传、插件清单上报、遥测与会话标题请求。工作目录的 .env 无法关闭，见剩余风险。

四个运行时默认都不保存会话。调用方给出 --session-dir 时，运行结束后会话记录移到那个目录，--resume 只从那里读，不读用户自己的会话记录。运行期间 codex 的记录在私有目录里，pi 与 dsh 的记录在会话临时目录里；claude-code 的新会话写在用户配置目录的 projects/ 里，结束后才移走，带来的风险见剩余风险，做法见保存与继续会话。

账号由登录方式决定。会话环境按运行时删除会改变登录方式的变量，容器里的凭据由环境变量写入登录文件，见会话环境。

剩余风险

读取限制按路径匹配。限制范围以外已有的硬链接指向同一个文件时，通过硬链接能读到内容。工作目录里被拒绝读取的目录，沙箱运行时 claude-code 的命令写进去报告成功，但写入的文件在运行结束后不存在（Linux 上这个目录在沙箱里换成了空目录，云端实测）；pi 写进去时报只读错误；codex 的拒绝项优先于工作目录的写权限，文件不会写出（codex 0.160.1 macOS 实测）。

读取限制只针对文件。会话环境里的变量（例如 DEEPSEEK_API_KEY 与容器里的令牌）agent 都能读到；默认列表以外的凭据文件，需要用 --deny-read 自己加上。pi 的会话记录目录（状态目录里的 sessions/）不在默认列表里。

保存会话（--session-dir）的剩余风险：

• claude-code 的新会话在运行期间写在用户的配置目录里，运行结束后才移到 --session-dir。只有给出 --session-dir 时这样做，不给时仍加 --no-session-persistence，不写记录。failed、interrupted、timeout 与 limit 的运行同样在结束时移走（云端实测 interrupted、timeout 与 limit）。运行期间用户自己的 claude --resume 列表能看到它；agentrun 被 SIGKILL 时它留在用户的配置目录里。运行期间用户在同一个工作目录里运行 claude --continue 可能接上这次运行的会话，用户写进去的内容在运行结束时随记录一起被移到 --session-dir。
• pi 与 dsh 的记录在运行期间放在会话临时目录里，沙箱里的 agent 能改写这次会话的记录，改写后的内容随记录一起保存，下次继续时进入模型上下文。其他会话的记录 agent 写不到。
• --session-dir 放在工作目录或会话临时目录之内时，沙箱里的 agent 能改写已保存的全部会话，改写的内容在下次继续时进入模型上下文。agentrun 不检查这一点，由调用方把目录放在两者之外。

过滤代理本身的剩余风险：

• HTTPS 只按 CONNECT 的主机名与端口判定，TLS 里的 SNI 与 Host 不检查。放行的主机如果和别的站点共用 IP 并按 SNI 选站点，隧道里可以访问那些站点。
• 有上游代理时，私有地址只看本机的解析结果，上游会自己再解析一次；本机解析失败时不做检查，直接交给上游，主机只有 IPv6 地址时同样不做检查。理由：Cloud Managed 容器的本机 DNS 常常不可用，解析不出地址时拒绝会让 full 在那里几乎不能用。
• 过滤代理在本机回环地址上监听 TCP 端口，会话期间同一台机器上的其他用户也能连这个端口，经它发出的请求会带上调用方的上游代理凭据。
• full 下 claude-code 的 WebFetch 在 claude 进程里运行，不经过过滤代理，也就没有私有地址检查。

不走代理的程序在沙箱里连不上网。例如 git clone git@github.com:... 走 SSH，即使用了 --network full 也会失败；改用 HTTPS 地址可以成功。