审批和沙箱

Codex 回合的审批与沙箱姿态，以及原生执行运行的位置。属于 Codex harness 参考 的一部分；每个章节迁移到哪里 列出了所有章节。

对于原生插件/应用工具，还需遵循 应用审批决策顺序。 应用准入、工具启用、逐工具审批模式以及 OpenClaw 的 elicitation 响应，均独立于下文的一般预设。

审批与沙箱模式¶

本地 stdio app-server 会话默认使用 YOLO 模式： approvalPolicy: "never"、approvalsReviewer: "user" 以及 sandbox: "danger-full-access"。这种受信任的本地操作者姿态可让 无人值守的 OpenClaw 回合和心跳在没有无人应答的原生审批提示的情况下继续推进。

如果 Codex 的本地系统要求文件不允许隐式 YOLO 审批、 审查者或沙箱值，OpenClaw 会将隐式默认视为 guardian， 并选择允许的 guardian 权限。tools.exec.mode: "auto" 还会强制使用 guardian 审查的 Codex 审批，并且不会保留不安全的旧版 approvalPolicy: "never" 或 sandbox: "danger-full-access" 覆盖； 如需有意采用无审批姿态，请设置 tools.exec.mode: "full"。 同一要求文件中按主机名匹配的 [[remote_sandbox_config]] 条目 会被用于沙箱默认决策。

设置 appServer.mode: "guardian" 以启用 Codex 的 guardian 审查审批：

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            mode: "guardian",
            serviceTier: "priority",
          },
        },
      },
    },
  },
}

当这些值被允许时，guardian 预设会展开为 approvalPolicy: "on-request"、 approvalsReviewer: "auto_review" 和 sandbox: "workspace-write"。单个策略字段会覆盖 mode。旧的 guardian_subagent 审查者值仍作为兼容别名被接受， 但新配置应使用 auto_review。

当 OpenClaw 沙箱处于激活状态时，本地 Codex app-server 进程仍 运行在 Gateway 主机上。因此，OpenClaw 会禁用该回合的 Codex 原生 Code Mode、 用户 MCP 服务器以及应用支持的插件执行，而不是将 Codex 主机侧沙箱视为等同于 OpenClaw 沙箱 后端。当常规 exec/process 工具可用时，Shell 访问会通过 OpenClaw 沙箱支持的动态工具 （例如 sandbox_exec 和 sandbox_process）暴露。

沙箱化的原生执行¶

稳定默认值是失败关闭：激活的 OpenClaw 沙箱会禁用原本会从 Codex app-server 主机运行的原生 Codex 执行面。只有当你想使用 OpenClaw 沙箱后端尝试 Codex 的远程环境支持时， 才使用 appServer.experimental.sandboxExecServer: true。 此预览路径使用固定版本的 Codex 0.158.0 app-server。

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            experimental: {
              sandboxExecServer: true,
            },
          },
        },
      },
    },
  },
}

当该标志开启且当前 OpenClaw 会话处于沙箱中时，OpenClaw 会启动一个由活动沙箱支持的本地 loopback exec-server，将其注册到 Codex app-server，并使用该 OpenClaw 拥有的环境启动 Codex 线程和回合。如果 app-server 无法注册该环境， 运行会失败关闭，而不是静默回退到主机执行。

沙箱化进程的输出以有序的 stdout、stderr 或 PTY 通知形式流式传输。OpenClaw 仅保留一个有界的近期输出缓冲区用于轮询 和重放，因此长时间运行的进程不会无限增大 app-server 桥接。进程退出和清理仍与沙箱拥有的进程绑定。

此预览路径仅限本地。除非远程 WebSocket app-server 运行在同一主机上，否则它无法访问 loopback exec-server，因此 OpenClaw 会拒绝该组合。

基于 Node 的 remote-exec 放置位于已配对设备或已注册的 Crabbox 云工作器上，是一条独立的、由 placement 拥有的执行路径，不需要 appServer.experimental.sandboxExecServer。Gateway 会在本地保留 Codex app-server 和 provider 认证，而经过授权的节点会通过其现有双工连接运行受管理的、 固定版本的 Codex exec-server。它需要针对 codex.exec-server.stdio.v1 的显式 gateway.nodes.commands.allow 授权、已批准的配对界面，以及每次尝试的启动授权。刻意选择的会话 Full access 权限只有在确切的已准入回合和放置仍然有效，并且节点本地的 tools.exec 与 exec-approvals 下限都允许 full/off 执行时，才能替代关键的 allow-once 提示。普通调用者和 raw 调用者 仍需要人工审批。本地 deny 会阻止任一启动；本地 ask 和 allowlist 策略无法通过 Full access 绕过。设置期间本地策略 发生变化会拒绝启动。Gateway 和节点都必须支持此 授权路径；缺少节点策略支持会失败关闭。节点会获得全新的私有 home 和已清理的环境，绝不会获得 Gateway provider、云 或 GitHub 凭据。节点连接丢失会终止该尝试和 进程，而不是恢复它。每个基于节点的尝试都会使用自己的 Gateway app-server 客户端，因为 Codex 可以注册远程环境，但无法 从运行中的 app-server 移除一个环境。节点 exec-server 不会占用 OpenClaw worker 槽位。包含认证、cookies、API 密钥或其他携带凭据的标头的 HTTP 请求会在到达节点之前被拒绝；请改用 Gateway 拥有的已认证请求或无凭据端点。 支持常规 Codex 回合，但在 /btw 侧边问题能够绑定到活动放置之前不可用。 受管理的放置工作区不是操作系统沙箱：已批准的进程和 文件拥有节点账户的完全访问权限。需要隔离时，请使用单独的最低权限节点 账户。 参见 在已配对设备上运行 Codex 和 在云工作器上运行 Codex。