网络访问为什么另有一条决策链

第 18 章停在一个仍然存活的进程上。它已经离开当前 tool future，却还可能通过 session 的 ProcessStore 被继续寻址。现在假设这个进程执行 curl：真正到达代理的不是“某条命令准备联网”这一高层意图，而是一条带 host、port、protocol 的 HTTP 或 SOCKS 请求。

这也是网络访问另开一条决策链的原因。shell 审批回答的是命令能否继续执行；network proxy 必须对实际目标再判断一次。命令获批不代表任意域名随之获批，Guardian 的 allow 也不能覆盖代理更早做出的显式 deny。

固定版本的顺序可以先压成一句话：

execution attribution
  -> explicit deny
  -> conditional local/private guard
  -> allowlist
  -> only a `NotAllowed` result (normally an allowlist miss) may call the decider
  -> approval service
  -> permission hook
  -> Guardian or user reviewer

这条链里最重要的边界不在最后的 approve / deny 按钮，而在“什么请求有资格走到 reviewer”。

先找回这次访问属于哪次执行

managed proxy 是 session 级共享对象，网络连接却来自某次具体执行。begin_network_approval 为调用登记 registration_id、turn、command、environment 与 cancellation token；Linux seccomp 路径还会生成另一个 attribution token，建立 execution-scoped proxy。registration id 是 core 的 execution id，attribution token 只是共享 proxy ingress 的内存查表键，两者不能混成一个身份。

trusted Linux bridge 会在应用协议之前写入一个短 frame。BindConnectionAttribution 读出 token，向 NetworkProxyState 查 execution-scoped state；未知 token 或已绑定 environment 不一致会在 ingress 处返回 PermissionDenied。成功时，scoped state 被放进这条 TCP stream 的 extensions，后续 HTTP / SOCKS handler 才能从同一连接拿到 environment 与 execution id。

这里有一个容易写过头的地方：首字节不是 attribution frame 的 magic 时，读取函数返回 None，代理继续使用 base state。源码证明的是“受信 bridge 可以给连接补上 execution attribution”，不是“所有代理连接都强制携带 token”，更不是 token 本身提供了密码学认证。

到了 core，NetworkApprovalService 再用 request 上的 execution id 查 active call，并核对 environment。这里必须区分“没有 owner”与“没有 attribution”。

带 execution_id 的请求如果找不到 active call，或 environment 不匹配，整个 attribution 才是 None。只带 environment_id 时，即使 active calls 有多个或一个也没有，service 仍返回带 environment 的 attribution，只把 owner_call 留为 None；后续仍可用当前 turn context 和合成的 network-access 命令继续 cache、gate 与 reviewer。

两个 id 都没有时，唯一 active call 才能用来推断 owner。多个并发调用无法安全归属，整个 attribution 返回 None；没有 active call 则返回一份无 owner 的空 attribution，再尝试由 turn context 补 environment。attribution 在这里负责把网络结果尽量交还正确 owner，不负责放宽 policy。

三道固定策略先于任何 reviewer

proxy 将 host 规范化后按固定顺序判断。这个顺序直接写在 NetworkProxyState::host_blocked 里：

denylist 永远先于 allowlist。即使 allowlist 是全局 *，命中 deny 的 host 也先返回。

local/private gate 只在 allow_local_binding 关闭时运行。精确写入 allowlist 的 local、loopback 或 IP literal，可以通过这一次 host_blocked 检查；*、子域通配和其他 wildcard 不算精确例外。hostname 一旦解析到 non-public IP，即使已经命中 allowlist，也仍会被挡住。

通过这层例外还不等于连接已经建立。direct connector 会按最终 socket address 再拒绝 non-public IP；man-in-the-middle（MITM，中间人代理）的 inner HTTPS 请求也会在 CONNECT 之后重跑 local/private 检查。对可解析 host 来说，allowlist 未配置或未命中通常产生 NotAllowed；格式无法解析的 host 在本 tag 也复用这个 reason。因此，严格说 decider 的入口是 reason，而不只是 allowlist miss。

源码里的“private”实际比 RFC1918 更宽。IPv4 还覆盖 loopback、link-local、unspecified、multicast、broadcast、CGNAT、TEST-NET、benchmark 与 reserved ranges；IPv6 覆盖 mapped IPv4、loopback、unspecified、multicast、unique-local 与 link-local。因此正文里把这层只叫“内网 IP 检查”会漏掉它的 fail-closed 范围。

evaluate_host_policy 按 reason 只对 HostBlockReason::NotAllowed 调用动态 NetworkPolicyDecider；在这个固定 tag 中，正常的已解析 host 上它通常代表 allowlist miss，但 Host::parse 失败也会复用同一个 reason。Denied、NotAllowedLocal 等其余 block reason 直接变成 source = BaselinePolicy、decision = Deny。所以后面的 service cache、hook、Guardian 或用户 reviewer 都不能覆盖显式 deny 或 private-network guard；“可覆盖 allowlist miss”是常见路径，不是对所有 NotAllowed 输入的语法保证。

