core-agent-ide/codex-rs/network-proxy
Charley Cunningham e84ee33cc0
Add guardian approval MVP (#13692)
## Summary
- add the guardian reviewer flow for `on-request` approvals in command,
patch, sandbox-retry, and managed-network approval paths
- keep guardian behind `features.guardian_approval` instead of exposing
a public `approval_policy = guardian` mode
- route ordinary `OnRequest` approvals to the guardian subagent when the
feature is enabled, without changing the public approval-mode surface

## Public model
- public approval modes stay unchanged
- guardian is enabled via `features.guardian_approval`
- when that feature is on, `approval_policy = on-request` keeps the same
approval boundaries but sends those approval requests to the guardian
reviewer instead of the user
- `/experimental` only persists the feature flag; it does not rewrite
`approval_policy`
- CLI and app-server no longer expose a separate `guardian` approval
mode in this PR

## Guardian reviewer
- the reviewer runs as a normal subagent and reuses the existing
subagent/thread machinery
- it is locked to a read-only sandbox and `approval_policy = never`
- it does not inherit user/project exec-policy rules
- it prefers `gpt-5.4` when the current provider exposes it, otherwise
falls back to the parent turn's active model
- it fail-closes on timeout, startup failure, malformed output, or any
other review error
- it currently auto-approves only when `risk_score < 80`

## Review context and policy
- guardian mirrors `OnRequest` approval semantics rather than
introducing a separate approval policy
- explicit `require_escalated` requests follow the same approval surface
as `OnRequest`; the difference is only who reviews them
- managed-network allowlist misses that enter the approval flow are also
reviewed by guardian
- the review prompt includes bounded recent transcript history plus
recent tool call/result evidence
- transcript entries and planned-action strings are truncated with
explicit `<guardian_truncated ... />` markers so large payloads stay
bounded
- apply-patch reviews include the full patch content (without
duplicating the structured `changes` payload)
- the guardian request layout is snapshot-tested using the same
model-visible Responses request formatter used elsewhere in core

## Guardian network behavior
- the guardian subagent inherits the parent session's managed-network
allowlist when one exists, so it can use the same approved network
surface while reviewing
- exact session-scoped network approvals are copied into the guardian
session with protocol/port scope preserved
- those copied approvals are now seeded before the guardian's first turn
is submitted, so inherited approvals are available during any immediate
review-time checks

## Out of scope / follow-ups
- the sandbox-permission validation split was pulled into a separate PR
and is not part of this diff
- a future follow-up can enable `serde_json` preserve-order in
`codex-core` and then simplify the guardian action rendering further

---------

Co-authored-by: Codex <noreply@openai.com>
2026-03-07 05:40:10 -08:00
..
src Add guardian approval MVP (#13692) 2026-03-07 05:40:10 -08:00
BUILD.bazel chore: reverse the codex-network-proxy -> codex-core dependency (#11121) 2026-02-08 17:03:24 -08:00
Cargo.toml feat(network-proxy): add embedded OTEL policy audit logging (#12046) 2026-02-25 11:46:37 -05:00
README.md fix: support managed network allowlist controls (#12752) 2026-03-06 17:52:54 -08:00

codex-network-proxy

codex-network-proxy is Codex's local network policy enforcement proxy. It runs:

  • an HTTP proxy (default 127.0.0.1:3128)
  • a SOCKS5 proxy (default 127.0.0.1:8081, enabled by default)

It enforces an allow/deny policy and a "limited" mode intended for read-only network access.

Quickstart

1) Configure

codex-network-proxy reads from Codex's merged config.toml (via codex-core config loading).

Network settings live under the selected permissions profile. Example config:

default_permissions = "workspace"

[permissions.workspace.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
# SOCKS5 listener (enabled by default).
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true
# When `enabled` is false, the proxy no-ops and does not bind listeners.
# When true, respect HTTP(S)_PROXY/ALL_PROXY for upstream requests (HTTP(S) proxies only),
# including CONNECT tunnels in full mode.
allow_upstream_proxy = true
# By default, non-loopback binds are clamped to loopback for safety.
# If you want to expose these listeners beyond localhost, you must opt in explicitly.
dangerously_allow_non_loopback_proxy = false
mode = "full" # default when unset; use "limited" for read-only mode
# When true, HTTPS CONNECT can be terminated so limited-mode method policy still applies.
mitm = false
# CA cert/key are managed internally under $CODEX_HOME/proxy/ (ca.pem + ca.key).

# Hosts must match the allowlist (unless denied).
# Use exact hosts or scoped wildcards like `*.openai.com` or `**.openai.com`.
# The global `*` wildcard is rejected.
# If `allowed_domains` is empty, the proxy blocks requests until an allowlist is configured.
allowed_domains = ["*.openai.com", "localhost", "127.0.0.1", "::1"]
denied_domains = ["evil.example"]

# If false, local/private networking is rejected. Explicit allowlisting of local IP literals
# (or `localhost`) is required to permit them.
# Hostnames that resolve to local/private IPs are still blocked even if allowlisted.
allow_local_binding = false

# macOS-only: allows proxying to a unix socket when request includes `x-unix-socket: /path`.
allow_unix_sockets = ["/tmp/example.sock"]
# DANGEROUS (macOS-only): bypasses unix socket allowlisting and permits any
# absolute socket path from `x-unix-socket`.
dangerously_allow_all_unix_sockets = false

2) Run the proxy

cargo run -p codex-network-proxy --

3) Point a client at it

For HTTP(S) traffic:

export HTTP_PROXY="http://127.0.0.1:3128"
export HTTPS_PROXY="http://127.0.0.1:3128"
export WS_PROXY="http://127.0.0.1:3128"
export WSS_PROXY="http://127.0.0.1:3128"

For SOCKS5 traffic (when enable_socks5 = true):

export ALL_PROXY="socks5h://127.0.0.1:8081"

4) Understand blocks / debugging

When a request is blocked, the proxy responds with 403 and includes:

  • x-proxy-error: one of:
    • blocked-by-allowlist
    • blocked-by-denylist
    • blocked-by-method-policy
    • blocked-by-policy

In "limited" mode, only GET, HEAD, and OPTIONS are allowed. HTTPS CONNECT requests require MITM to enforce limited-mode method policy; otherwise they are blocked. SOCKS5 remains blocked in limited mode.

Websocket clients typically tunnel wss:// through HTTPS CONNECT; those CONNECT targets still go through the same host allowlist/denylist checks.

Library API

codex-network-proxy can be embedded as a library with a thin API:

use codex_network_proxy::{NetworkProxy, NetworkDecision, NetworkPolicyRequest};

let proxy = NetworkProxy::builder()
    .http_addr("127.0.0.1:8080".parse()?)
    .policy_decider(|request: NetworkPolicyRequest| async move {
        // Example: auto-allow when exec policy already approved a command prefix.
        if let Some(command) = request.command.as_deref() {
            if command.starts_with("curl ") {
                return NetworkDecision::Allow;
            }
        }
        NetworkDecision::Deny {
            reason: "policy_denied".to_string(),
        }
    })
    .build()
    .await?;

let handle = proxy.run().await?;
handle.shutdown().await?;

When unix socket proxying is enabled (allow_unix_sockets or dangerously_allow_all_unix_sockets), proxy bind overrides are still clamped to loopback to avoid turning the proxy into a remote bridge to local daemons.

Policy hook (exec-policy mapping)

The proxy exposes a policy hook (NetworkPolicyDecider) that can override allowlist-only blocks. It receives command and exec_policy_hint fields when supplied by the embedding app. This lets core map exec approvals to network access, e.g. if a user already approved curl * for a session, the decider can auto-allow network requests originating from that command.

Important: Explicit deny rules still win. The decider only gets a chance to override not_allowed (allowlist misses), not denied or not_allowed_local.

OTEL Audit Events (embedded/managed)

When codex-network-proxy is embedded in managed Codex runtime, policy decisions emit structured OTEL-compatible events with target=codex_otel.network_proxy.

Event name:

  • codex.network_proxy.policy_decision
    • emitted for each policy decision (domain and non_domain).
    • network.policy.scope = "domain" for host-policy evaluations (evaluate_host_policy).
    • network.policy.scope = "non_domain" for mode-guard/proxy-state checks (including unix-socket guard paths and unix-socket allow decisions).

Common fields:

  • event.name
  • event.timestamp (RFC3339 UTC, millisecond precision)
  • optional metadata:
    • conversation.id
    • app.version
    • user.account_id
  • policy/network:
    • network.policy.scope (domain or non_domain)
    • network.policy.decision (allow, deny, or ask)
    • network.policy.source (baseline_policy, mode_guard, proxy_state, decider)
    • network.policy.reason
    • network.transport.protocol
    • server.address
    • server.port
    • http.request.method (defaults to "none" when absent)
    • client.address (defaults to "unknown" when absent)
    • network.policy.override (true only when decider-allow overrides baseline not_allowed)

Unix-socket block-path audits use sentinel endpoint values:

  • server.address = "unix-socket"
  • server.port = 0

Audit events intentionally avoid logging full URL/path/query data.

Platform notes

  • Unix socket proxying via the x-unix-socket header is macOS-only; other platforms will reject unix socket requests.
  • HTTPS tunneling uses rustls via Rama's rama-tls-rustls; this avoids BoringSSL/OpenSSL symbol collisions in mixed TLS dependency graphs.

Security notes (important)

This section documents the protections implemented by codex-network-proxy, and the boundaries of what it can reasonably guarantee.

  • Allowlist-first policy: if allowed_domains is empty, requests are blocked until an allowlist is configured.

  • Domain patterns: exact hosts plus scoped wildcards (*.example.com, **.example.com) are supported; the global * wildcard is rejected.

  • Deny wins: entries in denied_domains always override the allowlist.

  • Local/private network protection: when allow_local_binding = false, the proxy blocks loopback and common private/link-local ranges. Explicit allowlisting of local IP literals (or localhost) is required to permit them; hostnames that resolve to local/private IPs are still blocked even if allowlisted (best-effort DNS lookup).

  • Limited mode enforcement:

    • only GET, HEAD, and OPTIONS are allowed
    • HTTPS CONNECT remains a tunnel; limited-mode method enforcement does not apply to HTTPS
  • Listener safety defaults:

    • the HTTP proxy listener clamps non-loopback binds unless explicitly enabled via dangerously_allow_non_loopback_proxy
  • when unix socket proxying is enabled, all proxy listeners are forced to loopback to avoid turning the proxy into a remote bridge into local daemons.

  • dangerously_allow_all_unix_sockets = true bypasses the unix socket allowlist entirely (still macOS-only and absolute-path-only). Use only in tightly controlled environments.

  • enabled is enforced at runtime; when false the proxy no-ops and does not bind listeners. Limitations:

  • DNS rebinding is hard to fully prevent without pinning the resolved IP(s) all the way down to the transport layer. If your threat model includes hostile DNS, enforce network egress at a lower layer too (e.g., firewall / VPC / corporate proxy policies).