67 Commits

• feat(network-proxy): experimental local credential broker (#28034)

  ## Why
  
  Codex child processes can inherit injectable local credentials directly,
  which lets commands read and exfiltrate the real values. This
  experimental slice keeps supported workflows working while moving those
  credentials behind the managed network proxy.
  
  This PR contains only the proxy-owned broker implementation. The Codex
  config and runtime integration is stacked separately in #29752.
  
  ## What changed
  
  - discover supported credentials during child setup, retain real values
  only in the in-memory proxy broker, and replace them with shaped dummy
  values
  - require a presented dummy to select a stored credential and preserve
  unrelated explicit authorization headers
  - bind GitHub cloud, GitHub Enterprise, and OpenAI credentials to their
  intended hosts
  - inject credentials only into TLS traffic by default; plaintext
  injection requires the explicit dangerous opt-in
  - use TLS ClientHello routing for CONNECT so non-TLS protocols remain
  opaque tunnels
  - expose a pure API that identifies environment keys still holding
  broker-generated dummies without mutating the caller's environment
  
  ## Scope
  
  - supported credentials: `GH_TOKEN`, `GITHUB_TOKEN`,
  `GH_ENTERPRISE_TOKEN`, `GITHUB_ENTERPRISE_TOKEN`, and `OPENAI_API_KEY`
  - GitHub cloud credentials match `github.com`, `api.github.com`, and
  `*.ghe.com`
  - GitHub Enterprise credentials match only the normalized non-cloud
  `GH_HOST`
  - OpenAI API keys match only `api.openai.com`
  - this does not cover SSH agents, kube client certificates, filesystem
  secret discovery, or context-injected secret scrubbing
  
  ## Validation
  
  - `just test -p codex-network-proxy` (191 passed)
  - focused opaque CONNECT, plaintext opt-in, dummy-selection, and
  child-isolation regressions passed
  - scoped Clippy check for `codex-network-proxy` passed
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Winston Howes · 2026-06-24 13:21:16 -07:00
  989f55defa
• Keep managed MITM CA private keys in proxy memory (#29013)

  ## Why
  
  The managed MITM trust bundle must be readable by sandboxed commands.
  Persisting its sibling CA private key under `$CODEX_HOME/proxy`
  therefore requires a deny-read sandbox rule, but the Windows unelevated
  backend rejects deny-read paths and WSL1's legacy Landlock path cannot
  enforce that rule.
  
  A persistent OS credential store also does not provide the same
  cross-platform boundary from other processes running as the same user.
  Keeping the signer inside the network proxy process avoids both
  problems: ordinary sandbox setup stays independent of CA-key state, and
  no private signing key is exposed through the filesystem or a persistent
  credential record.
  
  ## What
  
  - generate one managed CA per proxy process and retain its private
  signer only in proxy memory
  - emit only content-addressed public CA certificates and trust bundles
  under `$CODEX_HOME/proxy`
  - hold a cross-process lease for each active public certificate and
  prune artifacts from inactive proxy processes
  - keep all CA ownership in `codex-network-proxy`; no `codex-core` or
  sandbox-policy changes
  - validate generated trust-bundle paths by their content hash
  - keep the public bundle readable by sandboxed commands on Windows,
  WSL1, macOS, and Linux
  
  The independent startup custom-CA follow-up is #29014.
  
  ## Validation
  
  - `CODEX_HOME=/private/tmp/codex-test-home-network-proxy just test -p
  codex-network-proxy` (179 tests)
  - `just bazel-lock-check`
  - `just fix -p codex-network-proxy`
  - `just fmt`
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Winston Howes · 2026-06-23 12:20:51 -07:00
  c5a9a95ab6
• Prepare managed network sandbox context (#29456)

  ## Why
  
  Managed network configures commands to use local HTTP and SOCKS proxies.
  For commands delegated to the exec server, the proxy environment and the
  sandbox policy were prepared separately. On macOS, that meant a command
  could receive `HTTPS_PROXY=http://127.0.0.1:43123` while Seatbelt still
  denied access to port `43123`.
  
  ## What changed
  
  `NetworkProxy` now prepares the command environment and sandbox context
  together from the same runtime snapshot:
  
  ```text
  Prepared managed network
  ├── command environment: HTTPS_PROXY=http://127.0.0.1:43123
  └── sandbox context: allow outbound to 127.0.0.1:43123
  ```
  
  That context travels with remote exec requests. The exec server
  preserves the managed proxy and CA environment, and macOS Seatbelt
  allows only the prepared loopback proxy ports without enabling broad
  network access or local binding.
  
  The protocol field is optional and the existing enforcement flag remains
  in place, preserving compatibility with callers that do not send the new
  context.

  jif · 2026-06-23 20:07:09 +01:00
  e476fc16ce
• Honor startup custom CA bundles with managed MITM (#29014)

  ## Why
  
  When Codex starts with a custom CA override such as
  `SSL_CERT_FILE=/path/to/corp-ca.pem codex`, `rustls-native-certs` treats
  that override as a replacement for the platform trust store. The managed
  proxy then rewrites child CA variables to its generated bundle, so the
  custom root or the ordinary platform roots can be lost. The proxy's
  upstream TLS connector must trust the same roots or private and
  corporate upstream certificates still fail after interception.
  
  ## What
  
  - load platform-native roots without consulting inherited CA override
  variables
  - append certificates from the existing curated startup CA file
  variables and `SSL_CERT_DIR`
  - share those platform and startup roots with the MITM upstream rustls
  connector
  - exclude the Codex managed MITM CA from upstream trust
  - normalize OpenSSL `TRUSTED CERTIFICATE` blocks while dropping trailing
  trust metadata
  - skip an inherited current Codex-managed bundle so nested launches do
  not duplicate it
  - append the Codex managed MITM CA to the child-facing bundle
  - copy certificate material only, so a private key or unrelated text
  colocated in a startup file is never exposed through the public bundle
  
  This is intentionally limited to CA paths present when Codex starts. It
  does not parse inline shell assignments or add per-command bundle
  materialization.
  
  This changes only `codex-network-proxy` and dependency metadata; it does
  not touch `codex-core` or sandbox orchestration.
  
  ## Validation
  
  - `just test -p codex-network-proxy`
  - includes an end-to-end upstream TLS test using a server trusted only
  by the startup custom CA
  - `just fix -p codex-network-proxy`
  - `just bazel-lock-check`

  Winston Howes · 2026-06-22 14:16:48 -07:00
  527ccb4a5d
• Scope network approvals by environment (#28899)

  Stacked on #28766.
  
  ## Why
  
  Network approvals are environment-scoped: allowing a host in one
  execution environment should not allow the same host in another
  environment.
  
  #28766 adds the inert IDs and constructor plumbing. This PR applies the
  behavior on top.
  
  ## What changed
  
  - Route managed network traffic through per-environment HTTP and SOCKS
  proxy listeners.
  - Stamp HTTP, HTTPS CONNECT, SOCKS TCP, and SOCKS UDP policy requests
  with the source environment at the proxy boundary.
  - Carry the selected execution environment through shell, unified exec,
  zsh-fork, and sandbox transform paths.
  - Include the environment in pending, approved-for-session, and
  denied-for-session network approval cache keys.
  - Include the environment in approval IDs and approval prompts.
  - Preserve legacy fallback for unattributed requests, but deny when
  active-call attribution is ambiguous.
  - Fail closed if an environment-specific proxy endpoint cannot be
  prepared.
  
  ## Validation
  
  - just fmt
  - CI will run tests and clippy

  jif · 2026-06-19 13:49:45 +02:00
  bd5d31b250
• Add network environment ID plumbing (#28766)

  ## Why
  
  Prepare network approval scoping to distinguish execution environments
  without changing behavior yet.
  
  ## What changed
  
  - Add optional environment IDs to network policy requests.
  - Add optional network environment IDs to exec and sandbox request
  structs.
  - Thread default None values through existing construction points.
  - Fix stale constructor call sites that caused the CI compile failures.
  
  ## Not included
  
  - Per-environment proxy listeners.
  - Network approval cache or prompt behavior changes.
  - Ambiguous request attribution handling.
  
  Those behavior changes moved to stacked follow-up #28899.
  
  ## Validation
  
  - just fmt
  - CI will run tests and clippy

  jif · 2026-06-18 14:09:38 +02:00
  0369b24d54
• [codex] Remove async_trait from first-party code (#27475)

  ## Why
  
  First-party async traits should expose their `Send` contracts explicitly
  without requiring `async_trait`. This completes the migration pattern
  established in #27303 and #27304.
  
  ## What changed
  
  - Replaced the remaining first-party `async_trait` traits with native
  return-position `impl Future + Send` where statically dispatched and
  explicit boxed `Send` futures where object safety is required.
  - Kept implementations behavior-preserving, outlining existing async
  bodies into inherent methods where that keeps the diff reviewable.
  - Removed all direct first-party `async-trait` dependencies and the
  workspace dependency declaration.
  - Added a cargo-deny policy that permits `async-trait` only through the
  remaining transitive wrapper crates.
  - Updated `rand` from 0.8.5 to 0.8.6 to resolve RUSTSEC-2026-0097 and
  keep the full cargo-deny check passing.
  
  ## Validation
  
  - `just test -p codex-exec-server`: 216 passed, 2 skipped.
  - `just test -p codex-model-provider`: 39 passed.
  - `just test -p codex-core` and `just test`: changed tests passed;
  remaining failures are environment-sensitive suites unrelated to this
  migration.
  - `cargo deny check`
  - `just fix`
  - `just fmt`
  - `cargo shear`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 18:16:39 -07:00
  5a56caf18c
• Add SOCKS5 TCP MITM coverage (#22685)

  ## Summary
  - reuse the MITM HTTPS serving path for raw SOCKS5 TCP streams
  - route limited-mode and hooked SOCKS5 TCP requests through MITM before
  dialing upstream
  - keep SOCKS5 UDP limited-mode behavior unchanged
  
  ## Validation
  - `just fmt`
  - `just test -p codex-network-proxy`
  - `just fix -p codex-network-proxy`
  - `git diff --check`

  Winston Howes · 2026-06-09 13:08:01 -07:00
  472619f9fc
• Wire managed MITM CA trust into child env (#22668)

  ## Stack
  1. Parent PR: #18240 uses named MITM permissions config.
  2. This PR wires managed MITM CA trust into spawned child processes.
  
  ## Why
  When Codex terminates HTTPS for limited mode or MITM hooks, child HTTPS
  clients need to trust Codex's managed MITM CA. Exporting proxy URLs
  alone is not enough, but blindly replacing user CA settings would be
  wrong: it can break custom enterprise/test roots, leak unreadable CA
  files into generated bundles, or make the child env disagree with its
  sandbox policy.
  
  ## Summary
  1. Build immutable managed CA bundles under `$CODEX_HOME/proxy` that
  include native roots, the managed MITM CA, and only inherited or
  command-scoped CA bundles the child is allowed to read.
  2. Export curated CA env vars alongside managed proxy env vars while
  preserving user CA override semantics, including nested Codex
  `SSL_CERT_FILE` precedence.
  3. Thread generated CA bundle paths into child sandbox readable roots,
  including debug sandbox execution, so the exported env vars work inside
  sandboxed commands.
  4. Remove only Codex-generated MITM CA bundle env when a child
  intentionally drops managed proxying for escalation or no-proxy retry.
  5. Document the managed CA bundle behavior and cover env injection,
  per-child bundle generation, sandbox readable roots, and no-proxy
  cleanup in tests.
  
  ## Validation
  1. Ran `just test -p codex-network-proxy`.
  2. Ran `just test -p codex-protocol`.
  3. Ran `just fix -p codex-network-proxy -p codex-protocol`.
  4. Tried focused `codex-core` validation, but the crate currently fails
  to compile in `core/tests/suite/guardian_review.rs` because an existing
  `Op::UserInput` initializer is missing `additional_context`.
  
  ---------
  
  Co-authored-by: Eva Wong <evawong@openai.com>

  Winston Howes · 2026-06-01 23:23:59 +00:00
  bca18cba40
• fix(config): use deny for Unix socket permissions (#24970)

  ## Why
  
  Unix socket permissions still accepted and displayed `"none"` while file
  permissions use the clearer `"deny"` spelling. This keeps network Unix
  socket policy vocabulary consistent with filesystem policy vocabulary.
  
  ## What changed
  
  - Replace the Unix socket permission variant and serialized spelling
  from `none` to `deny` across config, feature configuration, and network
  proxy types.
  - Update app-server v2 serialization, TUI debug output, focused tests,
  and generated schemas to expose `"deny"`.
  - Add coverage for denied Unix socket entries in managed requirements
  and profile overlay behavior.
  
  ## Security
  
  This is a vocabulary change for explicit Unix socket rejection, not a
  network access expansion. Denied entries continue to be omitted from the
  effective allowlist.
  
  ## Validation
  
  - `just fmt`
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just test -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-tui -E
  'test(network_requirements_are_preserved_as_constraints_with_source) |
  test(network_permission_containers_project_allowed_and_denied_entries) |
  test(network_toml_overlays_unix_socket_permissions_by_path) |
  test(permissions_profiles_resolve_extends_parent_first_with_child_overrides)
  | test(network_requirements_serializes_canonical_and_legacy_fields) |
  test(debug_config_output_formats_unix_socket_permissions)'`\n- Automatic
  `bench-smoke` follow-up from `just test`\n- `cargo clippy -p
  codex-config -p codex-core -p codex-features -p codex-network-proxy -p
  codex-app-server-protocol -p codex-app-server -p codex-tui --all-targets
  -- -D warnings`

  viyatb-oai · 2026-05-28 23:53:26 +00:00
  bf72be5927
• [codex] Enable Node env proxy for managed network proxy (#23905)

  ## Summary
  - set `NODE_USE_ENV_PROXY=1` when Codex applies managed network proxy
  environment overrides
  - keep the Node opt-in in the proxy environment key set used by
  shell/runtime env handling
  - cover the new env var in the focused network proxy env test
  
  ## Why
  Codex already sets HTTP proxy environment variables for child processes
  when the managed network proxy is active. Node's built-in network
  behavior needs the `NODE_USE_ENV_PROXY` opt-in to honor those env vars,
  so Node-based skill scripts can otherwise skip the managed proxy path
  and fail under restricted network access.
  
  ## Validation
  - `just fmt` in `codex-rs`
  - `cargo test -p codex-network-proxy` in `codex-rs`

  rreichel3-oai · 2026-05-22 01:27:25 -04:00
  b14f11d3d2
• Use named MITM permissions config (#18240)

  ## Stack
  1. Parent PR: #18868 adds MITM hook config and model only.
  2. Parent PR: #20659 wires hook enforcement into the proxy request path.
  3. This PR changes the user facing PermissionProfile TOML shape.
  
  ## Why
  1. The broader goal is to make MITM clamping usable from the same
  permission profile that already controls network behavior.
  2. This PR is the config UX layer for the stack. It moves MITM policy
  into `[permissions.<profile>.network.mitm]` instead of exposing the flat
  runtime shape to users.
  3. The named hook and action tables belong here because users need
  reusable policy blocks that are easy to review, while the proxy runtime
  only needs a flat hook list.
  4. This PR validates action refs during config parsing so mistakes in
  the user facing policy fail before a proxy session starts.
  5. Keeping the lowering here lets the proxy keep its simpler runtime
  model and lets PermissionProfile remain the single source of network
  permission policy.
  
  ## Summary
  1. Keep MITM policy inside `[permissions.<profile>.network.mitm]` so the
  selected PermissionProfile owns network proxy policy.
  2. Use named MITM hooks under
  `[permissions.<profile>.network.mitm.hooks.<name>]`.
  3. Put host, methods, path prefixes, query, headers, body, and action
  refs on the hook table.
  4. Define reusable action blocks under
  `[permissions.<profile>.network.mitm.actions.<name>]`.
  5. Represent action blocks with `NetworkMitmActionToml`, then lower them
  into the proxy runtime action config.
  6. Reject unknown refs, empty refs, and empty action blocks during
  config parsing.
  7. Keep the runtime hook model unchanged by lowering config into the
  existing proxy hook list.
  8. Preserve the #20659 activation fix for nested MITM policy.
  
  ## Example
  ```toml
  [permissions.workspace.network.mitm]
  enabled = true
  
  [permissions.workspace.network.mitm.hooks.github_write]
  host = "api.github.com"
  methods = ["POST", "PUT"]
  path_prefixes = ["/repos/openai/"]
  action = ["strip_auth"]
  
  [permissions.workspace.network.mitm.actions.strip_auth]
  strip_request_headers = ["authorization"]
  ```
  
  ## Validation
  1. Regenerated the config schema.
  2. Ran the core MITM config parsing and validation tests.
  3. Ran the core PermissionProfile MITM proxy activation tests.
  4. Ran the core config schema fixture test.
  5. Ran the network proxy MITM policy tests.
  6. Ran the scoped Clippy fixer for the network proxy crate.
  7. Ran the scoped Clippy fixer for the core crate.
  
  ---------
  
  Co-authored-by: Winston Howes <winston@openai.com>

  evawong-oai · 2026-05-20 17:10:37 -07:00
  3cae84009a
• Wire MITM hooks into runtime enforcement (#20659)

  ## Stack
  1. Parent PR: #18868 adds MITM hook config and model only.
  2. This PR wires runtime enforcement.
  3. User facing config follow up: #18240 moves MITM policy into the
  PermissionProfile network tree.
  
  ## Why
  1. After the hook model exists, the proxy needs a separate behavior
  change that can be tested at the request path.
  2. This PR makes hooked HTTPS hosts require MITM, evaluates inner
  requests after CONNECT, mutates headers for matching hooks, and blocks
  hooked hosts when no hook matches.
  3. It also fixes the activation path so a permission profile with MITM
  hook policy starts the managed proxy.
  4. Keeping this separate from #18868 lets reviewers focus on runtime
  effects, telemetry, and request mutation.
  
  ## Summary
  1. Store compiled MITM hooks in network proxy state.
  2. Require MITM for hooked hosts even when network mode is full.
  3. Evaluate inner HTTPS requests against host specific hooks.
  4. Apply hook actions by replacing request headers before forwarding.
  5. Block hooked hosts when no hook matches and record block telemetry.
  6. Treat profile MITM hook policy as managed proxy policy so the proxy
  starts when needed.
  7. Keep the duplicate authorization header replacement and query
  preserving request rebuild in this runtime PR.
  8. Add runtime tests and README guidance for hook enforcement.
  
  ## Validation
  1. Ran the network proxy MITM policy tests.
  2. Ran the hooked host CONNECT test.
  3. Ran the authorization header replacement test.
  4. Ran the core permission profile proxy activation test for MITM hooks.
  5. Ran the scoped Clippy fixer for the network proxy crate.
  6. Ran the scoped Clippy fixer for the core crate.

  evawong-oai · 2026-05-20 14:08:14 -07:00
  f6970214d2
• Add MITM hook config model (#18868)

  ## Stack
  1. This PR adds MITM hook config and model only.
  2. Runtime follow up: #20659 wires hook enforcement into the proxy
  request path.
  3. User facing config follow up: #18240 moves MITM policy into the
  PermissionProfile network tree.
  
  ## Why
  1. Viyat asked for the original parent PR to be split so reviewers can
  inspect the policy model before request behavior changes.
  2. This PR gives the proxy a typed MITM hook model, validation, matcher
  compilation, permissions TOML plumbing, schema support, and config
  tests.
  3. This PR deliberately does not change CONNECT or MITM request
  handling.
  4. Keeping runtime behavior out of this PR makes the review boundary
  simple: does the policy model parse, validate, compile, and lower
  correctly.
  
  ## Summary
  1. Add the MITM hook config model and matcher compilation.
  2. Validate hosts, methods, paths, query matchers, header matchers,
  secret sources, and reserved body matching.
  3. Add wildcard matcher support for path, query value, and header value
  matching.
  4. Add permissions TOML and schema support for flat runtime hook config.
  5. Add config loader tests for MITM hook overlay behavior.
  
  ## Validation
  1. Regenerated the config schema.
  2. Ran the network proxy MITM hook unit tests.
  3. Ran the core permission profile MITM hook parsing tests.
  4. Ran the core config schema fixture test.
  5. Ran the scoped Clippy fixer for the network proxy crate.
  6. Ran the scoped Clippy fixer for the core crate.
  
  ## Notes
  1. Runtime enforcement moved to #20659.
  2. User facing PermissionProfile TOML shape remains in #18240.

  evawong-oai · 2026-05-20 12:51:12 -07:00
  3d94e24a3d
• Disable empty Cargo test targets (#21584)

  ## Summary
  
  `cargo test` has entails both running standard Rust tests and doctests.
  It turns out that the doctest discovery is fairly slow, and it's a cost
  you pay even for crates that don't include any doctests.
  
  This PR disables doctests with `doctest = false` for crates that lack
  any doctests.
  
  For the collection of crates below, this speeds up test execution by
  >4x.
  
  E.g., before this PR:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):      1.849 s ±  4.455 s    [User: 0.752 s, System: 1.367 s]
    Range (min … max):    0.418 s … 14.529 s    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):     428.6 ms ±   6.9 ms    [User: 187.7 ms, System: 219.7 ms]
    Range (min … max):   418.0 ms … 436.8 ms    10 runs
  ```
  
  For a single crate, with >2x speedup, before:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     491.1 ms ±   9.0 ms    [User: 229.8 ms, System: 234.9 ms]
    Range (min … max):   480.9 ms … 512.0 ms    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     213.9 ms ±   4.3 ms    [User: 112.8 ms, System: 84.0 ms]
    Range (min … max):   206.8 ms … 221.0 ms    13 runs
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-07 15:44:17 -07:00
  54ef99a365
• chore: add minimal proxy egress diagnostics (#21220)

  ## Why
  Recent Auto Review reports show Git traffic hanging through the local
  proxy on both SSH and HTTPS paths. Today the support bundle does not
  make it obvious whether a request is stuck before upstream dialing,
  during the proxy hop, or after the upstream response begins, which slows
  down root-cause triage.
  
  This adds a small amount of runtime visibility at the existing proxy
  boundaries without changing routing or policy behavior.
  
  ## What changed
  - log whether HTTP and CONNECT traffic take the direct or upstream-proxy
  route
  - log start / success / failure timings for CONNECT, HTTP, and SOCKS5
  upstream dials
  - log CONNECT forwarding lifecycle events
  - describe HTTP success at the response-header boundary that is actually
  observed, rather than implying the full body finished
  
  ## Verification
  - `cargo test -p codex-network-proxy`
  - `cargo clippy -p codex-network-proxy --all-targets -- -D warnings`

  viyatb-oai · 2026-05-05 17:50:59 +00:00
  172303bbfa
• [network-proxy] Cover DNS timeout blocking (#21105)

  ## Summary
  - Add a testable DNS lookup helper for the local or private host
  precheck while preserving production `lookup_host` behavior.
  - Add deterministic coverage for DNS timeout, lookup error, private
  resolution, and public resolution decisions.
  - Keep BUGB 15982 guarded without relying on ambient DNS timing or
  resolver behavior.
  
  ## Why
  BUGB 15982 was fixed by failing closed on DNS lookup errors and
  timeouts. The existing regression covered lookup failure through real
  DNS, but did not deterministically exercise the timeout branch. This PR
  adds a small injection point so CI can cover that branch without
  standing up slow authoritative DNS.
  
  ## Validation
  - `cargo test -p codex-network-proxy host_resolves_to_non_public_ip --
  --nocapture`
  - `cargo test -p codex-network-proxy
  host_blocked_rejects_allowlisted_hostname_when_dns_lookup_fails --
  --nocapture`
  - `cargo test -p codex-network-proxy`
  - `just fmt`
  - `just fix -p codex-network-proxy`
  - `git diff --check`
  
  ## Tickets
  - BUGB 15982
  -
  https://linear.app/openai/issue/BUGB-15982/codex-dns-timeout-fail-open-in-codex-network-proxy-bypasses
  - Bugcrowd:
  https://tracker.bugcrowd.com/openai/submissions/b2bf131d-db04-478f-85aa-cdd17ca8f604

  evawong-oai · 2026-05-04 19:03:56 -07:00
  d85783901c
• fix(network-proxy): normalize network proxy host matching (#19995)

  ## Why
  The proxy matches allow and deny rules against normalized host strings.
  Scoped IPv6 literals can arrive in equivalent forms, such as
  `fd00::1%eth0`, `[fd00::1%eth0]`, or `[fd00::1%25eth0]`. Policy should
  canonicalize those spellings without erasing scope granularity: an
  unscoped rule like `fd00::1` should still cover scoped requests for that
  address, while a scoped rule like `fd00::1%eth0` should remain exact to
  that scope.
  
  ## What changed
  - preserve IPv6 scope IDs during host normalization and canonicalize
  `%25scope` to `%scope`
  - match policy against the exact normalized host plus the unscoped IP
  base for scoped literals
  - keep local-address explicit allow checks aligned with the same
  scoped/unscoped semantics
  - add focused coverage for scoped IPv6 normalization, scoped allow
  rules, and scoped deny rules in `network-proxy`
  
  ## Security impact
  A request cannot bypass a broad deny rule by adding an IPv6 scope
  suffix. At the same time, scoped policy remains precise:
  `deny=fd00::1%eth0` affects that scoped spelling without collapsing
  `fd00::1%eth1` onto the same key, and `allow=fe80::1%eth0` does not
  implicitly allow other scopes.
  
  ## Verification
  - `just fmt`
  - `cargo test -p codex-network-proxy`
  - `just fix -p codex-network-proxy`
  - `git diff --check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: evawong-oai <evawong@openai.com>

  viyatb-oai · 2026-04-28 15:50:00 -07:00
  2dbde94aa9
• fix(network-proxy): recheck network proxy connect targets (#19999)

  ## Why
  The proxy checks the requested host before opening the upstream
  connection, but DNS can resolve an allowed hostname to a loopback,
  private, or other non-public address after that first decision. Without
  a final check on the actual socket target, a request that looks
  acceptable at the hostname layer can still connect to a local service
  once resolution completes.
  
  ## What changed
  - add a shared TCP connector check for direct proxy egress
  - use that path for HTTP, `CONNECT`, SOCKS5, and MITM upstream
  connections
  - keep configured upstream proxy hops on the existing proxy path
  - add direct-connector coverage for allowed and rejected local targets
  
  ## Security impact
  Direct proxy egress now rechecks the resolved socket address before
  connecting, closing the gap between hostname policy evaluation and the
  final network target.
  
  ## Verification
  - `cargo test -p codex-network-proxy`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-28 12:51:43 -07:00
  e1ba87ccb2
• fix(network-proxy): tighten network proxy bypass defaults (#20002)

  ## Why
  Managed sessions use `NO_PROXY` to keep a small set of destinations on
  the direct path by default. The old default also bypassed all IPv4
  link-local addresses in `169.254.0.0/16`, which includes metadata
  endpoints such as `169.254.169.254`. Because `NO_PROXY` is evaluated by
  the client before the request reaches the managed proxy, requests to
  that range could skip proxy-side allowlist and local-binding checks
  entirely. On hosts where a link-local metadata service is reachable,
  that creates a path to sensitive environment metadata or credentials
  outside the intended enforcement point.
  
  ## What changed
  - remove the default IPv4 link-local `169.254.0.0/16` bypass from the
  managed proxy environment
  - keep the existing loopback and private-network defaults unchanged
  - update the regression assertion to lock in the narrower default
  
  ## Security impact
  Link-local requests now stay on the managed-proxy path by default, so
  the proxy can apply configured policy before they reach metadata-style
  endpoints or other link-local services.
  
  ## Verification
  - `cargo test -p codex-network-proxy`
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-28 10:51:43 -07:00
  3afb185a4f
• refactor: narrow async lock scopes (#18418)

  ## Why
  
  This is part of the follow-up work from #18178 to make Codex ready for
  Clippy's
  [`await_holding_lock`](https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_lock)
  /
  [`await_holding_invalid_type`](https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_invalid_type)
  lints.
  
  This bottom PR keeps the scope intentionally small:
  `NetworkProxyState::record_blocked()` only needs the state write lock
  while it mutates the blocked-request ring buffer and counters. The debug
  log payload and `BlockedRequestObserver` callback can be produced after
  that lock is released.
  
  ## What changed
  
  - Copies the blocked-request snapshot values needed for logging while
  updating the state.
  - Releases the `RwLockWriteGuard` before logging or notifying the
  observer.
  
  ## Verification
  
  - `cargo test -p codex-network-proxy`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18418).
  * #18698
  * #18423
  * __->__ #18418

  Michael Bolin · 2026-04-21 02:23:30 +00:00
  ff05532723
• fix: fix stale proxy env restoration after shell snapshots (#17271)

  ## Summary
  
  This fixes a stale-environment path in shell snapshot restoration. A
  sandboxed command can source a shell snapshot that was captured while an
  older proxy process was running. If that proxy has died and come back on
  a different port, the snapshot can otherwise put old proxy values back
  into the command environment, which is how tools like `pip` end up
  talking to a dead proxy.
  
  The wrapper now captures the live process environment before sourcing
  the snapshot and then restores or clears every proxy env var from the
  proxy crate's canonical list. That makes proxy state after shell
  snapshot restoration match the current command environment, rather than
  whatever proxy values happened to be present in the snapshot. On macOS,
  the Codex-generated `GIT_SSH_COMMAND` is refreshed when the SOCKS
  listener changes, while custom SSH wrappers are still left alone.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-20 16:39:17 -07:00
  33fa952426
• Use AbsolutePathBuf in skill loading and codex_home (#17407)

  Helps with FS migration later

  pakrym-oai · 2026-04-13 10:26:51 -07:00
  ac82443d07
• fix: unblock private DNS in macOS sandbox (#17370)

  ## Summary
  - keep hostname targets proxied by default by removing hostname suffixes
  from the managed `NO_PROXY` value while preserving private/link-local
  CIDRs
  - make the macOS `allow_local_binding` sandbox rules match the local
  socket shape used by DNS tools by allowing wildcard local binds
  - allow raw DNS egress to remote port 53 only when `allow_local_binding`
  is enabled, without opening blanket outbound network access
  
  ## Root cause
  Raw DNS tools do not honor `HTTP_PROXY` or `ALL_PROXY`, so the
  proxy-only Seatbelt policy blocked their resolver traffic before it
  could reach host DNS. In the affected managed config,
  `allow_local_binding = true`, but the existing rule only allowed
  `localhost:*` binds; `dig`/BIND can bind sockets in a way that needs
  wildcard local binding. Separately, hostname suffixes in `NO_PROXY`
  could force internal hostnames to resolve locally instead of through the
  proxy path.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-10 20:34:04 -07:00
  8a474a6561
• refactor(proxy): clarify sandbox block messages (#17168)

  ## Summary
  - Replace Codex-branded network-proxy block responses with concise
  reason text
  - Mention sandbox policy for local/private network and deny-policy
  wording
  - Remove “managed” from the proxy-disabled denial detail

  viyatb-oai · 2026-04-09 10:53:06 -07:00
  7ab825e047
• fix: refresh network proxy settings when sandbox mode changes (#17040)

  ## Summary
  
  Fix network proxy sessions so changing sandbox mode recomputes the
  effective managed network policy and applies it to the already-running
  per-session proxy.
  
  ## Root Cause
  
  `danger_full_access_denylist_only` injects `"*"` only while building the
  proxy spec for Full Access. Sessions built that spec once at startup, so
  a later permission switch to Full Access left the live proxy in its
  original restricted policy. Switching back needed the same recompute
  path to remove the synthetic wildcard again.
  
  ## What Changed
  
  - Preserve the original managed network proxy config/requirements so the
  effective spec can be recomputed for a new sandbox policy.
  - Refresh the current session proxy when sandbox settings change, then
  reapply exec-policy network overlays.
  - Add an in-place proxy state update path while rejecting
  listener/port/SOCKS changes that cannot be hot-reloaded.
  - Keep runtime proxy settings cheap to snapshot and update.
  - Add regression coverage for workspace-write -> Full Access ->
  workspace-write.

  viyatb-oai · 2026-04-08 03:07:55 +00:00
  3c1adbabcd
• ci: verify codex-rs Cargo manifests inherit workspace settings (#16353)

  ## Why
  
  Bazel clippy now catches lints that `cargo clippy` can still miss when a
  crate under `codex-rs` forgets to opt into workspace lints. The concrete
  example here was `codex-rs/app-server/tests/common/Cargo.toml`: Bazel
  flagged a clippy violation in `models_cache.rs`, but Cargo did not
  because that crate inherited workspace package metadata without
  declaring `[lints] workspace = true`.
  
  We already mirror the workspace clippy deny list into Bazel after
  [#15955](https://github.com/openai/codex/pull/15955), so we also need a
  repo-side check that keeps every `codex-rs` manifest opted into the same
  workspace settings.
  
  ## What changed
  
  - add `.github/scripts/verify_cargo_workspace_manifests.py`, which
  parses every `codex-rs/**/Cargo.toml` with `tomllib` and verifies:
    - `version.workspace = true`
    - `edition.workspace = true`
    - `license.workspace = true`
    - `[lints] workspace = true`
  - top-level crate names follow the `codex-*` / `codex-utils-*`
  conventions, with explicit exceptions for `windows-sandbox-rs` and
  `utils/path-utils`
  - run that script in `.github/workflows/ci.yml`
  - update the current outlier manifests so the check is enforceable
  immediately
  - fix the newly exposed clippy violations in the affected crates
  (`app-server/tests/common`, `file-search`, `feedback`,
  `shell-escalation`, and `debug-client`)
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16353).
  * #16351
  * __->__ #16353

  Michael Bolin · 2026-03-31 21:59:28 +00:00
  9a8730f31e
• fix: clean up remaining Windows argument-comment-lint violations (#16071)

  ## Why
  
  The initial `argument-comment-lint` rollout left Windows on
  default-target coverage because there were still Windows-only callsites
  failing under `--all-targets`. This follow-up cleans up those remaining
  Windows-specific violations so the Windows CI lane can enforce the same
  stricter coverage, leaving Linux as the remaining platform-specific
  follow-up.
  
  ## What changed
  
  - switched the Windows `rust-ci` argument-comment-lint step back to the
  default wrapper invocation so it runs full-target coverage again
  - added the required `/*param_name*/` annotations at Windows-gated
  literal callsites in:
    - `codex-rs/windows-sandbox-rs/src/lib.rs`
    - `codex-rs/windows-sandbox-rs/src/elevated_impl.rs`
    - `codex-rs/tui_app_server/src/multi_agents.rs`
    - `codex-rs/network-proxy/src/proxy.rs`
  
  ## Validation
  
  - Windows `argument comment lint` CI on this PR

  Michael Bolin · 2026-03-27 20:48:21 -07:00
  e02fd6e1d3
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• chore: refactor network permissions to use explicit domain and unix socket rule maps (#15120)

  ## Summary
  
  This PR replaces the legacy network allow/deny list model with explicit
  rule maps for domains and unix sockets across managed requirements,
  permissions profiles, the network proxy config, and the app server
  protocol.
  
  Concretely, it:
  
  - introduces typed domain (`allow` / `deny`) and unix socket permission
  (`allow` / `none`) entries instead of separate `allowed_domains`,
  `denied_domains`, and `allow_unix_sockets` lists
  - updates config loading, managed requirements merging, and exec-policy
  overlays to read and upsert rule entries consistently
  - exposes the new shape through protocol/schema outputs, debug surfaces,
  and app-server config APIs
  - rejects the legacy list-based keys and updates docs/tests to reflect
  the new config format
  
  ## Why
  
  The previous representation split related network policy across multiple
  parallel lists, which made merging and overriding rules harder to reason
  about. Moving to explicit keyed permission maps gives us a single source
  of truth per host/socket entry, makes allow/deny precedence clearer, and
  gives protocol consumers access to the full rule state instead of
  derived projections only.
  
  ## Backward Compatibility
  
  ### Backward compatible
  
  - Managed requirements still accept the legacy
  `experimental_network.allowed_domains`,
  `experimental_network.denied_domains`, and
  `experimental_network.allow_unix_sockets` fields. They are normalized
  into the new canonical `domains` and `unix_sockets` maps internally.
  - App-server v2 still deserializes legacy `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` payloads, so older clients can
  continue reading managed network requirements.
  - App-server v2 responses still populate `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` as legacy compatibility views
  derived from the canonical maps.
  - `managed_allowed_domains_only` keeps the same behavior after
  normalization. Legacy managed allowlists still participate in the same
  enforcement path as canonical `domains` entries.
  
  ### Not backward compatible
  
  - Permissions profiles under `[permissions.<profile>.network]` no longer
  accept the legacy list-based keys. Those configs must use the canonical
  `[domains]` and `[unix_sockets]` tables instead of `allowed_domains`,
  `denied_domains`, or `allow_unix_sockets`.
  - Managed `experimental_network` config cannot mix canonical and legacy
  forms in the same block. For example, `domains` cannot be combined with
  `allowed_domains` or `denied_domains`, and `unix_sockets` cannot be
  combined with `allow_unix_sockets`.
  - The canonical format can express explicit `"none"` entries for unix
  sockets, but those entries do not round-trip through the legacy
  compatibility fields because the legacy fields only represent allow/deny
  lists.
  ## Testing
  `/target/debug/codex sandbox macos --log-denials /bin/zsh -c 'curl
  https://www.example.com' ` gives 200 with config
  ```
  [permissions.workspace.network.domains]
  "www.example.com" = "allow"
  ```
  and fails when set to deny: `curl: (56) CONNECT tunnel failed, response
  403`.
  
  Also tested backward compatibility path by verifying that adding the
  following to `/etc/codex/requirements.toml` works:
  ```
  [experimental_network]
  allowed_domains = ["www.example.com"]
  ```

  Celia Chen · 2026-03-27 06:17:59 +00:00
  dd30c8eedd
• feat(windows-sandbox): add network proxy support (#12220)

  ## Summary
  
  This PR makes Windows sandbox proxying enforceable by routing proxy-only
  runs through the existing `offline` sandbox user and reserving direct
  network access for the existing `online` sandbox user.
  
  In brief:
  
  - if a Windows sandbox run should be proxy-enforced, we run it as the
  `offline` user
  - the `offline` user gets firewall rules that block direct outbound
  traffic and only permit the configured localhost proxy path
  - if a Windows sandbox run should have true direct network access, we
  run it as the `online` user
  - no new sandbox identity is introduced
  
  This brings Windows in line with the intended model: proxy use is not
  just env-based, it is backed by OS-level egress controls. Windows
  already has two sandbox identities:
  
  - `offline`: intended to have no direct network egress
  - `online`: intended to have full network access
  
  This PR makes proxy-enforced runs use that model directly.
  
  ### Proxy-enforced runs
  
  When proxy enforcement is active:
  
  - the run is assigned to the `offline` identity
  - setup extracts the loopback proxy ports from the sandbox env
  - Windows setup programs firewall rules for the `offline` user that:
    - block all non-loopback outbound traffic
    - block loopback UDP
    - block loopback TCP except for the configured proxy ports
  - optionally allow broader localhost access when `allow_local_binding=1`
  
  So the sandboxed process can only talk to the local proxy. It cannot
  open direct outbound sockets or do local UDP-based DNS on its own.The
  proxy then performs the real outbound network access outside that
  restricted sandbox identity.
  
  ### Direct-network runs
  
  When proxy enforcement is not active and full network access is allowed:
  
  - the run is assigned to the `online` identity
  - no proxy-only firewall restrictions are applied
  - the process gets normal direct network access
  
  ### Unelevated vs elevated
  
  The restricted-token / unelevated path cannot enforce per-identity
  firewall policy by itself.
  
  So for Windows proxy-enforced runs, we transparently use the logon-user
  sandbox path under the hood, even if the caller started from the
  unelevated mode. That keeps enforcement real instead of best-effort.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-03-26 17:27:38 -07:00
  81fa04783a
• fix(network-proxy): fail closed on network-proxy DNS lookup errors (#15909)

  ## Summary
  
  Fail closed when the network proxy's local/private IP pre-check hits a
  DNS lookup error or timeout, instead of treating the hostname as public
  and allowing the request.
  
  ## Root cause
  
  `host_resolves_to_non_public_ip()` returned `false` on resolver failure,
  which created a fail-open path in the `allow_local_binding = false`
  boundary. The eventual connect path performs its own DNS resolution
  later, so a transient pre-check failure is not evidence that the
  destination is public.
  
  ## Changes
  
  - Treat DNS lookup errors/timeouts as local/private for blocking
  purposes
  - Add a regression test for an allowlisted hostname that fails DNS
  resolution
  
  ## Validation
  
  - `cargo test -p codex-network-proxy`
  - `cargo clippy -p codex-network-proxy --all-targets -- -D warnings`
  - `just fmt`
  - `just argument-comment-lint`

  viyatb-oai · 2026-03-26 23:18:04 +00:00
  aea82c63ea
• Add wildcard in the middle test coverage (#15813)

  ## Summary
  Add a focused codex network proxy unit test for the denylist pattern
  with wildcard in the middle `region*.some.malicious.tunnel.com`. This
  does not change how existing code works, just ensure that behavior stays
  the same and we got CI guards to guard existin behavior.
  
  ## Why
  The managed Codex denylist update relies on this mid label glob form,
  and the existing tests only covered exact hosts, `*.` subdomains, and
  `**.` apex plus subdomains.
  
  ## Validation
  `cargo test -p codex-network-proxy
  compile_globset_supports_mid_label_wildcards`
  `cargo test -p codex-network-proxy`
  `./tools/argument-comment-lint/run-prebuilt-linter.sh -p
  codex-network-proxy`

  evawong-oai · 2026-03-26 17:53:31 +00:00
  0bd34c28c7
• Allow global network allowlist wildcard (#15549)

  ## Problem
  
  Today `codex-network-proxy` rejects a global `*` in
  `network.allowed_domains`, so there is no static way to configure a
  denylist-only posture for public hosts. Users have to enumerate broad
  allowlist patterns instead.
  
  ## Approach
  
  - Make global wildcard acceptance field-specific: `allowed_domains` can
  use `*`, while `denied_domains` still rejects a global wildcard.
  - Keep the existing evaluation order, so explicit denies still win first
  and local/private protections still apply unless separately enabled.
  - Add coverage for the denylist-only behavior and update the README to
  document it.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-network-proxy` (full run had one unrelated flaky
  telemetry test:
  `network_policy::tests::emit_block_decision_audit_event_emits_non_domain_event`;
  reran in isolation and it passed)
  - `cargo test -p codex-network-proxy
  network_policy::tests::emit_block_decision_audit_event_emits_non_domain_event
  -- --exact --nocapture`
  - `just fix -p codex-network-proxy`
  - `just argument-comment-lint`

  rreichel3-oai · 2026-03-24 10:43:46 -04:00
  1db6cb9789
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• fix(network-proxy): serve HTTP proxy listener as HTTP/1 (#14395)

  ## Summary
  - switch the local HTTP proxy listener from Rama's auto server to
  explicit HTTP/1 so CONNECT clients skip the version-sniffing pre-read
  path
  - move rustls crypto-provider bootstrap into the HTTP proxy runner so
  direct callers do not need hidden global init
  - add a regression test that exercises a plain HTTP/1 CONNECT request
  against a live loopback listener

  viyatb-oai · 2026-03-11 14:35:44 -07:00
  5259e5e236
• 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>

  Charley Cunningham · 2026-03-07 05:40:10 -08:00
  e84ee33cc0
• fix: support managed network allowlist controls (#12752)

  ## Summary
  - treat `requirements.toml` `allowed_domains` and `denied_domains` as
  managed network baselines for the proxy
  - in restricted modes by default, build the effective runtime policy
  from the managed baseline plus user-configured allowlist and denylist
  entries, so common hosts can be pre-approved without blocking later user
  expansion
  - add `experimental_network.managed_allowed_domains_only = true` to pin
  the effective allowlist to managed entries, ignore user allowlist
  additions, and hard-deny non-managed domains without prompting
  - apply `managed_allowed_domains_only` anywhere managed network
  enforcement is active, including full access, while continuing to
  respect denied domains from all sources
  - add regression coverage for merged-baseline behavior, managed-only
  behavior, and full-access managed-only enforcement
  
  ## Behavior
  Assuming `requirements.toml` defines both
  `experimental_network.allowed_domains` and
  `experimental_network.denied_domains`.
  
  ### Default mode
  - By default, the effective allowlist is
  `experimental_network.allowed_domains` plus user or persisted allowlist
  additions.
  - By default, the effective denylist is
  `experimental_network.denied_domains` plus user or persisted denylist
  additions.
  - Allowlist misses can go through the network approval flow.
  - Explicit denylist hits and local or private-network blocks are still
  hard-denied.
  - When `experimental_network.managed_allowed_domains_only = true`, only
  managed `allowed_domains` are respected, user allowlist additions are
  ignored, and non-managed domains are hard-denied without prompting.
  - Denied domains continue to be respected from all sources.
  
  ### Full access
  - With managed requirements present, the effective allowlist is pinned
  to `experimental_network.allowed_domains`.
  - With managed requirements present, the effective denylist is pinned to
  `experimental_network.denied_domains`.
  - There is no allowlist-miss approval path in full access.
  - Explicit denylist hits are hard-denied.
  - `experimental_network.managed_allowed_domains_only = true` now also
  applies in full access, so managed-only behavior remains in effect
  anywhere managed network enforcement is active.

  viyatb-oai · 2026-03-06 17:52:54 -08:00
  25fa974166
• config: add initial support for the new permission profile config language in config.toml (#13434)

  ## Why
  
  `SandboxPolicy` currently mixes together three separate concerns:
  
  - parsing layered config from `config.toml`
  - representing filesystem sandbox state
  - carrying basic network policy alongside filesystem choices
  
  That makes the existing config awkward to extend and blocks the new TOML
  proposal where `[permissions]` becomes a table of named permission
  profiles selected by `default_permissions`. (The idea is that if
  `default_permissions` is not specified, we assume the user is opting
  into the "traditional" way to configure the sandbox.)
  
  This PR adds the config-side plumbing for those profiles while still
  projecting back to the legacy `SandboxPolicy` shape that the current
  macOS and Linux sandbox backends consume.
  
  It also tightens the filesystem profile model so scoped entries only
  exist for `:project_roots`, and so nested keys must stay within a
  project root instead of using `.` or `..` traversal.
  
  This drops support for the short-lived `[permissions.network]` in
  `config.toml` because now that would be interpreted as a profile named
  `network` within `[permissions]`.
  
  ## What Changed
  
  - added `PermissionsToml`, `PermissionProfileToml`,
  `FilesystemPermissionsToml`, and `FilesystemPermissionToml` so config
  can parse named profiles under `[permissions.<profile>.filesystem]`
  - added top-level `default_permissions` selection, validation for
  missing or unknown profiles, and compilation from a named profile into
  split `FileSystemSandboxPolicy` and `NetworkSandboxPolicy` values
  - taught config loading to choose between the legacy `sandbox_mode` path
  and the profile-based path without breaking legacy users
  - introduced `codex-protocol::permissions` for the split filesystem and
  network sandbox types, and stored those alongside the legacy projected
  `sandbox_policy` in runtime `Permissions`
  - modeled `FileSystemSpecialPath` so only `ProjectRoots` can carry a
  nested `subpath`, matching the intended config syntax instead of
  allowing invalid states for other special paths
  - restricted scoped filesystem maps to `:project_roots`, with validation
  that nested entries are non-empty descendant paths and cannot use `.` or
  `..` to escape the project root
  - kept existing runtime consumers working by projecting
  `FileSystemSandboxPolicy` back into `SandboxPolicy`, with an explicit
  error for profiles that request writes outside the workspace root
  - loaded proxy settings from top-level `[network]`
  - regenerated `core/config.schema.json`
  
  ## Verification
  
  - added config coverage for profile deserialization,
  `default_permissions` selection, top-level `[network]` loading, network
  enablement, rejection of writes outside the workspace root, rejection of
  nested entries for non-`:project_roots` special paths, and rejection of
  parent-directory traversal in `:project_roots` maps
  - added protocol coverage for the legacy bridge rejecting non-workspace
  writes
  
  ## Docs
  
  - update the Codex config docs on developers.openai.com/codex to
  document named `[permissions.<profile>]` entries, `default_permissions`,
  scoped `:project_roots` syntax, the descendant-path restriction for
  nested `:project_roots` entries, and top-level `[network]` proxy
  configuration
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13434).
  * #13453
  * #13452
  * #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * #13439
  * __->__ #13434

  Michael Bolin · 2026-03-06 15:39:13 -08:00
  f82678b2a4
• fix: reject global wildcard network proxy domains (#13789)

  ## Summary
  - reject the global `*` domain pattern in proxy allow/deny lists and
  managed constraints introduced for testing earlier
  - keep exact hosts plus scoped wildcards like `*.example.com` and
  `**.example.com`
  - update docs and regression tests for the new invalid-config behavior

  viyatb-oai · 2026-03-06 21:06:24 +00:00
  9a4787c240
• refactor: remove proxy admin endpoint (#13687)

  ## Summary
  - delete the network proxy admin server and its runtime listener/task
  plumbing
  - remove the admin endpoint config, runtime, requirement, protocol,
  schema, and debug-surface fields
  - update proxy docs to reflect the remaining HTTP and SOCKS listeners
  only

  viyatb-oai · 2026-03-05 22:03:16 -08:00
  6a79ed5920
• fix(network-proxy): reject mismatched host headers (#13275)

  ## Summary
  - reject plain HTTP absolute-form requests whose Host header does not
  match the request target authority
  - add host/port-aware Host header validation for non-default ports
  - add regression coverage for mismatched Host forwarding and validator
  edge cases

  viyatb-oai · 2026-03-03 15:12:06 -08:00
  24a2d0c696
• feat(network-proxy): add embedded OTEL policy audit logging (#12046)

  **PR Summary**
  
  This PR adds embedded-only OTEL policy audit logging for
  `codex-network-proxy` and threads audit metadata from `codex-core` into
  managed proxy startup.
  
  ### What changed
  - Added structured audit event emission in `network_policy.rs` with
  target `codex_otel.network_proxy`.
  - Emitted:
  - `codex.network_proxy.domain_policy_decision` once per domain-policy
  evaluation.
    - `codex.network_proxy.block_decision` for non-domain denies.
  - Added required policy/network fields, RFC3339 UTC millisecond
  `event.timestamp`, and fallback defaults (`http.request.method="none"`,
  `client.address="unknown"`).
  - Added non-domain deny audit emission in HTTP/SOCKS handlers for
  mode-guard and proxy-state denies, including unix-socket deny paths.
  - Added `REASON_UNIX_SOCKET_UNSUPPORTED` and used it for unsupported
  unix-socket auditing.
  - Added `NetworkProxyAuditMetadata` to runtime/state, re-exported from
  `lib.rs` and `state.rs`.
  - Added `start_proxy_with_audit_metadata(...)` in core config, with
  `start_proxy()` delegating to default metadata.
  - Wired metadata construction in `codex.rs` from session/auth context,
  including originator sanitization for OTEL-safe tagging.
  - Updated `network-proxy/README.md` with embedded-mode audit schema and
  behavior notes.
  - Refactored HTTP block-audit emission to a small local helper to reduce
  duplication.
  - Preserved existing unix-socket proxy-disabled host/path behavior for
  responses and blocked history while using an audit-only endpoint
  override (`server.address="unix-socket"`, `server.port=0`).
  
  ### Explicit exclusions
  - No standalone proxy OTEL startup work.
  - No `main.rs` binary wiring.
  - No `standalone_otel.rs`.
  - No standalone docs/tests.
  
  ### Tests
  - Extended `network_policy.rs` tests for event mapping, metadata
  propagation, fallbacks, timestamp format, and target prefix.
  - Extended HTTP tests to assert unix-socket deny block audit events.
  - Extended SOCKS tests to cover deny emission from handler deny
  branches.
  - Added/updated core tests to verify audit metadata threading into
  managed proxy state.
  
  ### Validation run
  - `just fmt`
  - `cargo test -p codex-network-proxy` ✅
  - `cargo test -p codex-core` ran with one unrelated flaky timeout
  (`shell_snapshot::tests::snapshot_shell_does_not_inherit_stdin`), and
  the test passed when rerun directly ✅
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  mcgrew-oai · 2026-02-25 11:46:37 -05:00
  9a393c9b6f
• feat(network-proxy): add MITM support and gate limited-mode CONNECT (#9859)

  ## Description
  - Adds MITM support (CA load/issue, TLS termination, optional body
  inspection).
  - Adds `codex-network-proxy init` to create
  `CODEX_HOME/network_proxy/mitm`.
  - Enforces limited-mode HTTPS correctly: `CONNECT` requires MITM,
  otherwise blocked with `mitm_required`.
  - Keeps `origin/main` layering/reload semantics (managed layers included
  in reload checks).
  - Centralizes block reasons (`REASON_MITM_REQUIRED`) and removes
  `println!`.
  - Scope is MITM-only (no SOCKS changes).
  
  gated by `mitm=false` (default)

  viyatb-oai · 2026-02-24 18:15:15 +00:00
  8d3d58f992
• feat(core): persist network approvals in execpolicy (#12357)

  ## Summary
  Persist network approval allow/deny decisions as `network_rule(...)`
  entries in execpolicy (not proxy config)
  
  It adds `network_rule` parsing + append support in `codex-execpolicy`,
  including `decision="prompt"` (parse-only; not compiled into proxy
  allow/deny lists)
  - compile execpolicy network rules into proxy allow/deny lists and
  update the live proxy state on approval
  - preserve requirements execpolicy `network_rule(...)` entries when
  merging with file-based execpolicy
  - reject broad wildcard hosts (for example `*`) for persisted
  `network_rule(...)`

  viyatb-oai · 2026-02-23 21:37:46 -08:00
  c3048ff90a
• fix(network-proxy): add unix socket allow-all and update seatbelt rules (#11368)

  ## Summary
  Adds support for a Unix socket escape hatch so we can bypass socket
  allowlisting when explicitly enabled.
  
  ## Description
  * added a new flag, `network.dangerously_allow_all_unix_sockets` as an
  explicit escape hatch
  * In codex-network-proxy, enabling that flag now allows any absolute
  Unix socket path from x-unix-socket instead of requiring each path to be
  explicitly allowlisted. Relative paths are still rejected.
  * updated the macOS seatbelt path in core so it enforces the same Unix
  socket behavior:
    * allowlisted sockets generate explicit network* subpath rules
    * allow-all generates a broad network* (subpath "/") rule
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-20 10:56:57 -08:00
  28c0089060
• Refactor network approvals to host/protocol/port scope (#12140)

  ## Summary
  Simplify network approvals by removing per-attempt proxy correlation and
  moving to session-level approval dedupe keyed by (host, protocol, port).
  Instead of encoding attempt IDs into proxy credentials/URLs, we now
  treat approvals as a destination policy decision.
  
  - Concurrent calls to the same destination share one approval prompt.
  - Different destinations (or same host on different ports) get separate
  prompts.
  - Allow once approves the current queued request group only.
  - Allow for session caches that (host, protocol, port) and auto-allows
  future matching requests.
  - Never policy continues to deny without prompting.
  
  Example:
  - 3 calls: 
    - a.com (line 443)
    - b.com (line 443)
    - a.com (line 443)
  => 2 prompts total (a, b), second a waits on the first decision.
  - a.com:80 is treated separately from a.com line 443
  
  ## Testing
  - `just fmt` (in `codex-rs`)
  - `cargo test -p codex-core tools::network_approval::tests`
  - `cargo test -p codex-core` (unit tests pass; existing
  integration-suite failures remain in this environment)

  viyatb-oai · 2026-02-20 10:39:55 -08:00
  e8afaed502
• feat(network-proxy): add websocket proxy env support (#11784)

  ## Summary
  - add managed proxy env wiring for websocket-specific variables
  (`WS_PROXY`/`WSS_PROXY`, including lowercase)
  - keep websocket proxy vars aligned with the existing managed HTTP proxy
  endpoint
  - add CONNECT regression tests to cover allowlist and denylist decisions
  (websocket tunnel path)
  - document websocket proxy usage and CONNECT policy behavior in the
  network proxy README
  
  ## Testing
  - just fmt
  - cargo test -p codex-network-proxy
  - cargo clippy -p codex-network-proxy
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-17 13:49:43 -08:00
  f2ad519a87
• feat(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• feat(network-proxy): structured policy signaling and attempt correlation to core (#11662)

  ## Summary
  When network requests were blocked, downstream code often had to infer
  ask vs deny from free-form response text. That was brittle and led to
  incorrect approval behavior.
  This PR fixes the proxy side so blocked decisions are structured and
  request metadata survives reliably.
  
  ## Description
  - Blocked proxy responses now carry consistent structured policy
  decision data.
  - Request attempt metadata is preserved across proxy env paths
  (including ALL_PROXY flows).
  - Header stripping was tightened so we still remove unsafe forwarding
  headers, but keep metadata needed for policy handling.
  - Block messages were clarified (for example, allowlist miss vs explicit
  deny).
  - Added unified violation log entries so policy failures can be
  inspected in one place.
  - Added/updated tests for these behaviors.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-13 09:01:11 +00:00
  2bced810da