flowchart TB
  accTitle: 网络目标从 attribution 到 reviewer 的决策链
  accDescr: 请求先尝试绑定 execution，再依次检查显式 deny、条件性的 local 或 private 限制与 allowlist；显式 deny 和未通过 private guard 的请求直接终止，只有 NotAllowed 通常为 allowlist miss 才可进入 NetworkApprovalService，并在 hook 后路由到 Guardian 或用户 reviewer
  REQUEST["HTTP / SOCKS request"] --> ATTR["execution attribution"]
  ATTR --> DENY{"explicit deny?"}
  DENY -->|yes| HARD_DENY["BaselinePolicy / Deny"]
  DENY -->|no| PRIVATE{"local or non-public blocked after literal exception?"}
  PRIVATE -->|yes| PRIVATE_DENY["BaselinePolicy / Deny"]
  PRIVATE -->|no| ALLOWLIST{"allowlist match?"}
  ALLOWLIST -->|yes| ALLOW["Allow"]
  ALLOWLIST -->|no| DECIDER{"decider installed?"}
  DECIDER -->|no| MISS_DENY["BaselinePolicy / Deny"]
  DECIDER -->|yes| SERVICE["NetworkApprovalService"]
  SERVICE --> GATES{"attribution, cache and gates"}
  GATES -->|fail| DECIDER_DENY["Decider / Deny"]
  GATES -->|continue| HOOK["permission-request hook"]
  HOOK -->|allow or deny| RESULT["NetworkDecision"]
  HOOK -->|no decision| ROUTE{"review route"}
  ROUTE -->|auto-review| GUARDIAN["Guardian"]
  ROUTE -->|manual| USER["user reviewer"]
  GUARDIAN --> RESULT
  USER --> RESULT

图中的 private 分支表示 host_blocked 在处理完精确 local-literal 例外后仍返回 NotAllowedLocal，不是所有 local literal 的无条件硬拒绝；而且它只描述 host policy，direct upstream connector 和 MITM inner request 还会按连接时的 non-public address 再检查一次。

这张图只画 network target policy。普通命令可能在首次 sandbox attempt 前已经经过一次 exec approval；那次批准不会删除图里的前三道网络检查。

Ask 是一张窄门票

proxy 的类型有一点反直觉：NetworkDecision 只有 Allow 和 Deny { ... } 两个外层 variant，动态 decider 想申请审批时会返回 NetworkDecision::Deny { decision: Ask, source: Decider }。这表示当前请求仍被阻断，但阻断携带了一张“可以申请”的票；它不等于拒绝已经被推翻。

core 对这张票做了更严格的投影。NetworkPolicyDecisionPayload 必须同时满足 decision == Ask 与 source == Decider，随后还必须有 protocol、非空 host，才能产生 NetworkApprovalContext。任何 Deny，包括 Deny + Decider，都会得到 None。

orchestrator 收到 managed-network sandbox denial 后先尝试提取这个 context。只要 payload 存在而 context 不存在，它就把原始 SandboxErr::Denied 返回，不构造 retry approval。显式 deny 因此在 Guardian 之前已经结束；Guardian 没有拿到 request，自然无从把 deny 翻成 allow。

core 还为这条边界提供了明确文案：denylist block 会告诉模型，domain 被 policy 显式拒绝，cannot be approved from this prompt。这不是 Guardian 的风险判断，而是 deterministic policy 的终态说明。

NetworkApprovalService 拥有什么

NetworkApprovalService 是 session 里的协调者，不是最终 enforcement engine。它持有四组状态：active call 与 outcome、相同 host 正在等待的 approval、session-approved hosts、session-denied hosts。host cache key 由 environment、lowercased host、protocol 与 port 组成；因此一次 https approval 不会顺手批准同 host 的任意 protocol、port 或 environment。

service 处理 NotAllowed（通常是 allowlist miss）时的真实顺序是：

1. 用 execution / environment 找 owner；只有整体 attribution 缺失才拒绝，带 environment 但 owner_call=None 的请求仍可继续。
2. 先查 session deny cache，再查 allow cache。
3. 用同一个 HostApprovalKey 合并并发等待者，只有第一个 pending request owner 创建 reviewer request；这不要求 owner_call 存在。
4. 缺 active turn、缺 environment、Permission Profile 不是 Managed，或 approval policy 为 Never 时 fail closed。
5. permission-request hook 有决定就直接采用；没有决定才路由 Guardian 或用户。

hook 也属于 reviewer 之前的 governor。Allow 产生本次放行，Deny 记录 policy outcome 并唤醒相同 host 的等待者。只有 hook 没有返回决定时，service 才根据 routes_approval_to_guardian 选择自动 reviewer；否则发送普通 command approval event 给用户。

review 结果再被折回三个内部状态：allow once、allow for session、deny。ApprovedForSession 才写 session allow cache；deny amendment 才写 session deny cache。普通 denial 不会永久污染后续 session 请求，重复请求仍可能重新走 reviewer。

