104 Commits

• [codex] Load user instructions through an injected provider (#27101)

  ## Why
  
  We want to remove implicit use of `$CODEX_HOME` from `codex-core` and
  make embedders responsible for supplying user-level instructions. This
  also ensures user instructions load when no primary environment is
  selected.
  
  ## What changed
  
  Stacked on #27415, which makes `codex exec` surface thread-scoped
  runtime warnings.
  
  - Added `UserInstructionsProvider` to `codex-extension-api`, with
  absolute source attribution and recoverable loading warnings.
  - Added `codex-home` with the filesystem-backed provider for
  `AGENTS.override.md` and `AGENTS.md`, preserving precedence, fallback,
  trimming, lossy UTF-8 handling, and the existing uncapped global
  instruction size.
  - Removed global instruction loading from `Config` and require
  `ThreadManager` callers to inject a provider.
  - Load provider instructions once for each fresh root runtime, including
  runtimes without a primary environment. Running sessions retain their
  snapshot, while child agents inherit the parent snapshot without
  invoking the provider.
  - Keep provider instructions separate while loading project `AGENTS.md`,
  then assemble the model-visible instructions with the existing ordering,
  source attribution, warning, and turn-context behavior.
  - Wired the Codex home provider through the CLI, app server, MCP server,
  core facade, and thread-manager sample.
  
  ## Validation
  
  - `just test -p codex-home -p codex-extension-api`
  - `just test -p codex-core agents_md`
  - `just test -p codex-core guardian`
  - `just test -p codex-app-server
  thread_start_without_selected_environment_includes_only_global_instruction_source`
  - `just test -p codex-exec warning`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 19:28:47 +00:00
  236b50125d
• [codex] migrate ExecutorFileSystem paths to PathUri (#27424)

  ## Why
  
  We're moving exec-server to use PathUri for its internal path
  representations.
  
  ## What
  
  Move `ExecutorFileSystem` APIs to use `PathUri` instead of
  `AbsolutePathBuf`. Future changes will convert higher-level parts of
  exec-server.

  Adam Perry @ OpenAI · 2026-06-11 18:44:18 +00:00
  b2a4e3be27
• Pair thread environment settings (#26687)

  ## Why
  
  Thread cwd and environment selections are a single logical setting in
  core: updating one without the other can silently desynchronize the
  next-turn execution context. This change makes that relationship
  explicit in the internal thread settings flow while preserving the
  existing app-server public API shape.
  
  ## What changed
  
  - Moved the cwd/environment pair through internal
  `ThreadSettingsOverrides.environment_settings` instead of a top-level
  internal `cwd` field.
  - Kept `thread/settings/update` public params unchanged, with app-server
  translating top-level `cwd` into the paired internal settings shape.
  - Moved `Op::UserInput` environment overrides into thread settings so
  user turns and settings updates use the same core path.
  - Updated core, app-server, MCP, memories, sample, and test callsites to
  construct the paired settings shape.
  
  ## Verification
  
  - `git diff --check`
  - Local test run starting after PR creation.

  pakrym-oai · 2026-06-08 13:55:15 -07:00
  f3c1283411
• [codex] Use standalone tools for Responses Lite (#26490)

  ## Summary
  
  Responses Lite does not execute hosted Responses tools, so models using
  it must route web search and image generation through Codex-owned
  executors & standalone Response's API endpoints.
  
  This PR is stacked on #26487.
  
  ## Validation
  
  - `cargo test -p codex-core responses_lite_ --lib`
  - `cargo test -p codex-core
  standalone_executors_remain_hidden_without_flags_or_responses_lite
  --lib`
  - `cargo test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates --lib`
  - `cargo test -p codex-web-search-extension -p
  codex-image-generation-extension`
  - `cargo test -p codex-app-server --test all standalone_`
  - `cargo fmt --all -- --check`

  rka-oai · 2026-06-06 00:23:40 +00:00
  ffe90cb5c3
• Require absolute cwd in thread settings (#26532)

  ## Why
  
  Thread settings cwd overrides are expected to be resolved before they
  enter core. Keeping this boundary as a plain `PathBuf` made it easy for
  core/session code to keep fallback normalization and relative-path
  resolution logic in places that should only receive an already-resolved
  cwd.
  
  This is intentionally the absolute-cwd-only slice: it does not change
  environment selection stickiness or cwd-to-default-environment fallback
  behavior.
  
  ## What changed
  
  - Changes `ThreadSettingsOverrides.cwd`,
  `CodexThreadSettingsOverrides.cwd`, and `SessionSettingsUpdate.cwd` to
  use `AbsolutePathBuf`.
  - Removes core-side cwd normalization/resolution from session settings
  updates.
  - Updates affected core/app-server test helpers and callsites to pass
  existing absolute cwd values or use `abs()` helpers.
  
  ## Validation
  
  Opening as draft so CI can start while local validation continues.

  pakrym-oai · 2026-06-05 09:29:15 -07:00
  40c8f1a007
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• Add experimental turn additional context (#24154)

  ## Summary
  
  Adds experimental `additionalContext` support to `turn/start` and
  `turn/steer` so clients can provide ephemeral external context, such as
  browser or automation state, without turning that plumbing into a
  visible user prompt or triggering user-prompt lifecycle behavior.
  
  ## API Shape
  
  The parameter shape is:
  
  ```ts
  additionalContext?: Record<string, {
    value: string
    kind: "untrusted" | "application"
  }> | null
  ```
  
  Example:
  
  ```json
  {
    "additionalContext": {
      "browser_info": {
        "value": "Active tab is CI failures.",
        "kind": "untrusted"
      },
      "automation_info": {
        "value": "CI rerun is in progress.",
        "kind": "application"
      }
    }
  }
  ```
  
  The keys are opaque and caller-defined.
  
  ## Context Injection
  
  When provided, accepted entries are inserted into model context as
  hidden contextual message items, not as visible thread user-message
  items.
  
  `kind: "untrusted"` entries are inserted with role `user`:
  
  ```text
  <external_${key}>${value}</external_${key}>
  ```
  
  `kind: "application"` entries are inserted with role `developer`:
  
  ```text
  <${key}>${value}</${key}>
  ```
  
  Values are not escaped. Each value is truncated to 1k approximate tokens
  before wrapping.
  
  For `turn/start`, accepted additional context is inserted before normal
  user input. For `turn/steer`, additional context is merged only when the
  steer includes non-empty user input; context-only steers still reject as
  empty input.
  
  ## Dedupe Strategy
  
  `AdditionalContextStore` lives on session state and stores the latest
  complete additional-context map.
  
  Each `turn/start` or non-empty `turn/steer` treats its
  `additionalContext` as the current complete set of values. Entries are
  injected only when the key is new or the exact entry for that key
  changed, including `value` or `kind`. After merging, the store is
  replaced with the provided map, so omitted keys are removed from the
  retained set and can be injected again later if reintroduced.
  
  Omitting `additionalContext`, passing `null`, or passing an empty object
  resets the store to empty and injects nothing.
  
  ## What Changed
  
  - Threads experimental v2 `additionalContext` through app-server into
  core turn start and steer handling.
  - Adds separate contextual fragment types for untrusted user-role
  context and application developer-role context.
  - Uses pending response input items so additional context can be
  combined with normal user input without treating it as prompt text.
  - Adds integration coverage for start/steer flow, role routing,
  dedupe/reset behavior, deletion/re-add behavior, hook-blocked input
  behavior, empty context-only steer rejection, external-fragment marker
  matching, and truncation.

  pakrym-oai · 2026-05-26 13:02:34 -07:00
  768848ab6f
• Honor client-resolved service tier defaults (#23537)

  ## Why
  
  Model catalog responses can now advertise a nullable
  `default_service_tier` for each model. Codex needs to preserve three
  distinct states all the way from config/app-server inputs to inference:
  
  - no explicit service tier, so the client may apply the current model
  catalog default when FastMode is enabled
  - explicit `default`, meaning the user intentionally wants standard
  routing
  - explicit catalog tier ids such as `priority`, `flex`, or future tiers
  
  Keeping those states distinct prevents the UI from showing one tier
  while core sends another, especially after model switches or app-server
  `thread/start` / `turn/start` updates.
  
  ## What Changed
  
  - Plumbed `default_service_tier` through model catalog protocol types,
  app-server model responses, generated schemas, model cache fixtures, and
  provider/model-manager conversions.
  - Added the request-only `default` service tier sentinel and normalized
  legacy config spelling so `fast` in `config.toml` still materializes as
  the runtime/request id `priority`.
  - Moved catalog default resolution to the TUI/client side, including
  recomputing the effective service tier when model/FastMode-dependent
  surfaces change.
  - Updated app-server thread lifecycle config construction so
  `serviceTier: null` preserves explicit standard-routing intent by
  mapping to `default` instead of internal `None`.
  - Kept core responsible for validating explicit tiers against the
  current model and stripping `default` before `/v1/responses`, without
  applying catalog defaults itself.
  
  ## Validation
  
  - `CARGO_INCREMENTAL=0 cargo build -p codex-cli`
  - `CARGO_INCREMENTAL=0 cargo test -p codex-app-server model_list`
  - `cargo test -p codex-tui service_tier`
  - `cargo test -p codex-protocol service_tier_for_request`
  - `cargo test -p codex-core get_service_tier`
  - `RUST_MIN_STACK=8388608 CARGO_INCREMENTAL=0 cargo test -p codex-core
  service_tier`

  Shijie Rao · 2026-05-20 15:57:50 -07:00
  370b13afc9
• Make local environment optional in EnvironmentManager (#23369)

  ## Summary
  - make `EnvironmentManager` local environment/runtime paths optional
  - simplify constructor surface around snapshot materialization
  - rename local env accessors to `require_local_environment` /
  `try_local_environment`
  
  ## Validation
  - devbox Bazel build for touched crate surfaces
  - `//codex-rs/exec-server:exec-server-unit-tests`
  - `//codex-rs/app-server-client:app-server-client-unit-tests`
  - filtered touched `//codex-rs/core:core-unit-tests` cases

  starr-openai · 2026-05-19 12:55:34 -07:00
  5c43a64e2b
• [3 of 7] Remove UserTurn (#23075)

  **Stack position:** [3 of 7]
  
  ## Summary
  
  This PR finishes the input-op consolidation by moving the remaining
  `Op::UserTurn` callers onto `Op::UserInput` and deleting `Op::UserTurn`.
  This touches a lot of files, but it is a low-risk mechanical migration.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075) (this PR)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 19:56:00 -07:00
  1a25d8b6e5
• [codex] Remove legacy shell output formatting paths (#22706)

  ## Why
  
  The client and tool pipeline still carried compatibility code for legacy
  structured shell output. Current shell and apply_patch responses are
  already plain text for model consumption, so keeping a
  JSON-serialization path plus shell-item rewrite logic makes the request
  formatter and tests preserve a format we do not need anymore.
  
  ## What Changed
  
  - Removed the client-side shell output rewrite from
  `core/src/client_common.rs`.
  - Removed the structured exec-output formatter and the shell `freeform`
  switch so tool emitters use one model-facing formatter.
  - Collapsed apply_patch/shell serialization tests around the remaining
  plain-text output expectations and removed duplicate one-variant
  parameterized cases.
  - Kept the `ApplyPatchModelOutput::ShellCommandViaHeredoc` compatibility
  input shape, but no longer treats it as a separate output-format mode.
  
  ## Validation
  
  - `cargo test -p codex-core client_common`
  - `cargo test -p codex-core shell_serialization`
  - `cargo test -p codex-core apply_patch_cli`
  - `just fix -p codex-core`
  
  ## Documentation
  
  No external Codex documentation update is needed.

  pakrym-oai · 2026-05-18 09:57:54 -07:00
  82061660ae
• chore(features) rm Feature::ApplyPatchFreeform (#22711)

  ## Summary
  Removes the feature since this is effectively on by default in all cases
  where we should use it, or can be configured via models.json.
  
  ## Testing
  - [x] unit tests pass

  Dylan Hurd · 2026-05-14 16:15:56 -07:00
  51b0e94105
• Fix remote environment test fixtures (#22572)

  ## Why
  The Docker remote-env coverage was failing before it reached the
  behavior those tests are meant to exercise. The remote-aware test
  fixture only registered the remote environment, so tests that
  intentionally select both `local` and `remote` could not start a turn.
  After that was fixed, two tests exposed stale fixtures: the approval
  test was auto-approving under workspace-write, and the remote
  `view_image` test was writing invalid PNG bytes.
  
  ## What Changed
  - Added `EnvironmentManager::create_for_tests_with_local(...)` so tests
  can keep the provider default while also selecting `local` explicitly.
  - Updated `build_remote_aware()` to use that test-only manager when a
  remote exec-server URL is present.
  - Changed the remote apply-patch approval helper to use
  `SandboxPolicy::new_read_only_policy()` so the test actually exercises
  approval caching per environment.
  - Replaced the hardcoded remote `view_image` PNG blob with the existing
  `png_bytes(...)` helper so the test uses a valid image fixture.
  
  ## Validation
  Ran these isolated Docker remote-env tests on the devbox with
  `$remote-tests` setup:
  -
  `suite::remote_env::apply_patch_freeform_routes_to_selected_remote_environment`
  -
  `suite::remote_env::apply_patch_approvals_are_remembered_per_environment`
  -
  `suite::remote_env::apply_patch_intercepted_exec_command_routes_to_selected_remote_environment`
  -
  `suite::remote_env::exec_command_routes_to_selected_remote_environment`
  - `suite::view_image::view_image_routes_to_selected_remote_environment`
  
  All five pass.

  starr-openai · 2026-05-14 12:40:01 -07:00
  255748638c
• [codex] Remove unused legacy shell tools (#22246)

  ## Why
  
  Recent session history showed no active use of the raw `shell`,
  `local_shell`, or `container.exec` execution surfaces. Keeping those
  handlers/specs wired into core leaves duplicate shell execution paths
  alongside the supported `shell_command` and unified exec tools.
  
  ## What changed
  
  - Removed the raw `shell` handler/spec and its `ShellToolCallParams`
  protocol helper.
  - Removed the legacy `local_shell` and `container.exec` handler/spec
  plumbing while preserving persisted-history compatibility for old
  response items.
  - Normalized model/config `default` and `local` shell selections to
  `shell_command`.
  - Pruned tests that exercised removed raw-shell/local-shell/apply-patch
  variants and kept coverage on `shell_command`, unified exec, and
  freeform `apply_patch`.
  
  ## Verification
  
  - `git diff --check`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::handlers::shell`
  - `cargo test -p codex-core tools::spec`
  - `cargo test -p codex-core tools::router`
  - `cargo test -p codex-core
  active_call_preserves_triggering_command_context`
  - `cargo test -p codex-core guardian_tests`
  - `cargo test -p codex-core --test all shell_serialization`
  - `cargo test -p codex-core --test all apply_patch_cli`
  - `cargo test -p codex-core --test all shell_command_`
  - `cargo test -p codex-core --test all local_shell`
  - `cargo test -p codex-core --test all otel::`
  - `cargo test -p codex-core --test all hooks::`
  - `just fix -p codex-core`
  - `just fix -p codex-tools`

  pakrym-oai · 2026-05-13 16:43:25 +00:00
  83decfa300
• extension: wire extension registries into sessions (#21737)

  ## Why
  
  [#21736](https://github.com/openai/codex/pull/21736) introduces the
  typed extension API, but the runtime does not yet carry a registry
  through thread/session startup or give contributors host-owned stores to
  read from. This PR wires that host-side path so later feature migrations
  can move product-specific behavior behind typed contributions without
  adding another bespoke seam directly to `codex-core`.
  
  ## What changed
  
  - Thread `ExtensionRegistry<Config>` through `ThreadManager`,
  `CodexSpawnArgs`, `Session`, and sub-agent spawn paths.
  - Wire `ThreadStartContributor` and `ContextContributor`
  - Expose the small supporting surface needed by non-core callers that
  construct threads directly, including `empty_extension_registry()`
  through `codex-core-api`.
  
  This PR lands the host plumbing only: the app-server registry is still
  empty, and concrete feature migrations are intended to follow
  separately.

  jif-oai · 2026-05-11 11:38:18 +02:00
  436c0df658
• tests: cover sandbox link write behavior (#21819)

  ## Why
  
  [PR #1705](https://github.com/openai/codex/pull/1705) moved
  `apply_patch` execution under the configured sandbox and called out the
  need for integration coverage. We already covered textual `../` escapes,
  but did not have coverage for link aliases that live inside a writable
  workspace while pointing at, or aliasing, files visible outside it.
  
  This PR locks in the current sandbox boundary without changing
  production write semantics. Symlink escapes into a read-only outside
  root should fail and leave the outside file unchanged. Existing hard
  links are characterized separately: if a user-created hard link already
  exists inside the writable root, sandboxed writes preserve normal
  hard-link semantics rather than replacing the link and silently breaking
  that relationship.
  
  ## What Changed
  
  - Added
  `apply_patch_cli_does_not_write_through_symlink_escape_outside_workspace`
  to verify `apply_patch` cannot update a symlink that targets a file
  outside the writable workspace.
  - Added `apply_patch_cli_preserves_existing_hard_link_outside_workspace`
  to verify `apply_patch` intentionally writes through an existing hard
  link and does not unlink or replace it.
  - Added `file_system_sandboxed_write_preserves_existing_hard_link` to
  verify sandboxed `fs/writeFile` preserves an existing hard link and
  writes the shared inode.
  
  ## Testing
  
  - `cargo test -p codex-exec-server file_system_sandboxed_write`
  - `cargo test -p codex-core
  apply_patch_cli_does_not_write_through_symlink_escape_outside_workspace`
  - `cargo test -p codex-core
  apply_patch_cli_preserves_existing_hard_link_outside_workspace`
  - `just fix -p codex-exec-server -p codex-core`
  - `just fix -p codex-core`
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21819).
  * #21845
  * __->__ #21819

  Michael Bolin · 2026-05-09 08:28:15 -07:00
  0c70698e24
• [codex] Delete function-style apply_patch (#21651)

  ## Why
  
  `apply_patch` is now a freeform/custom tool. Keeping the old
  JSON/function-style registration and parsing path left another way for
  models and tests to invoke `apply_patch`, which made the tool surface
  harder to reason about.
  
  ## What changed
  
  - Removed the `ApplyPatchToolType::Function` variant, JSON `apply_patch`
  spec, and handler support for function payloads.
  - Kept `apply_patch_tool_type = freeform` as the supported model
  metadata path, including Bedrock catalog metadata.
  - Migrated `apply_patch` tests and SSE fixtures to custom/freeform tool
  calls.
  
  ## Verification
  
  - `cargo test -p codex-tools -p codex-protocol -p codex-model-provider`
  - `cargo test -p codex-core tools::handlers::apply_patch --lib`
  - `cargo test -p codex-core --test all
  apply_patch_tool_executes_and_emits_patch_events`
  - `cargo test -p codex-core --test all
  apply_patch_reports_parse_diagnostics`
  - `cargo test -p codex-exec test_apply_patch_tool`
  - `just fix -p codex-core`
  - `just fix -p codex-tools -p codex-protocol -p codex-model-provider -p
  codex-exec`

  pakrym-oai · 2026-05-08 13:00:57 -07:00
  e783341b70
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343
• Add CODEX_HOME environments TOML provider (#20666)

  ## Why
  
  After stdio transports and provider-owned defaults exist, Codex needs a
  config-backed provider that can describe more than the single legacy
  `CODEX_EXEC_SERVER_URL` remote. This PR adds that provider without
  activating it in product entrypoints yet, keeping parser/validation
  review separate from runtime wiring.
  
  **Stack position:** this is PR 4 of 5. It builds on PR 3's
  provider/default model and adds the `environments.toml` provider used by
  PR 5.
  
  ## What Changed
  
  - Add `environment_toml.rs` as the TOML-specific home for parsing,
  validation, and provider construction.
  - Keep the TOML schema/provider structs private; the public constructor
  added here is `EnvironmentManager::from_codex_home(...)`.
  - Add `TomlEnvironmentProvider`, including validation for:
    - reserved ids such as `local` and `none`
    - duplicate ids
    - unknown explicit defaults
    - empty programs or URLs
    - exactly one of `url` or `program` per configured environment
  - Support websocket environments with `url = "ws://..."` / `wss://...`.
  - Support stdio-command environments with `program = "..."`.
  - Add helpers to load `environments.toml` from `CODEX_HOME`, but do not
  wire entrypoints to call them yet.
  - Add the `toml` dependency for parsing.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - **4. This PR:** https://github.com/openai/codex/pull/20666 - Add
  CODEX_HOME environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack.
  
  ## Documentation
  
  This introduces the config shape for `environments.toml`; user-facing
  documentation should be added before this stack is treated as a
  documented public workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:37:47 +00:00
  07b695190f
• 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
• 2- Use string service tiers in session protocol (#20971)

  ## Summary
  - break service tier session/op/app-server protocol fields from the
  closed enum to string tier ids
  - send the service tier string directly through model requests, prewarm,
  compaction, memories, and TUI/app-server turn starts
  - regenerate app-server protocol JSON/TypeScript schemas, removing the
  standalone ServiceTier TS enum
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-app-server -p codex-tui
  - just write-app-server-schema
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-06 18:00:21 +03:00
  be1d3cff93
• Move installation ID resolution out of core startup (#21182)

  ## Summary
  
  - resolve or inject the installation ID before core startup and pass it
  through `ThreadManager`, `CodexSpawnArgs`, and `Session` as a plain
  `String`
  - keep child sessions on the parent installation ID instead of
  rediscovering it inside core
  - propagate installation ID startup failures in `mcp-server` instead of
  panicking
  
  ## Why
  
  Core was still touching the filesystem on the session startup path to
  discover `installation_id`. This moves that work to the outer host
  boundary so core no longer depends on `codex_home` reads during session
  construction.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:54 +00:00
  8f3bb355f4
• 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
• state: pass state db handles through consumers (#20561)

  ## Why
  
  SQLite state was still being opened from consumer paths, including lazy
  `OnceCell`-backed thread-store call sites. That let one process
  construct multiple state DB connections for the same Codex home, which
  makes SQLite lock contention and `database is locked` failures much
  easier to hit.
  
  State DB lifetime should be chosen by main-like entrypoints and tests,
  then passed through explicitly. Consumers should use the supplied
  `Option<StateDbHandle>` or `StateDbHandle` and keep their existing
  filesystem fallback or error behavior when no handle is available.
  
  The startup path also needs to keep the rollout crate in charge of
  SQLite state initialization. Opening `codex_state::StateRuntime`
  directly bypasses rollout metadata backfill, so entrypoints should
  initialize through `codex_rollout::state_db` and receive a handle only
  after required rollout backfills have completed.
  
  ## What Changed
  
  - Initialize the state DB in main-like entrypoints for CLI, TUI,
  app-server, exec, MCP server, and the thread-manager sample.
  - Pass `Option<StateDbHandle>` through `ThreadManager`,
  `LocalThreadStore`, app-server processors, TUI app wiring, rollout
  listing/recording, personality migration, shell snapshot cleanup,
  session-name lookup, and memory/device-key consumers.
  - Remove the lazy local state DB wrapper from the thread store so
  non-test consumers use only the supplied handle or their existing
  fallback path.
  - Make `codex_rollout::state_db::init` the local state startup path: it
  opens/migrates SQLite, runs rollout metadata backfill when needed, waits
  for concurrent backfill workers up to a bounded timeout, verifies
  completion, and then returns the initialized handle.
  - Keep optional/non-owning SQLite helpers, such as remote TUI local
  reads, as open-only paths that do not run startup backfill.
  - Switch app-server startup from direct
  `codex_state::StateRuntime::init` to the rollout state initializer so
  app-server cannot skip rollout backfill.
  - Collapse split rollout lookup/list APIs so callers use the normal
  methods with an optional state handle instead of `_with_state_db`
  variants.
  - Restore `getConversationSummary(ThreadId)` to delegate through
  `ThreadStore::read_thread` instead of a LocalThreadStore-specific
  rollout path special case.
  - Keep DB-backed rollout path lookup keyed on the DB row and file
  existence, without imposing the filesystem filename convention on
  existing DB rows.
  - Verify readable DB-backed rollout paths against `session_meta.id`
  before returning them, so a stale SQLite row that points at another
  thread's JSONL falls back to filesystem search and read-repairs the DB
  row.
  - Keep `debug prompt-input` filesystem-only so a one-off debug command
  does not initialize or backfill SQLite state just to print prompt input.
  - Keep goal-session test Codex homes alive only in the goal-specific
  helper, rather than leaking tempdirs from the shared session test
  helper.
  - Update tests and call sites to pass explicit state handles where DB
  behavior is expected and explicit `None` where filesystem-only behavior
  is intended.
  
  ## Validation
  
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo check -p
  codex-rollout -p codex-thread-store -p codex-app-server -p codex-core -p
  codex-tui -p codex-exec -p codex-cli --tests`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout state_db_`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout find_thread_path`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout find_thread_path -- --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout try_init_ -- --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo clippy -p
  codex-rollout --lib -- -D warnings`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-thread-store
  read_thread_falls_back_when_sqlite_path_points_to_another_thread --
  --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-thread-store`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  shell_snapshot`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all personality_migration`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all rollout_list_find`
  - `RUST_MIN_STACK=8388608 CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all rollout_list_find::find_prefers_sqlite_path_by_id --
  --nocapture`
  - `RUST_MIN_STACK=8388608 CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all rollout_list_find -- --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  interrupt_accounts_active_goal_before_pausing`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-app-server get_auth_status -- --test-threads=1`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-app-server --lib`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo check -p codex-rollout
  -p codex-app-server --tests`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p codex-rollout
  -p codex-thread-store -p codex-core -p codex-app-server -p codex-tui -p
  codex-exec -p codex-cli`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p codex-rollout -p
  codex-app-server`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p
  codex-rollout`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p codex-core`
  - `just argument-comment-lint -p codex-core`
  - `just argument-comment-lint -p codex-rollout`
  
  Focused coverage added in `codex-rollout`:
  
  - `recorder::tests::state_db_init_backfills_before_returning` verifies
  the rollout metadata row exists before startup init returns.
  - `state_db::tests::try_init_waits_for_concurrent_startup_backfill`
  verifies startup waits for another worker to finish backfill instead of
  disabling the handle for the process.
  -
  `state_db::tests::try_init_times_out_waiting_for_stuck_startup_backfill`
  verifies startup does not hang indefinitely on a stuck backfill lease.
  -
  `tests::find_thread_path_accepts_existing_state_db_path_without_canonical_filename`
  verifies DB-backed lookup accepts valid existing rollout paths even when
  the filename does not include the thread UUID.
  -
  `tests::find_thread_path_falls_back_when_db_path_points_to_another_thread`
  verifies DB-backed lookup ignores a stale row whose existing path
  belongs to another thread and read-repairs the row after filesystem
  fallback.
  
  Focused coverage updated in `codex-core`:
  
  - `rollout_list_find::find_prefers_sqlite_path_by_id` now uses a
  DB-preferred rollout file with matching `session_meta.id`, so it still
  verifies that valid SQLite paths win without depending on stale/empty
  rollout contents.
  
  `cargo test -p codex-app-server thread_list_respects_search_term_filter
  -- --test-threads=1 --nocapture` was attempted locally but timed out
  waiting for the app-server test harness `initialize` response before
  reaching the changed thread-list code path.
  
  `bazel test //codex-rs/thread-store:thread-store-unit-tests
  --test_output=errors` was attempted locally after the thread-store fix,
  but this container failed before target analysis while fetching `v8+`
  through BuildBuddy/direct GitHub. The equivalent local crate coverage,
  including `cargo test -p codex-thread-store`, passes.
  
  A plain local `cargo check -p codex-rollout -p codex-app-server --tests`
  also requires system `libcap.pc` for `codex-linux-sandbox`; the
  follow-up app-server check above used `CODEX_SKIP_VENDORED_BWRAP=1` in
  this container.

  Ruslan Nigmatullin · 2026-05-04 11:46:03 -07:00
  4d201e340e
• Make thread store process-scoped (#19474)

  - Build one app-server process ThreadStore from startup config and share
  it with ThreadManager and CodexMessageProcessor.
  - Remove per-thread/fork store reconstruction so effective thread config
  cannot switch the persistence backend.
  - Add params to ThreadStore create/resume for specifying thread
  metadata, since otherwise the metadata from store creation would be used
  (incorrectly).

  Tom · 2026-04-30 21:24:59 -07:00
  fe05acad23
• 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 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
• Add environment provider snapshot (#20058)

  ## Summary
  - Change `EnvironmentProvider` to return concrete `Environment`
  instances instead of `EnvironmentConfigurations`.
  - Make `DefaultEnvironmentProvider` provide the provider-visible `local`
  environment plus optional `remote` environment from
  `CODEX_EXEC_SERVER_URL`.
  - Keep `EnvironmentManager` as the concrete cache while exposing its own
  explicit local environment for `local_environment()` fallback paths.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-28 20:05:18 -07:00
  e1ec9e63a0
• core tests: build user turns from permission profiles (#20011)

  ## Summary
  - Add `turn_permission_fields()` so tests that construct `Op::UserTurn`
  directly can provide a canonical `PermissionProfile` while still filling
  the required legacy `sandbox_policy` compatibility field.
  - Migrate direct user-turn construction in core integration tests from
  `SandboxPolicy::DangerFullAccess` to `PermissionProfile::Disabled`.
  - Continue reducing direct `SandboxPolicy` usage in
  `codex-rs/core/tests`, from 41 files after #20010 to 32 files in this
  PR.
  
  ## Testing
  - `cargo check -p codex-core --tests`
  - `just fmt`
  - `just fix -p core_test_support`
  - `just fix -p codex-core`

  Michael Bolin · 2026-04-28 17:03:20 -07:00
  7d15936e69
• core tests: submit turns with permission profiles (#20010)

  ## Summary
  
  - Add `PermissionProfile`-based turn submission helpers to
  `core_test_support`, while keeping the legacy `SandboxPolicy` helper for
  tests that intentionally exercise legacy fallback behavior.
  - Switch the default `TestCodex::submit_turn()` path to send a real
  `PermissionProfile` plus the required legacy compatibility projection in
  `Op::UserTurn`.
  - Migrate straightforward app/search/shell/truncation tests from
  `SandboxPolicy::{DangerFullAccess, ReadOnly}` to
  `PermissionProfile::{Disabled, read_only}`.
  - Add a TUI compatibility projection helper for legacy app-server fields
  so non-legacy writable roots are preserved instead of being downgraded
  to read-only.
  - Fix remote start/resume/fork sandbox-mode projection to classify any
  managed profile with writable roots as workspace-write, not only
  profiles that can write `cwd`.
  - Reduce `SandboxPolicy` references in `codex-rs/core/tests` from 47
  files to 41 files without changing production behavior.
  
  ## Testing
  
  - `cargo check -p codex-core --tests`
  - `cargo test -p codex-tui
  compatibility_profile_preserves_unbridgeable_write_roots`
  - `cargo test -p codex-tui
  sandbox_mode_preserves_non_cwd_write_roots_for_remote_sessions`
  - `just fmt`
  - `just fix -p core_test_support`
  - `just fix -p codex-core`

  Michael Bolin · 2026-04-28 23:01:40 +00:00
  891722849d
• 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
• tui: carry permission profiles on user turns (#18285)

  ## Why
  
  Per-turn permission overrides should use the same canonical profile
  abstraction as session configuration. That lets TUI submissions preserve
  exact configured permissions without round-tripping through legacy
  sandbox fields.
  
  ## What changed
  
  This adds `permission_profile` to user-turn operations, threads it
  through TUI/app-server submission paths, fills the new field in existing
  test fixtures, and adds coverage that composer submission includes the
  configured profile.
  
  ## Verification
  
  - `cargo test -p codex-tui permissions -- --nocapture`
  - `cargo test -p codex-core --test all permissions_messages --
  --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18285).
  * #18288
  * #18287
  * #18286
  * __->__ #18285

  Michael Bolin · 2026-04-23 11:54:17 -07:00
  f90cc0ee64
• codex: support hooks in config.toml and requirements.toml (#18893)

  ## Summary
  
  Support the existing hooks schema in inline TOML so hooks can be
  configured from both `config.toml` and enterprise-managed
  `requirements.toml` without requiring a separate `hooks.json` payload.
  
  This gives enterprise admins a way to ship managed hook policy through
  the existing requirements channel while still leaving script delivery to
  MDM or other device-management tooling, and it keeps `hooks.json`
  working unchanged for existing users.
  
  This also lays the groundwork for follow-on managed filtering work such
  as #15937, while continuing to respect project trust gating from #14718.
  It does **not** implement `allow_managed_hooks_only` itself.
  
  NOTE: yes, it's a bit unfortunate that the toml isn't formatted as
  closely as normal to our default styling. This is because we're trying
  to stay compatible with the spec for plugins/hooks that we'll need to
  support & the main usecase here is embedding into requirements.toml
  
  ## What changed
  
  - moved the shared hook serde model out of `codex-rs/hooks` into
  `codex-rs/config` so the same schema can power `hooks.json`, inline
  `config.toml` hooks, and managed `requirements.toml` hooks
  - added `hooks` support to both `ConfigToml` and
  `ConfigRequirementsToml`, including requirements-side `managed_dir` /
  `windows_managed_dir`
  - treated requirements-managed hooks as one constrained value via
  `Constrained`, so managed hook policy is merged atomically and cannot
  drift across requirement sources
  - updated hook discovery to load requirements-managed hooks first, then
  per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning
  when a single layer defines both representations
  - threaded managed hook metadata through discovered handlers and exposed
  requirements hooks in app-server responses, generated schemas, and
  `/debug-config`
  - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`,
  `codex-rs/core/src/config_loader/tests.rs`, and
  `codex-rs/core/tests/suite/hooks.rs`
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server config_api`
  
  ## Documentation
  
  Companion updates are needed in the developers website repo for:
  
  - the hooks guide
  - the config reference, sample, basic, and advanced pages
  - the enterprise managed configuration guide
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Andrei Eternal · 2026-04-22 21:20:09 -07:00
  2b2de3f38b
• Add turn-scoped environment selections (#18416)

  ## Summary
  - add experimental turn/start.environments params for per-turn
  environment id + cwd selections
  - pass selections through core protocol ops and resolve them with
  EnvironmentManager before TurnContext creation
  - treat omitted selections as default behavior, empty selections as no
  environment, and non-empty selections as first environment/cwd as the
  turn primary
  
  ## Testing
  - ran `just fmt`
  - ran `just write-app-server-schema`
  - not run: unit tests for this stacked PR
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 17:48:33 -07:00
  1d4cc494c9
• Support multiple managed environments (#18401)

  ## Summary
  - refactor EnvironmentManager to own keyed environments with
  default/local lookup helpers
  - keep remote exec-server client creation lazy until exec/fs use
  - preserve disabled agent environment access separately from internal
  local environment access
  
  ## Validation
  - not run (per Codex worktree instruction to avoid tests/builds unless
  requested)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 15:29:35 -07:00
  ddbe2536be
• Update models.json (#18586)

  - Replace the active models-manager catalog with the deleted core
  catalog contents.
  - Replace stale hardcoded test model slugs with current bundled model
  slugs.
  - Keep this as a stacked change on top of the cleanup PR.

  Ahmed Ibrahim · 2026-04-20 10:27:01 -07:00
  316cf0e90b
• Stabilize Bazel tests (timeout tweaks and flake fixes) (#17791)
  David de Regt · 2026-04-16 07:57:51 -07:00
  6adba99f4d
• Reuse remote exec-server in core tests (#17837)

  ## Summary
  - reuse a shared remote exec-server for remote-aware codex-core
  integration tests within a test binary process
  - keep per-test remote cwd creation and cleanup so tests retain
  workspace isolation
  - leave codex_self_exe, codex_linux_sandbox_exe, cwd_path(), and
  workspace_path() behavior unchanged
  
  ## Validation
  - rustfmt codex-rs/core/tests/common/test_codex.rs
  - git diff --check
  - CI is running on the updated branch

  starr-openai · 2026-04-14 20:42:03 -07:00
  e063596c67
• Stabilize exec-server filesystem tests in CI (#17671)

  ## Summary\n- add an exec-server package-local test helper binary that
  can run exec-server and fs-helper flows\n- route exec-server filesystem
  tests through that helper instead of cross-crate codex helper
  binaries\n- stop relying on Bazel-only extra binary wiring for these
  tests\n\n## Testing\n- not run (per repo guidance for codex changes)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-13 16:53:42 -07:00
  280a4a6d42
• 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
• Run exec-server fs operations through sandbox helper (#17294)

  ## Summary
  - run exec-server filesystem RPCs requiring sandboxing through a
  `codex-fs` arg0 helper over stdin/stdout
  - keep direct local filesystem execution for `DangerFullAccess` and
  external sandbox policies
  - remove the standalone exec-server binary path in favor of top-level
  arg0 dispatch/runtime paths
  - add sandbox escape regression coverage for local and remote filesystem
  paths
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - remote devbox: `cd codex-rs && bazel test --bes_backend=
  --bes_results_url= //codex-rs/exec-server:all` (6/6 passed)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-12 18:36:03 -07:00
  d626dc3895
• [codex-analytics] add compaction analytics event (#17155)

  - event for compaction analytics
  - introduces thread-connection and thread metadata caches for data
  denormalization, expected to be useful for denormalization onto core
  emitted events in general
  - threads analytics event client into core (mirrors approved
  implementation in #16640)
  - denormalizes key thread metadata: thread_source, subagent_source,
  parent_thread_id, as well as app-server client and runtime metadata)
  - compaction strategy defaults to memento, forward compatible with
  expected prefill_compaction strategy
  
  1. Manual standalone compact, local
  `INFO | 2026-04-09 17:35:50 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d0-5cfb-70c0-bef9-165c3bf9b2df', 'turn_id':
  '019d74d0-d7f6-7c81-acc6-aae2030243d6', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'manual', 'reason':
  'user_requested', 'implementation': 'responses', 'phase':
  'standalone_turn', 'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 20170, 'active_context_tokens_after':
  4830, 'started_at': 1775781337, 'completed_at': 1775781350,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 13524} | `
  
  2. Auto pre-turn compact, local
  `INFO | 2026-04-09 17:37:30 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d2-45ef-71d1-9c93-23cc0c13d988', 'turn_id':
  '019d74d2-7b42-7372-9f0e-c0da3f352328', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'auto', 'reason':
  'context_limit', 'implementation': 'responses', 'phase': 'pre_turn',
  'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 20063, 'active_context_tokens_after':
  4822, 'started_at': 1775781444, 'completed_at': 1775781449,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 5497} | `
  
  3. Auto mid-turn compact, local
  `INFO | 2026-04-09 17:38:28 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d3-212f-7a20-8c0a-4816a978675e', 'turn_id':
  '019d74d3-3ee1-7462-89f6-2ffbeefcd5e3', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'auto', 'reason':
  'context_limit', 'implementation': 'responses', 'phase': 'mid_turn',
  'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 20325, 'active_context_tokens_after':
  14641, 'started_at': 1775781500, 'completed_at': 1775781508,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 7507} | `
  
  4. Remote /responses/compact, manual standalone
  `INFO | 2026-04-09 17:40:20 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d4-7a11-78a1-89f7-0535a1149416', 'turn_id':
  '019d74d4-e087-7183-9c20-b1e40b7578c0', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'manual', 'reason':
  'user_requested', 'implementation': 'responses_compact', 'phase':
  'standalone_turn', 'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 23461, 'active_context_tokens_after':
  6171, 'started_at': 1775781601, 'completed_at': 1775781620,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 18971} | `

  rhan-oai · 2026-04-10 13:03:54 -07:00
  5779be314a
• Default realtime startup to v2 model (#17183)

  - Default realtime sessions to v2 and gpt-realtime-1.5 when no override
  is configured.
  - Add Op::RealtimeConversationStart integration coverage and keep
  v1-specific tests explicit.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-08 22:11:30 -07:00
  1fdb695e42
• [codex] Apply patches through executor filesystem (#17048)

  ## Summary
  - run apply_patch through the executor filesystem when a remote
  environment is present instead of shelling out to the local process
  - thread the executor FileSystem into apply_patch interception and keep
  existing local behavior for non-remote turns
  - make the apply_patch integration harness use the executor filesystem
  for setup/assertions
  - add remote-aware skips for turn-diff coverage that still reads the
  test-runner filesystem
  
  ## Why
  Remote apply_patch needed to mutate the remote workspace instead of the
  local checkout. The tests also needed to seed and assert workspace state
  through the same filesystem abstraction so local and remote runs
  exercise the same behavior.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - `cargo check -p core_test_support --tests`
  - `cargo test -p codex-core --test all
  suite::shell_serialization::apply_patch_custom_tool_call -- --nocapture`
  - `cargo test -p codex-core --test all
  suite::apply_patch_cli::apply_patch_cli_updates_file_appends_trailing_newline
  -- --nocapture`
  - remote `cargo test -p codex-core --test all apply_patch_cli --
  --nocapture` (229 passed)

  pakrym-oai · 2026-04-07 16:35:02 -07:00
  600c3e49e0
• Make AGENTS.md discovery FS-aware (#15826)

  ## Summary
  - make AGENTS.md discovery and loading fully FS-aware and remove the
  non-FS discover helper
  - migrate remote-aware codex-core tests to use TestEnv workspace setup
  instead of syncing a local workspace copy
  - add AGENTS.md corner-case coverage, including directory fallbacks and
  remote-aware integration coverage
  
  ## Testing
  - cargo test -p codex-core project_doc -- --nocapture
  - cargo test -p codex-core hierarchical_agents -- --nocapture
  - cargo test -p codex-core agents_md -- --nocapture
  - cargo test -p codex-tui status -- --nocapture
  - cargo test -p codex-tui-app-server status -- --nocapture
  - just fix
  - just fmt
  - just bazel-lock-update
  - just bazel-lock-check
  - just argument-comment-lint
  - remote Linux executor tests in progress via scripts/test-remote-env.sh

  pakrym-oai · 2026-04-06 20:26:21 -07:00
  4bb507d2c4
• remove temporary ownership re-exports (#16626)

  Stacked on #16508.
  
  This removes the temporary `codex-core` / `codex-login` re-export shims
  from the ownership split and rewrites callsites to import directly from
  `codex-model-provider-info`, `codex-models-manager`, `codex-api`,
  `codex-protocol`, `codex-feedback`, and `codex-response-debug-context`.
  
  No behavior change intended; this is the mechanical import cleanup layer
  split out from the ownership move.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-03 00:33:34 -07:00
  af8a9d2d2b
• extract models manager and related ownership from core (#16508)

  ## Summary
  - split `models-manager` out of `core` and add `ModelsManagerConfig`
  plus `Config::to_models_manager_config()` so model metadata paths stop
  depending on `core::Config`
  - move login-owned/auth-owned code out of `core` into `codex-login`,
  move model provider config into `codex-model-provider-info`, move API
  bridge mapping into `codex-api`, move protocol-owned types/impls into
  `codex-protocol`, and move response debug helpers into a dedicated
  `response-debug-context` crate
  - move feedback tag emission into `codex-feedback`, relocate tests to
  the crates that now own the code, and keep broad temporary re-exports so
  this PR avoids a giant import-only rewrite
  
  ## Major moves and decisions
  - created `codex-models-manager` as the owner for model
  cache/catalog/config/model info logic, including the new
  `ModelsManagerConfig` struct
  - created `codex-model-provider-info` as the owner for provider config
  parsing/defaults and kept temporary `codex-login`/`codex-core`
  re-exports for old import paths
  - moved `api_bridge` error mapping + `CoreAuthProvider` into
  `codex-api`, while `codex-login::api_bridge` temporarily re-exports
  those symbols and keeps the `auth_provider_from_auth` wrapper
  - moved `auth_env_telemetry` and `provider_auth` ownership to
  `codex-login`
  - moved `CodexErr` ownership to `codex-protocol::error`, plus
  `StreamOutput`, `bytes_to_string_smart`, and network policy helpers to
  protocol-owned modules
  - created `codex-response-debug-context` for
  `extract_response_debug_context`, `telemetry_transport_error_message`,
  and related response-debug plumbing instead of leaving that behavior in
  `core`
  - moved `FeedbackRequestTags`, `emit_feedback_request_tags`, and
  `emit_feedback_request_tags_with_auth_env` to `codex-feedback`
  - deferred removal of temporary re-exports and the mechanical import
  rewrites to a stacked follow-up PR so this PR stays reviewable
  
  ## Test moves
  - moved auth refresh coverage from `core/tests/suite/auth_refresh.rs` to
  `login/tests/suite/auth_refresh.rs`
  - moved text encoding coverage from
  `core/tests/suite/text_encoding_fix.rs` to
  `protocol/src/exec_output_tests.rs`
  - moved model info override coverage from
  `core/tests/suite/model_info_overrides.rs` to
  `models-manager/src/model_info_overrides_tests.rs`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-02 23:00:02 -07:00
  6fff9955f1
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• ci: sync Bazel clippy lints and fix uncovered violations (#16351)

  ## Why
  
  Follow-up to #16345, the Bazel clippy rollout in #15955, and the cleanup
  pass in #16353.
  
  `cargo clippy` was enforcing the workspace deny-list from
  `codex-rs/Cargo.toml` because the member crates opt into `[lints]
  workspace = true`, but Bazel clippy was only using `rules_rust` plus
  `clippy.toml`. That left the Bazel lane vulnerable to drift:
  `clippy.toml` can tune lint behavior, but it cannot set
  allow/warn/deny/forbid levels.
  
  This PR now closes both sides of the follow-up. It keeps `.bazelrc` in
  sync with `[workspace.lints.clippy]`, and it fixes the real clippy
  violations that the newly-synced Windows Bazel lane surfaced once that
  deny-list started matching Cargo.
  
  ## What Changed
  
  - added `.github/scripts/verify_bazel_clippy_lints.py`, a Python check
  that parses `codex-rs/Cargo.toml` with `tomllib`, reads the Bazel
  `build:clippy` `clippy_flag` entries from `.bazelrc`, and reports
  missing, extra, or mismatched lint levels
  - ran that verifier from the lightweight `ci.yml` workflow so the sync
  check does not depend on a Rust toolchain being installed first
  - expanded the `.bazelrc` comment to explain the Cargo `workspace =
  true` linkage and why Bazel needs the deny-list duplicated explicitly
  - fixed the Windows-only `codex-windows-sandbox` violations that Bazel
  clippy reported after the sync, using the same style as #16353: inline
  `format!` args, method references instead of trivial closures, removed
  redundant clones, and replaced SID conversion `unwrap` and `expect`
  calls with proper errors
  - cleaned up the remaining cross-platform violations the Bazel lane
  exposed in `codex-backend-client` and `core_test_support`
  
  ## Testing
  
  Key new test introduced by this PR:
  
  `python3 .github/scripts/verify_bazel_clippy_lints.py`

  Michael Bolin · 2026-03-31 17:09:48 -07:00
  2e942ce830
• fix: box apply_patch test harness futures (#15835)

  ## Why
  
  `#[large_stack_test]` made the `apply_patch_cli` tests pass by giving
  them more stack, but it did not address why those tests needed the extra
  stack in the first place.
  
  The real problem is the async state built by the `apply_patch_cli`
  harness path. Those tests await three helper boundaries directly:
  harness construction, turn submission, and apply-patch output
  collection. If those helpers inline their full child futures, the test
  future grows to include the whole harness startup and request/response
  path.
  
  This change replaces the workaround from #12768 with the same basic
  approach used in #13429, but keeps the fix narrower: only the helper
  boundaries awaited directly by `apply_patch_cli` stay boxed.
  
  ## What Changed
  
  - removed `#[large_stack_test]` from
  `core/tests/suite/apply_patch_cli.rs`
  - restored ordinary `#[tokio::test(flavor = "multi_thread",
  worker_threads = 2)]` annotations in that suite
  - deleted the now-unused `codex-test-macros` crate and removed its
  workspace wiring
  - boxed only the three helper boundaries that the suite awaits directly:
    - `apply_patch_harness_with(...)`
    - `TestCodexHarness::submit(...)`
    - `TestCodexHarness::apply_patch_output(...)`
  - added comments at those boxed boundaries explaining why they remain
  boxed
  
  ## Testing
  
  - `cargo test -p codex-core --test all suite::apply_patch_cli --
  --nocapture`
  
  ## References
  
  - #12768
  - #13429

  Michael Bolin · 2026-03-26 17:32:04 +00:00
  e36ebaa3da