746 Commits

• device-key: clean up unused crate (#21487)
  Ruslan Nigmatullin · 2026-05-07 09:01:44 -07:00
  e64a8979b0
• feat: make built-in MCPs first-class runtime servers (#21356)

  ## DISCLAIMER
  This is experimental and no production service must rely on this
  
  ## Why
  
  Built-in MCPs are product-owned runtime capabilities, but they were
  previously flattened into the same config-backed stdio path as
  user-configured servers. That made them depend on a hidden `codex
  builtin-mcp` re-exec path, exposed them through config-oriented CLI
  flows, and erased distinctions the runtime needs to preserve—most
  notably whether an MCP call should count as external context for
  memory-mode pollution.
  
  ## What changed
  
  - Model product-owned built-ins separately from config-backed MCP
  servers via `BuiltinMcpServer` and `EffectiveMcpServer`.
  - Launch built-ins in process through a reusable async transport instead
  of the hidden `builtin-mcp` stdio subcommand.
  - Keep config-oriented CLI operations such as `codex mcp
  list/get/login/logout` scoped to configured servers, while merging
  built-ins only into the effective runtime server set.
  - Retain server metadata after launch so parallel-tool support and
  context classification come from the live server set; built-in
  `memories` is now classified as local Codex state rather than external
  context.
  
  ## Test plan
  
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-core --test suite
  builtin_memories_mcp_call_does_not_mark_thread_memory_mode_polluted_when_configured`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-07 10:36:32 +02:00
  b2268999fe
• Show plugin hooks in plugin details (#21447)

  Supersedes the abandoned #19859, rebuilt on latest `main`.
  
  # Why
  
  PR #19705 adds discovery for hooks bundled with plugins, but `/plugins`
  still only shows skills, apps, and MCP servers. This follow-up makes
  bundled hooks visible in the same plugin detail view so users can
  inspect the full plugin surface in one place.
  
  We also need `PluginHookSummary` to populate Plugin Hooks in the app;
  `hooks/list` is not enough there because plugin detail needs to show
  hooks for disabled plugins too.
  
  # What
  
  - extend `plugin/read` with `PluginHookSummary` entries for bundled
  hooks
  - summarize plugin hooks while loading plugin details
  - render a `Hooks` row in the `/plugins` detail popup
  
  <img width="3456" height="848" alt="CleanShot 2026-04-27 at 11 45 34@2x"
  src="https://github.com/user-attachments/assets/fe3a38d6-a260-4351-8513-fb04c93d725b"
  />

  Abhinav · 2026-05-07 00:21:14 -07:00
  40e282849c
• Revert state DB injection and agent graph store (#21481)

  ## Why
  
  Reverts #20689 to restore the previous optional state DB plumbing. The
  conflict resolution keeps the newer installation ID and session/thread
  identity changes that landed after #20689, while removing the mandatory
  state DB and agent graph store dependency from ThreadManager
  construction.
  
  ## What changed
  
  - Restored `Option<StateDbHandle>` through app-server, MCP server,
  prompt debug, and test entry points.
  - Removed the `codex-core` dependency on `codex-agent-graph-store` and
  reverted descendant lookup back to the existing state DB path when
  available.
  - Kept newer `installation_id` forwarding by passing it beside the
  optional DB handle.
  - Kept local thread-name updates working when the optional state DB
  handle is absent.
  
  ## Validation
  
  - `git diff --check`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-state -p codex-rollout -p
  codex-app-server-protocol`
  - Attempted `env CARGO_INCREMENTAL=0 cargo test -p codex-core -p
  codex-app-server -p codex-app-server-client -p codex-mcp-server -p
  codex-thread-manager-sample -p codex-tui`; blocked locally by a rustc
  ICE while compiling `v8 v146.4.0` with `rustc 1.93.0 (254b59607
  2026-01-19)` on `aarch64-apple-darwin`.

  pakrym-oai · 2026-05-06 22:48:29 -07:00
  a8488fec5e
• Remove core MCP list tools op (#21281)

  ## Why
  
  The core `Op::ListMcpTools` request path is no longer needed. Keeping it
  around left a dead request/response surface alongside the app-server MCP
  inventory APIs that own current server status listing.
  
  ## What Changed
  
  - Removed `Op::ListMcpTools`, `EventMsg::McpListToolsResponse`, and the
  core handler that built the MCP snapshot response.
  - Removed the now-unused `codex-mcp` snapshot wrapper/export and passive
  event handling arms in rollout and MCP-server consumers.
  - Updated tests that used the old op as a synchronization hook to wait
  on existing startup/skills events, and deleted the plugin test that only
  exercised the removed listing op.
  
  ## Validation
  
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-rollout -p codex-rollout-trace -p
  codex-mcp-server`
  - `cargo test -p codex-core --test all
  pending_input::queued_inter_agent_mail`
  - `cargo test -p codex-core --test all
  rmcp_client::stdio_mcp_tool_call_includes_sandbox_state_meta`
  - `cargo test -p codex-core --test all
  rmcp_client::stdio_image_responses`
  - `just fix -p codex-core -p codex-protocol -p codex-mcp -p
  codex-rollout -p codex-rollout-trace -p codex-mcp-server`

  pakrym-oai · 2026-05-06 11:20:34 -07:00
  712305be47
• Move message history out of core (#21278)

  ## Why
  
  Message history was implemented inside `codex-core` and surfaced through
  core protocol ops and `SessionConfiguredEvent` fields even though the
  current consumer is TUI-local prompt recall. That made core own UI
  history persistence and exposed `history_log_id` / `history_entry_count`
  through surfaces that app-server and other clients do not need.
  
  This change moves message history persistence out of core and keeps the
  recall plumbing local to the TUI.
  
  ## What changed
  
  - Added a new `codex-message-history` crate for appending, looking up,
  trimming, and reading metadata from `history.jsonl`.
  - Removed core protocol history ops/events: `AddToHistory`,
  `GetHistoryEntryRequest`, and `GetHistoryEntryResponse`.
  - Removed `history_log_id` and `history_entry_count` from
  `SessionConfiguredEvent` and updated exec/MCP/test fixtures accordingly.
  - Updated the TUI to dispatch local app events for message-history
  append/lookup and keep its persistent-history metadata in TUI session
  state.
  
  ## Validation
  
  - `cargo test -p codex-message-history -p codex-protocol`
  - `cargo test -p codex-exec event_processor_with_json_output`
  - `cargo test -p codex-mcp-server outgoing_message`
  - `cargo test -p codex-tui`
  - `just fix -p codex-message-history -p codex-protocol -p codex-core -p
  codex-tui -p codex-exec -p codex-mcp-server`

  pakrym-oai · 2026-05-06 08:35:42 -07:00
  2004173cd7
• chore: spawn MCP for memories (#21214)

  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 15:05:54 +02:00
  ca257b6ce5
• test: isolate app-server-client in-process test state (#21328)

  ## Why
  
  The in-process `app-server-client` tests were still building their
  configs from the ambient `codex_home` and letting the embedded app
  server create its own state DB when `state_db` was absent. That matters
  because in-process startup falls back to
  `init_state_db_from_config(...)` in that case, so tests can otherwise
  share persisted state instead of getting isolated fixtures:
  [`app-server/src/in_process.rs`](https://github.com/openai/codex/blob/a98623511ba433154ec811fc63091617f5945438/codex-rs/app-server/src/in_process.rs#L368-L373).
  
  ## What changed
  
  - Give each in-process test client its own temporary `codex_home`.
  - Initialize the matching state DB from that per-client config and pass
  it into the client explicitly.
  - Keep the temp directory alive for the lifetime of the test client
  through a small `TestClient` wrapper.
  - Add `tempfile` as a dev dependency for the new harness.
  
  The updated setup lives in
  [`app-server-client/src/lib.rs`](https://github.com/openai/codex/blob/35c1133d45d10931914dbb88a1246a195d025ff6/codex-rs/app-server-client/src/lib.rs#L982-L1055).
  
  ## Testing
  
  - Existing `codex-app-server-client` tests continue to exercise the
  updated in-process client path through the isolated helper.

  jif-oai · 2026-05-06 09:21:22 +00:00
  b5e965e1d7
• linux-sandbox: use standalone bundled bwrap (#21255)

  **Summary**
  - Add `codex-bwrap`, a standalone `bwrap` binary built from the existing
  vendored bubblewrap sources.
  - Remove the linked vendored bwrap path from `codex-linux-sandbox`;
  runtime now prefers system `bwrap` and falls back to bundled
  `codex-resources/bwrap`.
  - Add bundled SHA-256 verification with missing/all-zero digest as the
  dev-mode skip value, then exec the verified file through
  `/proc/self/fd`.
  - Keep `launcher.rs` focused on choosing and dispatching the preferred
  launcher. Bundled lookup, digest verification, and bundled exec now live
  in `linux-sandbox/src/bundled_bwrap.rs`; Bazel runfiles lookup lives in
  `linux-sandbox/src/bazel_bwrap.rs`; shared argv/fd exec helpers live in
  `linux-sandbox/src/exec_util.rs`.
  - Teach Bazel tests to surface the Bazel-built `//codex-rs/bwrap:bwrap`
  through `CARGO_BIN_EXE_bwrap`; `codex-linux-sandbox` only honors that
  fallback in debug Bazel runfiles environments so release/user runtime
  lookup stays tied to `codex-resources/bwrap`.
  - Allow `codex-exec-server` filesystem helpers to preserve just the
  Bazel bwrap/runfiles variables they need in debug Bazel builds, since
  those helpers intentionally rebuild a small environment before spawning
  `codex-linux-sandbox`.
  - Verify the Bazel bwrap target in Linux release CI with a build-only
  check. Running `bwrap --version` is too strong for GitHub runners
  because bubblewrap still attempts namespace setup there.
  
  **Verification**
  - Latest update: `cargo test -p codex-linux-sandbox`
  - Latest update: `just fix -p codex-linux-sandbox`
  - `cargo check --target x86_64-unknown-linux-gnu -p codex-linux-sandbox`
  could not run locally because this macOS machine does not have
  `x86_64-linux-gnu-gcc`; GitHub Linux Bazel CI is expected to cover the
  Linux-only modules.
  - Earlier in this PR: `cargo test -p codex-bwrap`
  - Earlier in this PR: `cargo test -p codex-exec-server`
  - Earlier in this PR: `cargo check --release -p codex-exec-server`
  - Earlier in this PR: `just fix -p codex-linux-sandbox -p
  codex-exec-server`
  - Earlier in this PR: `bazel test --nobuild
  //codex-rs/linux-sandbox:linux-sandbox-all-test
  //codex-rs/core:core-all-test
  //codex-rs/exec-server:exec-server-file_system-test
  //codex-rs/app-server:app-server-all-test` (analysis completed; Bazel
  then refuses to run tests under `--nobuild`)
  - Earlier in this PR: `bazel build --nobuild //codex-rs/bwrap:bwrap`
  - Prior to this update: `just bazel-lock-update`, `just
  bazel-lock-check`, and YAML parse check for
  `.github/workflows/bazel.yml`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21255).
  * #21257
  * #21256
  * __->__ #21255

  Michael Bolin · 2026-05-05 17:14:29 -07:00
  26f355b67b
• Add cloud executor registration to exec-server (#19575)

  ## Summary
  This PR adds the first `codex-rs` milestone for remote-exec e2e: a local
  `codex exec-server` can now register itself with
  `codex-cloud-environments` and attach to the returned rendezvous
  websocket.
  
  At a high level, `codex exec-server --cloud ...` now:
  - loads ChatGPT auth from normal Codex config
  - registers an executor with `codex-cloud-environments`
  - receives a signed rendezvous websocket URL
  - serves the existing exec-server JSON-RPC protocol over that websocket
  
  ## What Changed
  - Added `--cloud`, `--cloud-base-url`, `--cloud-environment-id`, and
  `--cloud-name` to `codex exec-server`
  - Added a new `exec-server/src/cloud.rs` module that handles:
    - registration requests
    - auth/header setup
    - bounded auth retry on `401/403`
    - reconnect/backoff after websocket disconnects
  - Reused the existing `ConnectionProcessor` / `ExecServerHandler` path
  so cloud mode serves the same exec/filesystem RPC surface as local
  websocket mode
  - Added cloud-specific error variants and minimal docs for the new mode
  
  ## Testing
  Manual e2e test that fully goes through exec server flow with our codex
  cloud agent as orchestrator

  Michael Zeng · 2026-05-05 22:01:48 +00:00
  d0f9d5eba2
• Inject state DB, agent graph store (#20689)

  ## Why
  
  We want the agent graph store to be passed down the stack as a real
  dependency, the same way we already treat the thread store.
  
  This will let us inject the agent graph store as a real dependency and
  support implementations other than the local SQLite-backed one. Right
  now most code instantiates a state DB and an agent graph store
  just-in-time. Ideally, we would not depend on the state DB directly but
  only read through the higher-level interfaces.
  
  This change makes the dependency boundaries explicit and moves state DB
  initialization to process bootstrap instead of hiding it inside local
  store implementations.
  
  ## What changed
  
  - `ThreadManager` now requires a `StateDbHandle` and an
  `AgentGraphStore` at construction time instead of treating them as
  optional internals.
  - The local store constructors no longer lazily initialize SQLite.
  Callers now initialize the state DB once per process and use that shared
  handle to build:
    - `LocalThreadStore`
    - `LocalAgentGraphStore`
  - App bootstraps (`app-server`, `mcp-server`, `prompt_debug`, and the
  thread-manager sample) now initialize the state DB up front and inject
  the resulting handle down the stack.
  - `app-server` now consistently uses its process-scoped state DB handle
  instead of reopening SQLite or trying to recover it from loaded threads.
  - Device-key storage now reuses the shared state DB handle instead of
  maintaining its own lazy opener.
  - The thread archive / descendant traversal paths now use the injected
  `AgentGraphStore` instead of reaching through local
  thread-store-specific state.
  
  ## Verification
  
  - `cargo check -p codex-core -p codex-thread-store -p codex-app-server
  -p codex-mcp-server -p codex-thread-manager-sample --tests`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-core
  thread_manager_accepts_separate_agent_graph_store_and_thread_store --
  --nocapture`
  - `cargo test -p codex-app-server
  thread_archive_archives_spawned_descendants -- --nocapture`

  Rasmus Rygaard · 2026-05-05 21:45:29 +00:00
  7e310bc7f3
• hook trust metadata and enforcement (#20321)

  # Why
  
  We want shared hook trust that both the app and the TUI can build on,
  but the metadata is only useful if runtime behavior agrees with it. This
  PR adds a single backend trust model for hooks so unmanaged hooks cannot
  run until the current definition has been reviewed, while managed hooks
  remain runnable and non-configurable.
  
  # What
  
  - persist `trusted_hash` alongside hook state in `config.toml`
  - expose `currentHash` and derived `trustStatus` through `hooks/list`
  - derive trust from normalized hook definitions so equivalent hooks from
  `config.toml` and `hooks.json` share the same trust identity
  - gate unmanaged hooks on trust before they enter the runnable handler
  set
  
  # Reviewer Notes
  
  - key file to review is `codex-rs/hooks/src/engine/discovery.rs`
  - the only **core** change is schema related

  Abhinav · 2026-05-05 19:13:55 +00:00
  0452dca986
• Spill large hook outputs from context (#21069)

  ## Why
  
  Large hook outputs can enter model-visible context through hook-specific
  paths such as `additionalContext` and `Stop` continuation prompts.
  Without a dedicated cap, one hook can inject a large blob directly into
  conversation history instead of leaving a bounded preview for the model
  and preserving the full text elsewhere.
  
  ## What
  
  - spill hook text once it exceeds a fixed `2_500`-token budget,
  preserving the full output on disk and leaving a head/tail preview plus
  saved path in context
  - add shared hook-output spilling under
  `CODEX_HOME/hook_outputs/<thread_id>/<uuid>.txt`
  - apply the cap to both `additionalContext`, `feedback_message`, and
  `Stop` continuation fragments

  Abhinav · 2026-05-05 05:03:18 +00:00
  dca105cf99
• memories/mcp: generate tool schemas with schemars (#21012)

  ## Why
  
  The memories MCP server currently keeps handwritten JSON Schema beside
  the Rust types that actually serialize and deserialize the tool
  payloads:
  [`schema.rs`](https://github.com/openai/codex/blob/2f5c06a29cdd68f11d07126dc56871bff1218ba1/codex-rs/memories/mcp/src/schema.rs#L4-L133),
  [`server.rs`](https://github.com/openai/codex/blob/2f5c06a29cdd68f11d07126dc56871bff1218ba1/codex-rs/memories/mcp/src/server.rs#L44-L75),
  and
  [`backend.rs`](https://github.com/openai/codex/blob/2f5c06a29cdd68f11d07126dc56871bff1218ba1/codex-rs/memories/mcp/src/backend.rs#L41-L117).
  That duplicates the tool contract and makes schema drift easier as the
  API evolves.
  
  ## What changed
  
  - derive `JsonSchema` for the memories tool arguments, responses, and
  nested response types
  - replace the handwritten schema builders with shared `schemars`
  generation
  - preserve the existing wire shape while generating schemas, including
  nullable output `Option` fields and non-nullable optional input fields
  - wire the `list`, `read`, and `search` tools to the generated schemas
  
  ## Verification
  
  - CI pending

  jif-oai · 2026-05-04 18:40:17 +02:00
  f20f8a719e
• feat: memories mcp v1 (#20622)

  Add an experimental MCP on memories
  This must never be used and is only here for testing purpose
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-04 13:51:03 +02:00
  d013155f40
• Fix custom CA login behind TLS-inspecting proxies (#20676)

  Refs:
  https://linear.app/openai/issue/SE-6311/login-fails-for-experian-users-behind-tls-inspecting-proxy
  
  ## Summary
  - When a custom CA bundle is configured, force the shared `codex-client`
  reqwest builder onto rustls before registering custom roots.
  - Add the `rustls-tls-native-roots` reqwest feature so the rustls client
  preserves native roots plus the enterprise CA bundle.
  - Add subprocess TLS coverage for both a direct local TLS 1.3 server and
  a hermetic local CONNECT TLS-intercepting proxy that forwards a
  token-exchange-shaped POST to a local origin.
  
  ## Plain-language explanation
  Experian users are behind a TLS-inspecting proxy, so the login token
  exchange needs to trust the enterprise CA bundle from
  `CODEX_CA_CERTIFICATE` or `SSL_CERT_FILE`. Before this change, that
  custom-CA branch still used reqwest default TLS selection, which could
  fail in the proxy environment. Now, only when a custom CA is configured,
  Codex selects rustls first and then adds the custom CA roots, matching
  the validated behavior from the Experian test build while leaving normal
  system-root clients unchanged.
  
  The new regression test recreates the enterprise-proxy shape locally:
  the probe client sends an HTTPS `POST /oauth/token` through an explicit
  HTTP CONNECT proxy, the proxy presents a leaf certificate signed by a
  runtime-generated test CA, decrypts the request, forwards it to a local
  origin, and relays the `ok` response back.
  
  ## Scope note
  - The actual production fix is the first commit: `8368119282 Fix custom
  CA reqwest clients to use rustls`.
  - The second commit is integration-test coverage only. It generates all
  test CA and localhost certificate material at runtime.
  
  ## Validation
  - `cd codex-rs && cargo test -p codex-client --test ca_env
  posts_to_token_origin_through_tls_intercepting_proxy_with_custom_ca_bundle
  -- --nocapture`
  - `cd codex-rs && cargo test -p codex-client`
  - `cd codex-rs && cargo test -p codex-login`
  - `cd codex-rs && just fmt`
  - `cd codex-rs && just bazel-lock-update`
  - `cd codex-rs && just bazel-lock-check`
  - `cd codex-rs && just fix -p codex-client`

  jgershen-oai · 2026-05-01 17:51:49 -07:00
  9e905528bb
• app-server: move transport into dedicated crate (#20545)

  ## Why
  
  `codex-app-server` currently owns both request-processing code and
  transport implementation details. Splitting the transport layer into its
  own crate makes that boundary explicit, reduces the amount of
  transport-specific dependency surface carried by `codex-app-server`, and
  gives future transport work a narrower place to evolve.
  
  ## What changed
  
  - Added `codex-app-server-transport` and moved the existing transport
  tree into it, including stdio, unix socket, websocket, remote-control
  transport, and websocket auth.
  - Moved shared transport-facing message types into the new crate so both
  the transport implementation and `codex-app-server` use the same
  definitions.
  - Kept processor-facing connection state and outbound routing in
  `codex-app-server`, with the routing tests moved next to that local
  wrapper.
  - Updated workspace metadata, Bazel crate metadata, and
  `codex-app-server` dependencies for the new crate boundary.
  
  ## Validation
  
  - `cargo metadata --locked --no-deps`
  - `git diff --check`
  - Attempted `cargo test -p codex-app-server-transport`, `cargo test -p
  codex-app-server`, `just fix -p codex-app-server-transport`, and `just
  fix -p codex-app-server`; all were blocked before compilation by the
  existing `packageproxy` resolution failure for locked `rustls-webpki =
  0.103.13`.
  - Attempted Bazel build / lockfile validation; those were blocked by
  external fetch failures against BuildBuddy / GitHub while resolving
  `v8`.

  Ruslan Nigmatullin · 2026-05-01 09:23:47 -07:00
  41e171fcf2
• Move plugin out of core. (#20348)
  xl-openai · 2026-04-30 14:26:14 -07:00
  7b3de63041
• install WFP filters for Windows sandbox setup (#20101)

  ## Summary
  
  This PR installs a first wave of WFP (Windows Filtering Platform)
  filters that reduce the surface area of network egress vulnerabilities
  for the Windows Sandbox.
  
  - Add persistent Windows Filtering Platform provider, sublayer, and
  filters for the Windows sandbox offline account.
  - Install WFP filters during elevated full setup, log failures
  non-fatally, and emit setup metrics when analytics are enabled.
  - Bump the Windows sandbox setup version so existing users rerun full
  setup and receive the new filters.
  
  ## What WFP is
  Windows Filtering Platform (WFP) is the low-level Windows networking
  policy engine underneath things like Windows Firewall. It lets
  privileged code install persistent filtering rules at specific network
  stack layers, with conditions like "only traffic from this Windows
  account" or "only this remote port," and an action like block.
  
  In this change, we create a Codex-owned persistent WFP provider and
  sublayer, then install block filters scoped to the Windows sandbox's
  offline user account via `ALE_USER_ID`. That means the filters are
  targeted at sandboxed processes running as that account, rather than
  globally affecting the host.
  
  ## Initial filter set
  We are starting with 12 concrete WFP filters across a few high-value
  bypass surfaces. The table below describes the filter families rather
  than one filter per row:
  
  | Area | Concrete filters | Purpose |
  | --- | --- | --- |
  | ICMP | 4 filters: ICMP v4/v6 on `ALE_AUTH_CONNECT` and
  `ALE_RESOURCE_ASSIGNMENT` | Block direct ping-style network reachability
  checks from the offline account. |
  | DNS | 2 filters: remote port `53` on `ALE_AUTH_CONNECT_V4/V6` | Block
  direct DNS queries that bypass our intended proxy/offline path. |
  | DNS-over-TLS | 2 filters: remote port `853` on
  `ALE_AUTH_CONNECT_V4/V6` | Block encrypted DNS attempts that could
  bypass ordinary DNS interception. |
  | SMB / NetBIOS | 4 filters: remote ports `445` and `139` on
  `ALE_AUTH_CONNECT_V4/V6` | Block Windows file-sharing/network share
  traffic from sandboxed processes. |
  
  For IPv4/IPv6 coverage, the port-based filters are installed on both
  `ALE_AUTH_CONNECT_V4` and `ALE_AUTH_CONNECT_V6`. ICMP also gets both
  connect-layer and resource-assignment-layer coverage because ICMP
  traffic is shaped differently from ordinary TCP/UDP port traffic.
  
  ## Validation
  - `cargo fmt -p codex-windows-sandbox` (completed with existing
  stable-rustfmt warnings about `imports_granularity = Item`)
  - `cargo test -p codex-windows-sandbox wfp::tests`
  - `cargo test -p codex-windows-sandbox` (fails in existing legacy
  PowerShell sandbox tests because `Microsoft.PowerShell.Utility` could
  not be loaded; WFP tests passed before that failure)

  iceweasel-oai · 2026-04-30 12:39:01 -07:00
  8121710ffe
• fix: show correct Bedrock runtime endpoint in /status (#20275)

  ## Why
  
  `/status` was showing the configured `ModelProviderInfo.base_url` for
  Amazon Bedrock, which can be stale or misleading because the actual
  Bedrock Mantle endpoint is derived at runtime from the resolved AWS
  region. This made sessions report the wrong provider endpoint even
  though requests used the correct runtime URL.
  
  ## What changed
  
  - Added `ModelProvider::runtime_base_url()` so provider implementations
  can expose the request-time base URL through the shared runtime provider
  abstraction.
  - Moved Bedrock region-to-Mantle URL resolution into
  `amazon_bedrock::mantle::runtime_base_url()`, keeping region resolution
  private to the Mantle module.
  - Overrode `runtime_base_url()` for Amazon Bedrock so it returns the
  resolved Mantle endpoint instead of the configured default.
  - Resolved and cached the runtime provider base URL during TUI startup,
  then used that cached value when rendering `/status`.
  - Added status coverage that verifies Bedrock displays the runtime URL
  and ignores the configured Bedrock `base_url` when they differ.
  
  ## Verification
  model provider is resolved correctly in local build:
  <img width="696" height="245" alt="Screenshot 2026-04-29 at 5 01 36 PM"
  src="https://github.com/user-attachments/assets/a13c10a5-3720-41ab-8ace-3c4bc573f971"
  />

  Celia Chen · 2026-04-30 19:02:34 +00:00
  31f8813e3e
• Move item event mapping into app-server-protocol (#20299)

  ## Why
  
  Follow-up to #20291.
  
  The v2 item-event-to-notification translation had been embedded in
  `app-server/src/bespoke_event_handling.rs`, which made it hard to reuse
  anywhere else. This PR moves that stateless mapping into shared protocol
  code so other entry points can produce the same `ServerNotification`
  payloads without copying app-server logic.
  
  That also lets `thread-manager-sample` demonstrate the same notification
  surface that the app server exposes, instead of only printing the final
  assistant message.
  
  ## What changed
  
  - move `item_event_to_server_notification` into
  `codex-app-server-protocol::protocol::event_mapping`
  - keep the mapper tests next to the shared implementation in
  `codex-app-server-protocol`
  - re-export the mapper from `codex-core-api` so lightweight consumers
  can use it without reaching into `app-server-protocol` directly
  - simplify `app-server/src/bespoke_event_handling.rs` so it delegates
  the stateless event-to-notification projection to the shared helper
  - update `thread-manager-sample` to:
    - print mapped notifications as newline-delimited JSON
    - use the shared mapper through `codex-core-api`
  - enable the default feature set so the sample exposes the normal tool
  surface
  - use a `read_only` permission profile so shell commands can run in the
  sample without widening permissions
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-api`
  - `cargo test -p codex-app-server bespoke_event_handling::tests`
  - `cargo test -p codex-thread-manager-sample`
  - `cargo run -p codex-thread-manager-sample -- "briefly explore the repo
  with pwd and ls, then summarize it"`

  pakrym-oai · 2026-04-30 11:02:13 -07:00
  5cc5f12efc
• Reduce the surface of collaboration modes (#20149)

  Collaboration modes were slightly invasive both into ThreadManager
  construction and ModelProvider

  pakrym-oai · 2026-04-29 17:22:41 -07:00
  fedcefe9da
• Add hooks/list app-server RPC (#19778)

  ## Why
  
  We need a way to list the available hooks to expose via the TUI and App
  so users can view and manage their hooks
  
  ## What
  
  - Adds `hooks/list` for one or more `cwd` values that returns discovered
  hook metadata
  
  ## Stack
  
  1. openai/codex#19705
  2. This PR - openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Review Notes
  
  The generated schema files account for most of the raw diff, these files
  have the core change:
  
  - `hooks/src/engine/discovery.rs` builds the inventory entries during
  hook discovery while leaving runtime handlers focused on execution.
  - `app-server/src/codex_message_processor.rs` wires `hooks/list` into
  the app-server flow for each requested `cwd`.
  - `app-server-protocol/src/protocol/v2.rs` defines the new v2
  request/response payloads exposed on the wire.
  
  ### Core Changes
  
  `core/src/plugins/manager.rs` adds `plugins_for_layer_stack(...)` so
  `skills/list` and `hooks/list`can resolve plugin state for each
  requested `cwd`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-29 23:39:57 +00:00
  8774229a89
• Add codex-core public API listing (#20243)

  Summary:
  - Add a checked-in codex-core public API listing generated by
  cargo-public-api.
  - Add scripts/regen-public-api.sh with an embedded crate list,
  auto-install for cargo-public-api 0.51.0, pinned nightly, and --check
  mode.
  - Add Rust CI jobs on the codex Linux x64 runner pool to verify the
  listing stays up to date.
  
  Testing:
  - bash -n scripts/regen-public-api.sh
  - just regen-public-api --check
  - yq '.' .github/workflows/rust-ci.yml
  .github/workflows/rust-ci-full.yml
  - git diff --check

  pakrym-oai · 2026-04-29 22:58:08 +00:00
  8de2a7a16d
• Add agent graph store interface (#19229)

  ## Summary
  
  Persisted subagent parent/child topology currently leaks through
  `StateRuntime`'s SQLite-specific thread-spawn helpers. This PR
  introduces a narrow `AgentGraphStore` boundary so follow-up work can
  route graph operations through a local or remote store without coupling
  orchestration code directly to the state DB graph API.
  
  ## Changes
  
  - Adds the new `codex-agent-graph-store` crate.
  - Defines a flat `AgentGraphStore` trait for the v1 graph surface:
  upsert edge, set edge status, list direct children, and list
  descendants.
  - Adds public graph types for `ThreadSpawnEdgeStatus`,
  `AgentGraphStoreError`, and `AgentGraphStoreResult`.
  - Implements `LocalAgentGraphStore` on top of an existing
  `codex_state::StateRuntime`, preserving today's SQLite-backed
  `thread_spawn_edges` behavior.
  - Registers the crate in Cargo/Bazel metadata.
  
  This PR only adds the local contract and implementation; call-site
  migration and the remote gRPC store are left to the follow-up PRs in the
  stack.
  
  ## Testing
  
  - `cargo test -p codex-agent-graph-store`
  
  The new unit tests cover local parity with the existing `StateRuntime`
  graph methods, `Open`/`Closed` filtering, status updates, and stable
  breadth-first descendant ordering.

  Rasmus Rygaard · 2026-04-29 22:48:26 +00:00
  782191547c
• Escape turn metadata headers as ASCII JSON (#19620)

  ## Why
  
  `x-codex-turn-metadata` is sent as an HTTP/WebSocket header, but Codex
  was serializing the metadata JSON with raw UTF-8 string contents. When a
  workspace path contains non-ASCII characters, common HTTP stacks can
  reject or corrupt that header before the request reaches the provider.
  
  Fixes #17468. Also addresses the duplicate WebSocket report in #19581.
  
  ## What changed
  
  - Added `codex_utils_string::to_ascii_json_string`, a shared helper that
  serializes JSON normally while escaping non-ASCII string content as
  `\uXXXX`.
  - Switched turn metadata header serialization, including merged
  Responses API client metadata, to use the ASCII-safe JSON helper.
  - Added coverage for non-ASCII workspace paths and non-ASCII client
  metadata while preserving the same parsed JSON values.
  
  ## Verification
  
  - `cargo test -p codex-utils-string`
  - `cargo test -p codex-core turn_metadata`
  - `just bazel-lock-check`

  Eric Traut · 2026-04-29 15:35:33 -07:00
  4241df4d79
• Add ThreadManager sample crate (#20141)

  Summary:
  - Add codex-thread-manager-sample, a one-shot binary that starts a
  ThreadManager thread, submits a prompt, and prints the final assistant
  output.
  - Pass ThreadStore into ThreadManager::new and expose
  thread_store_from_config for existing callsites.
  - Build the sample Config directly with only --model and prompt inputs.
  
  Verification:
  - just fmt
  - cargo check -p codex-thread-manager-sample -p codex-app-server -p
  codex-mcp-server
  - git diff --check
  
  Tests: Not run per request.

  pakrym-oai · 2026-04-29 11:21:06 -07:00
  8356806fc9
• Support detect and import MCP, Subagents, hooks, commands from external (#19949)

  ## Why
  This PR expands the migration path so Codex can detect and import MCP
  server config, hooks, commands, and subagents configs in a Codex-native
  shape.
  
  ## What changed
  
  - Added a `codex-external-agent-migration` crate that owns conversion
  logic for external-agent MCP servers, hooks, commands, and subagents.
  - Extended the app-server external-agent config detection/import API
  with migration item types for MCP server config, hooks, commands, and
  subagents.
  
  ## Migration strategy
  
  The migration is intentionally conservative: Codex only imports
  external-agent config that can be represented safely in Codex today.
  Unsupported or ambiguous config is skipped instead of being partially
  translated into behavior that may not match the source system.
  
  - **MCP servers**: import supported stdio and HTTP MCP server
  definitions into `mcp_servers`. Disabled servers and servers filtered
  out by source `enabledMcpjsonServers` / `disabledMcpjsonServers` are
  skipped. Project-scoped MCP entries from `.claude.json` are included
  when they match the repo path.
  - **Hooks**: import only supported command hooks into
  `.codex/hooks.json`. Unsupported hook features such as conditional
  groups, async handlers, prompt/http hooks, or unknown fields are
  skipped. Referenced hook scripts are copied into `.codex/hooks/`,
  preserving any existing target scripts.
  - **Commands**: import supported external commands as Codex skills under
  `.agents/skills/source-command-*`. Commands that rely on source runtime
  expansion such as `$ARGUMENTS`, `$1`, `@file` references, shell
  interpolation, or colliding generated names are skipped.
  - **Subagents**: import valid subagent Markdown files into
  `.codex/agents/*.toml` when they have the minimum Codex agent fields.
  Source model names are not migrated, so imported agents keep the user’s
  Codex default model; compatible reasoning effort and sandbox mode are
  migrated when present.
  - **Skills and project guidance**: copy missing skill directories into
  `.agents/skills` and migrate `CLAUDE.md` guidance into `AGENTS.md`,
  rewriting source-agent terminology to Codex terminology where
  appropriate.
  - **Detection details**: detected migration items include lightweight
  details for UI preview, such as MCP server names, hook event names,
  generated command skill names, and subagent names. Import still
  recomputes from disk instead of trusting details as the source of truth.
  
  - Adds focused coverage for the new migration behavior and app-server
  import flow.
  
  ## Verification
  
  - `cargo test -p codex-external-agent-migration`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server external_agent_config`
  - `just bazel-lock-check`

  alexsong-oai · 2026-04-29 00:45:24 +00:00
  cb8b1bbcd6
• Discover hooks bundled with plugins (#19705)

  ## Why
  
  Plugins can bundle lifecycle hooks, but Codex previously only discovered
  hooks from user, project, and managed config layers. This adds the
  plugin discovery and runtime plumbing needed for plugin-bundled hooks
  while keeping execution behind the `plugin_hooks` feature flag.
  
  ## What
  
  - Discovers plugin hook sources from each plugin's default
  `hooks/hooks.json`.
  - Supports `plugin.json` manifest `hooks` entries as either relative
  paths or inline hook objects.
  - Plumbs discovered plugin hook sources through plugin loading into the
  hook runtime when `plugin_hooks` is enabled.
  - Marks plugin-originated hook runs as `HookSource::Plugin`.
  - Injects `PLUGIN_ROOT` and `CLAUDE_PLUGIN_ROOT` into plugin hook
  command environments.
  - Updates generated schemas and hook source metadata for the plugin hook
  source.
  
  ## Stack
  
  1. This PR - openai/codex#19705
  2. openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  - Core logic is in `codex-rs/core-plugins/src/loader.rs` and
  `codex-rs/hooks/src/engine/discovery.rs`
  - Moved existing / adding new tests to
  `codex-rs/core-plugins/src/loader_tests.rs` hence the large diff there
  - Otherwise mostly plumbing and minor schema updates
  
  ### Core Changes
  
  The `codex-rs/core` changes are limited to wiring plugin hook support
  into existing core flows:
  
  - `core/src/session/session.rs` conditionally pulls effective plugin
  hook sources and plugin hook load warnings from `PluginsManager` when
  `plugin_hooks` is enabled, then passes them into `HooksConfig`.
  - `core/src/hook_runtime.rs` adds the `plugin` metric tag for
  `HookSource::Plugin`.
  - `core/config.schema.json` picks up the new `plugin_hooks` feature
  flag, and `core/src/plugins/manager_tests.rs` updates fixtures for the
  added plugin hook fields.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-28 14:17:18 -07:00
  c6e7d564c3
• fix(network-proxy): harden linux proxy bridge helpers (#20001)

  ## Why
  The Linux managed-proxy bridge helpers are long-lived child processes in
  the sandbox networking path. Before this change they stayed dumpable and
  the network seccomp profile did not block cross-process memory syscalls,
  so another same-user process could potentially inspect or modify bridge
  memory instead of interacting only through the intended proxy interface.
  
  ## What changed
  - reuse the shared `codex-process-hardening` helper to mark bridge
  helper children non-dumpable before they begin serving
  - deny `process_vm_readv` and `process_vm_writev` in the existing
  network seccomp filter
  
  ## Security impact
  Bridge helpers are less exposed to same-user cross-process inspection or
  memory writes, which reduces the chance that sandboxed code can
  interfere with proxy support processes outside the intended IPC path.
  
  ## Verification
  - `cargo test -p codex-process-hardening`
  - `cargo test -p codex-linux-sandbox`
  - attempted `cargo check -p codex-linux-sandbox --target
  x86_64-unknown-linux-gnu`; blocked on missing `x86_64-linux-gnu-gcc` on
  this macOS host
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-28 11:52:50 -07:00
  3377afd84a
• permissions: add built-in default profiles (#19900)

  ## Why
  
  The migration away from `SandboxPolicy` needs new configs to start from
  permissions profiles instead of deriving profiles from legacy sandbox
  modes. Existing users can have empty `config.toml` files, and we should
  not rewrite user-owned config files that may live in shared
  repositories.
  
  This PR introduces built-in profile names so an empty config can resolve
  to a canonical `PermissionProfile`, while explicit named `[permissions]`
  profiles still behave predictably.
  
  ## What changed
  
  - Adds built-in `default_permissions` profile names:
    - `:read-only` maps to `PermissionProfile::read_only()`.
  - `:workspace` maps to the workspace-write profile, including
  project-root metadata carveouts.
  - `:danger-no-sandbox` maps to `PermissionProfile::Disabled`, preserving
  the distinction between no sandbox and a broad managed sandbox.
  - Reserves the `:` prefix for built-in profiles so user-defined
  `[permissions]` profiles cannot collide with future built-ins.
  - Allows `default_permissions` to reference a built-in profile without
  requiring a `[permissions]` table.
  - Makes an otherwise empty config choose a built-in profile by
  trust/platform context: trusted or untrusted project roots use
  `:workspace` when the platform supports that sandbox, while roots
  without a trust decision use `:read-only`.
  - Keeps legacy `sandbox_mode` configs on the legacy path, and still
  rejects user-defined `[permissions]` profiles that omit
  `default_permissions` so we do not silently guess among custom profiles.
  - Preserves compatibility behavior for implicit defaults: bare
  `network.enabled = true` allows runtime network without starting the
  managed proxy, explicit profile proxy policy still starts the proxy, and
  implicit workspace/add-dir roots keep legacy metadata carveouts.
  
  ## Verification
  
  - `cargo test -p codex-core builtin --lib`
  - `cargo test -p codex-core profile_network_proxy_config`
  - `cargo test -p codex-core
  implicit_builtin_workspace_profile_preserves_add_dir_metadata_carveouts`
  - `cargo test -p codex-core
  permissions_profiles_network_enabled_allows_runtime_network_without_proxy`
  - `cargo test -p codex-core
  permissions_profiles_proxy_policy_starts_managed_network_proxy`
  
  ## Documentation
  
  Public Codex config docs should mention these built-in names when the
  `[permissions]` config format is ready to document as stable.
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19900).
  * #20041
  * #20040
  * #20037
  * #20035
  * #20034
  * #20033
  * #20032
  * #20030
  * #20028
  * #20027
  * #20026
  * #20024
  * #20021
  * #20018
  * #20016
  * #20015
  * #20013
  * #20011
  * #20010
  * #20008
  * __->__ #19900

  Michael Bolin · 2026-04-28 11:21:39 -07:00
  9e26613657
• External agent session support (#19895)

  ## Summary
  
  This extends external agent detection/import beyond config artifacts so
  Codex can detect recent sessions files from the external agent home and
  import them into Codex rollout history.
  
  ## What changed
  
  - Added a focused `external_agent_sessions` module for:
    - session discovery
    - source-record parsing
    - rollout construction
    - import ledger tracking
  - Wired session detection/import into the app-server external agent
  config API.
  - Added compaction handling so large imported sessions can be resumed
  safely before the first follow-up turn.
  
  ## Testing
  
  Added coverage for:
  - recent-session detection
  - custom-title handling
  - recency filtering
  - dedupe and re-detect-after-source-change behavior
  - visible imported turn construction
  - backward-compatible import payload deserialization
  - end-to-end RPC import flow
  - rejection of undetected session paths
  - repeat-import behavior
  - large-session compaction before first follow-up
  
  Ran:
  - `cargo test -p codex-app-server external_agent_config_import_ --test
  all`

  stefanstokic-oai · 2026-04-28 17:42:36 +00:00
  4c68bd728f
• feat: verify agent identity JWTs with JWKS (#19764)
  efrazer-oai · 2026-04-28 09:56:20 -07:00
  f6797c3ac6
• feat: skip memory startup when Codex rate limits are low (#19990)

  ## Why
  
  Memory startup runs in the background after an eligible turn, but it can
  consume Codex backend quota at exactly the wrong time: when the user is
  already near a rate-limit boundary. This PR adds a guard so the memory
  pipeline backs off when the Codex rate-limit snapshot says the remaining
  budget is too low.
  
  ## What Changed
  
  - Added `memories.min_rate_limit_remaining_percent` with a default of
  `25`, clamped to `0..=100`, and regenerated `core/config.schema.json`.
  - Added `codex-rs/memories/write/src/guard.rs`, which fetches Codex
  backend rate limits before memory startup and skips phase 1 / phase 2
  when the Codex limit is reached or either tracked window is above the
  configured usage ceiling.
  - Keeps startup best-effort: non-Codex auth or rate-limit fetch/client
  failures preserve the existing memory startup behavior.
  - Records a `codex.memory.startup` counter with
  `status=skipped_rate_limit` when startup is skipped.
  - Added config parsing/clamping coverage and guard unit tests.
  
  ## Verification
  
  - Added `codex-rs/memories/write/src/guard_tests.rs` for threshold,
  primary/secondary window, and reached-limit behavior.
  - Added config tests for TOML parsing and clamping.

  jif-oai · 2026-04-28 17:07:16 +02:00
  1b74360365
• feat: split memories part 2 (#19860)

  Keep extracting memories out of core and moving the write trigger in the
  app-server
  This is temporary and it should move at the client level as a follow-up
  This makes core fully independant from `codex-memories-write`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-28 13:03:28 +02:00
  431ebeaef7
• feat: Cache remote plugin bundles on install (#19914)

  Remote installs now fetch, validate, download, and cache the plugin
  bundle locally

  xl-openai · 2026-04-28 00:53:27 -07:00
  7d72fc8f53
• Remove ghost snapshots (#19481)

  ## Summary
  - Remove `ghost_snapshot` / `GhostCommit` from the Responses API surface
  and generated SDK/schema artifacts.
  - Keep legacy config loading compatible, but make undo a no-op that
  reports the feature is unavailable.
  - Clean up core history, compaction, telemetry, rollout, and tests to
  stop carrying ghost snapshot items.
  
  ## Testing
  - Unit tests passed for `codex-protocol`, `codex-core` targeted undo and
  compaction flows, `codex-rollout`, and `codex-app-server-protocol`.
  - Regenerated config and app-server schemas plus Python SDK artifacts
  and verified they match the checked-in outputs.

  pakrym-oai · 2026-04-27 18:48:57 -07:00
  4e05f3053c
• Refactor exec-server filesystem API into codex-file-system (#19892)

  ## Summary
  - Extracted the shared filesystem types and `ExecutorFileSystem` trait
  into a new `codex-file-system` crate
  - Switched `codex-config` and `codex-git-utils` to depend on that crate
  instead of `codex-exec-server`
  - Kept `codex-exec-server` re-exporting the same API for existing
  callers
  
  ## Testing
  - Ran `cargo test -p codex-file-system`
  - Ran `cargo test -p codex-git-utils`
  - Ran `cargo test -p codex-config`
  - Ran `cargo test -p codex-exec-server`
  - Ran `just fix -p codex-file-system`, `just fix -p codex-git-utils`,
  `just fix -p codex-config`, `just fix -p codex-exec-server`
  - Ran `just fmt`
  - Updated and verified the Bazel module lockfile

  Michael Zeng · 2026-04-27 17:43:15 -07:00
  a3350de855
• chore: split memories part 1 (#19818)

  Extract memories into 2 different crates

  jif-oai · 2026-04-27 16:01:05 +02:00
  bb83eec825
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• feat: load AgentIdentity from JWT login/env (#18904)

  ## Summary
  
  This PR lets programmatic AgentIdentity users provide one token through
  either stdin login or environment auth.
  
  `codex login --with-agent-identity` reads an Agent Identity JWT from
  stdin, validates that it has the required claims, and stores that token
  as the `agent_identity` value in `auth.json`. The file format is
  token-only; the decoded account and key fields are runtime state, not
  hand-authored auth.json fields.
  
  The Agent Identity JWT claim shape and decoder live in
  `codex-agent-identity`; `codex-login` only owns env/storage precedence
  and conversion into `CodexAuth::AgentIdentity`.
  
  When env auth is enabled, `CODEX_AGENT_IDENTITY` can provide the same
  JWT without writing auth state to disk. `CODEX_API_KEY` still wins if
  both env vars are set.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  Reference JWT/env stack: https://github.com/openai/codex/pull/18176
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. https://github.com/openai/codex/pull/18811: migrate Codex backend
  auth callsites through AuthProvider
  5. This PR: accept AgentIdentity JWTs through login/env
  
  ## Testing
  
  Tests: targeted login and Agent Identity crate tests, CLI checks, scoped
  formatter/linter cleanup, and CI.
  
  ---------
  
  Co-authored-by: Shijie Rao <shijie.rao@openai.com>

  efrazer-oai · 2026-04-26 19:49:54 +00:00
  fed0a8f4fa
• [codex] remove responses command (#19640)

  This removes the hidden `codex responses` CLI subcommand after
  confirming no downstream callers rely on it, deleting the raw Responses
  passthrough implementation, unregistering the subcommand, and dropping
  the now-unused CLI dependencies on `codex-api` and
  `codex-model-provider`.

  Thibault Sottiaux · 2026-04-25 23:10:38 -07:00
  87bc72408c
• Support end_turn in response.completed (#19610)

  Some providers of Responses API forward a model-defined `end_turn`
  boolean indicating explicitly the model's indication of whether it would
  like to end the turn or to be inferenced again. In this PR, we update
  the sampling loop to use this field correctly if it's set. If the field
  is not set by the provider, we fall back to the existing sampling logic.

  Andrey Mishchenko · 2026-04-25 21:57:42 -07:00
  355c40ad7e
• app-server: persist device key bindings in sqlite (#19206)

  ## Why
  
  Device-key providers should only own platform key material. The
  account/client binding used to authorize a signing payload is app-server
  state, and keeping that state in provider-specific metadata makes the
  same check harder to audit and harder to share across platform
  implementations.
  
  Persisting the binding in the shared state database gives the device-key
  crate a platform-neutral source of truth before it asks a provider to
  sign. It also lets app-server move potentially blocking key operations
  off the main message processor path, which matters once providers may
  wait for OS authentication prompts.
  
  ## What changed
  
  - Add a `device_key_bindings` state migration plus `StateRuntime`
  helpers keyed by `key_id`.
  - Add an async `DeviceKeyBindingStore` abstraction to `codex-device-key`
  and use it from `DeviceKeyStore::create` and `DeviceKeyStore::sign`.
  - Keep provider calls behind async store methods and run the synchronous
  provider work through `spawn_blocking`.
  - Wire app-server device-key RPC handling to the SQLite-backed binding
  store and spawn response/error delivery tasks for device-key requests.
  - Run the turn-start tracing test on the existing larger current-thread
  test harness after the larger async surface made the default test stack
  too small locally.
  
  ## Validation
  
  - `cargo test -p codex-device-key`
  - `cargo test -p codex-state device_key`
  - `cargo test -p codex-state`
  - `cargo test -p codex-app-server device_key`
  - `cargo test -p codex-app-server
  message_processor::tracing_tests::turn_start_jsonrpc_span_parents_core_turn_spans`
  - `cargo test -p codex-app-server`
  - `just fix -p codex-device-key`
  - `just fix -p codex-state`
  - `just fix -p codex-app-server`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `git diff --check`

  Ruslan Nigmatullin · 2026-04-23 21:55:56 -07:00
  19badb0be2
• feat: let model providers own model discovery (#18950)

  ## Why
  
  `codex-models-manager` had grown to own provider-specific concerns:
  constructing OpenAI-compatible `/models` requests, resolving provider
  auth, emitting request telemetry, and deciding how provider catalogs
  should be sourced. That made the manager harder to reuse for providers
  whose model catalog is not fetched from the OpenAI `/models` endpoint,
  such as Amazon Bedrock.
  
  This change moves provider-specific model discovery behind
  provider-owned implementations, so the models manager can focus on
  refresh policy, cache behavior, picker ordering, and model metadata
  merging.
  
  ## What Changed
  
  - Introduced a `ModelsManager` trait with separate `OpenAiModelsManager`
  and `StaticModelsManager` implementations.
  - Added `ModelsEndpointClient` so OpenAI-compatible HTTP fetching lives
  outside `codex-models-manager`.
  - Moved `/models` request construction, provider auth resolution,
  timeout handling, and request telemetry into `codex-model-provider` via
  `OpenAiModelsEndpoint`.
  - Added provider-owned `models_manager(...)` construction so configured
  OpenAI-compatible providers use `OpenAiModelsManager`, while
  static/catalog-backed providers can return `StaticModelsManager`.
  - Added an Amazon Bedrock static model catalog for the GPT OSS Bedrock
  model IDs.
  - Updated core/session/thread manager code and tests to depend on
  `Arc<dyn ModelsManager>`.
  - Moved offline model test helpers into
  `codex_models_manager::test_support`.
  ## Metadata References
  
  The Bedrock catalog metadata is based on the official Amazon Bedrock
  OpenAI model documentation:
  
  - [Amazon Bedrock OpenAI
  models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-openai.html)
  lists the Bedrock model IDs, text input/output modalities, and `128,000`
  token context window for `gpt-oss-20b` and `gpt-oss-120b`.
  - [Amazon Bedrock `gpt-oss-120b` model
  card](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-oss-120b.html)
  lists the `bedrock-runtime` model ID `openai.gpt-oss-120b-1:0`, the
  `bedrock-mantle` model ID `openai.gpt-oss-120b`, text-only modalities,
  and `128K` context window.
  - [OpenAI `gpt-oss-120b` model
  docs](https://developers.openai.com/api/docs/models/gpt-oss-120b)
  document configurable reasoning effort with `low`, `medium`, and `high`,
  plus text input/output modality.
  
  The display names, default reasoning effort, and priority ordering are
  Codex-local catalog choices.
  
  ## Test Plan
  - Manually verified app-server model listing with an AWS profile:
  
  ```shell
  CODEX_HOME="$(mktemp -d)" cargo run -p codex-app-server-test-client -- \
    --codex-bin ./target/debug/codex \
    -c 'model_provider="amazon-bedrock"' \
    -c 'model_providers.amazon-bedrock.aws.profile="codex-bedrock"' \
    -c 'model_providers.amazon-bedrock.aws.region="us-west-2"' \
    model-list
  ```
  
  The response returned the Bedrock catalog with `openai.gpt-oss-120b-1:0`
  as the default model and `openai.gpt-oss-20b-1:0` as the second listed
  model, both text-only and supporting low/medium/high reasoning effort.

  Celia Chen · 2026-04-24 04:28:25 +00:00
  e8d8080818
• [rollout_trace] Add debug trace reduction command (#18880)

  ## Summary
  
  Adds the debug CLI entry point for reducing recorded rollout traces.
  This gives developers a direct way to inspect whether the emitted trace
  stream reduces into the expected conversation/runtime model.
  
  ## Stack
  
  This is PR 5/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is intentionally last: it depends on the trace crate, core
  recorder, runtime/tool events, and session/agent edge data all existing.
  The command should remain a debug/developer tool and avoid adding new
  runtime behavior.
  
  The useful review question is whether the CLI exposes the reducer in the
  smallest practical way for local inspection without turning the debug
  command into a supported user-facing workflow.

  cassirer-openai · 2026-04-24 01:56:48 +00:00
  e3c8720a99
• refactor: route Codex auth through AuthProvider (#18811)

  ## Summary
  
  This PR moves Codex backend request authentication from direct
  bearer-token handling to `AuthProvider`.
  
  The new `codex-auth-provider` crate defines the shared request-auth
  trait. `CodexAuth::provider()` returns a provider that can apply all
  headers needed for the selected auth mode.
  
  This lets ChatGPT token auth and AgentIdentity auth share the same
  callsite path:
  - ChatGPT token auth applies bearer auth plus account/FedRAMP headers
  where needed.
  - AgentIdentity auth applies AgentAssertion plus account/FedRAMP headers
  where needed.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Callsite Migration
  
  | Area | Change |
  | --- | --- |
  | backend-client | accepts an `AuthProvider` instead of a raw
  token/header |
  | chatgpt client/connectors | applies auth through
  `CodexAuth::provider()` |
  | cloud tasks | keeps Codex-backend gating, applies auth through
  provider |
  | cloud requirements | uses Codex-backend auth checks and provider
  headers |
  | app-server remote control | applies provider headers for backend calls
  |
  | MCP Apps/connectors | gates on `uses_codex_backend()` and keys caches
  from generic account getters |
  | model refresh | treats AgentIdentity as Codex-backend auth |
  | OpenAI file upload path | rejects non-Codex-backend auth before
  applying headers |
  | core client setup | keeps model-provider auth flow and allows
  AgentIdentity through provider-backed OpenAI auth |
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. This PR: migrate Codex backend auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-23 17:14:02 -07:00
  5882f3f95e
• [rollout_trace] Trace tool and code-mode boundaries (#18878)

  ## Summary
  
  Extends rollout tracing across tool dispatch and code-mode runtime
  boundaries. This records canonical tool-call lifecycle events and links
  code-mode execution/wait operations back to the model-visible calls that
  caused them.
  
  ## Stack
  
  This is PR 3/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is about attribution. Reviewers should focus on whether direct
  tool calls, code-mode-originated tool calls, waits, outputs, and
  cancellation boundaries are recorded with enough source information for
  deterministic reduction without coupling the reducer to live runtime
  internals.
  
  The stack remains valid after this layer: tool and code-mode traces
  reduce through the existing crate model, while the broader session and
  multi-agent relationships are added in the next PR.

  cassirer-openai · 2026-04-23 12:22:11 -07:00
  6d09b6752d
• Move marketplace add/remove and startup sync out of core. (#19099)

  Move more things to core-plugins.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-23 11:27:17 -07:00
  198eddd25d
• app-server: add Unix socket transport (#18255)

  ## Summary
  - add unix:// app-server transport backed by the shared codex-uds crate
  - reuse the websocket connection loop for axum and tungstenite-backed
  streams
  - add codex app-server proxy to bridge stdio clients to the control
  socket
  - tolerate Windows UDS backends that report a missing rendezvous path as
  connection refused before binding
  
  ## Tests
  - cargo test -p codex-app-server
  control_socket_acceptor_forwards_websocket_text_messages_and_pings
  - cargo test -p codex-app-server
  - just fmt
  - just fix -p codex-app-server
  - git -c core.fsmonitor=false diff --check

  Ruslan Nigmatullin · 2026-04-23 11:09:25 -07:00
  8a0ab3fc13