Guardian 是通用 reviewer

GuardianApprovalRequest 同时覆盖 shell、Unified Exec、Unix execve、apply patch、network access、MCP tool call 与 request permissions。network 只是其中一个 variant，携带 target、host、protocol、port，以及可选的触发命令。Guardian 因而是这套审批系统的一般 reviewer，不是 network policy 的 owner。

只有 OnRequest 或 Granular 且 approvals_reviewer == AutoReview 时，allowed approval prompt 才改道 Guardian。源码注释也保留了前置边界：更早的控制层仍可能 block action。Guardian review 对 timeout、review session error、prompt build error 与 parse error fail closed；取消会记录为 Aborted 并返回 ReviewDecision::Abort，而 NetworkApprovalService 把 Abort 与 Denied 一样收口为 pending deny。正常的 Allow / Deny assessment 才映射成普通 ReviewDecision::Approved 或 Denied。

不要给固定版本补一个不存在的配置

第 17 章已经列过 GranularApprovalConfig 的 baseline。固定 tag 只有五个 gate：sandbox_approval、rules、skill_approval、request_permissions、mcp_elicitations。其中没有 network_approval。把下面这种 proposal 写成当前可用配置，会制造一条源码中不存在的控制面：

# 仅为未落地提案示意；rust-v0.144.6 不接受这个字段。
[approval_policy.granular]
network_approval = true

当前网络审批是否能进入动态链，由已经落地的组合决定：session 是否配置 managed network requirements、proxy 是否安装 decider、Permission Profile 是否为 Managed、approval policy 是否不是 Never。start_proxy 的 enable_network_approval_flow 只是 core 调用的内部 bool 参数；它不是 serde 字段，也不是用户可写的 network_approval 配置。

policy amendment 已落地，但入口仍受 context 限制

proposed_network_policy_amendments 与虚构的 granular config 字段不是一回事。用户审批 event 可以为当前 NetworkApprovalContext.host 生成 allow / deny amendment 候选。收到 amendment 后，session 先验证 amendment host 与刚刚批准的 host 规范化后完全一致，再更新运行中 proxy 的 allowlist 或 denylist，最后追加 exec-policy network rule。

这条持久化链仍然改变不了显式 deny 的顺序。amendment proposals 依赖一个已经存在的 NetworkApprovalContext；explicit deny 不产生 context，所以当前 prompt 连 amendment 入口都到不了。即使 session cache 曾批准过同一个 host，proxy 也只在 host_blocked 返回 NotAllowed 时询问 decider，后来加入的 baseline deny 仍会先挡住请求。

另一个失败边界发生在持久化阶段：service 对 amendment persistence error 发 warning，但当次 resolved decision 仍按 allow-for-session 或 deny 收口。运行中 proxy update 与磁盘 exec-policy append 不是原子事务，不能把“本次 reviewer 已做决定”写成“持久规则一定完整落盘”。

指定实验：确认 deny 不是零测试假绿

命令只在第四部源码工作台创建并校准后的 disposable archive 副本中运行。固定 checkout 只负责确认 tag、commit 和导出源码；进入临时副本的 codex-rs 目录后执行：

: "${ARCHIVE_CODEX_RS:?先执行第四部导读的 archive 准备脚本}"
cd "$ARCHIVE_CODEX_RS"
just test --locked -p codex-core --lib denied_network_policy_message_for_denylist_block_is_explicit

2026-07-21 的真实结果中，codex_core library harness 找到并运行了目标测试：

PASS ... codex-core::lib network_policy_decision::tests::denied_network_policy_message_for_denylist_block_is_explicit
Summary ... 1 test run: 1 passed

后续 binary / integration harness 如果被 name filter 排除，nextest 会显示没有命中的测试，不构成这次实验的成功证据。门禁是同时看到完整测试名、PASS 与 library target 的 1 passed；如果目标 harness 也是 zero-match，或者测试带 runtime skip，这次实验就失败。

这条测试只证明 denylist 文案映射，不证明完整代理、Guardian 与 UI 的端到端行为。显式 deny 不进入 Guardian 的证据仍来自三段可穷尽的控制流：host_blocked 先返回 Denied，evaluate_host_policy 不为它调用 decider，core 也只把 Ask + Decider 转成 approval context。

用 owner / executor / governor 收口

网络链可以落在下面这张 matrix 里。owner 保存长期或 session 状态，executor 协调或执行当前动作，governor 决定它能否继续；同一个组件偶尔承担两列职责，但不能因此抹掉接口。

持久化 write failure 不属于 governor 的批准条件，而是 failure boundary：service 会发 warning，但当次 resolved decision 仍按 reviewer 的 allow-for-session 或 deny 收口；运行中 proxy 更新与磁盘 exec-policy append 也不是原子事务。

第 20 章不会继续扩展 network proxy，而是换一个入口追踪 Skills：能力怎样被发现、筛选并注入当前 session，再把边界交给 SkillsService、mention collector 和 context fragment 这些实际 owner。见第 20 章：Skills 的发现与注入。