199 Commits

• [codex] Add managed new-thread model settings (#29683)

  ## Why
  
  Admins need persistent defaults for the model, reasoning effort, and
  service tier shown when the Desktop App creates a new thread. These are
  initialization defaults rather than runtime constraints: the App should
  use them to initialize its draft while still allowing a user to make an
  explicit selection.
  
  The app-server therefore needs to expose the managed values before
  thread creation without changing `thread/start` behavior for other
  clients.
  
  ## What changed
  
  - Parse `model`, `model_reasoning_effort`, and `service_tier` from
  `[models.new_thread]` in `requirements.toml`.
  - Compose the `models` requirements through the existing
  requirements-layer precedence rules.
  - Expose the resolved values through `configRequirements/read` as
  `requirements.models.newThread`.
  - Add the corresponding app-server protocol types and regenerate the
  JSON and TypeScript schema fixtures.
  - Document the new `configRequirements/read` fields in the app-server
  README.
  
  ## Scope
  
  This PR is data plumbing only. It does not apply these values during
  `thread/start` and does not change thread creation for existing
  app-server clients, resumed or forked sessions, internal or subagent
  sessions, `codex exec`, or the TUI. A companion Desktop App change owns
  draft initialization, sends the effective settings for ordinary and
  prewarmed starts, and preserves explicit user changes.
  
  ## Validation
  
  - Requirements deserialization coverage for `[models.new_thread]`
  - Requirements-layer precedence coverage
  - App-server API mapping coverage
  - `configRequirements/read` integration coverage
  - Regenerated app-server JSON and TypeScript schema fixtures

  hefuc-oai · 2026-06-26 18:37:40 +00:00
  d9cf931d0e
• Relax hooks.json top-level metadata validation (#30229)

  ## Summary
  - Allow a top-level `description` string in `hooks.json`.
  - Continue rejecting unknown top-level keys and root-level hook events;
  events must remain under `hooks`.
  
  ## Testing
  - `just test -p codex-config`

  charlesgong-openai · 2026-06-26 11:24:12 -04:00
  2c5bc5e284
• [codex] Surface MCP reauthentication-required startup failures (#29877)

  ## Summary
  
  - distinguish expired, non-refreshable stored MCP OAuth credentials from
  first-time missing credentials
  - carry a typed `failureReason: "reauthenticationRequired"` on the
  existing `mcpServer/startupStatus/updated` notification only when user
  action is required
  - keep the public MCP auth-status API unchanged and regenerate the
  app-server protocol schemas and documentation
  
  ## Why
  
  An MCP server with an expired access token and no usable refresh token
  currently fails startup without giving clients a reliable, typed
  recovery signal.
  
  The existing startup-status notification is the natural place to carry
  this state. Its nullable `failureReason` keeps the recovery reason
  attached to the failed startup transition without adding a one-off
  notification. Internally, Codex distinguishes first-time login from
  reauthentication and emits the reason only when the startup error itself
  requires authentication.
  
  ## User impact
  
  App clients can prompt an existing user to reconnect an MCP server when
  automatic recovery is impossible by handling a failed
  `mcpServer/startupStatus/updated` notification whose `failureReason` is
  `reauthenticationRequired`. Starting, ready, cancelled, unrelated
  failures, and first-time setup carry no reauthentication reason.
  
  ## Companion app PR
  
  - openai/openai#1069582
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` — 248 passed; schema fixture
  tests passed
  - `cargo check -p codex-app-server -p codex-tui`
  - `just test -p codex-rmcp-client -p codex-mcp` — 184 passed, 2 skipped
  - `just test -p codex-protocol -p codex-app-server-protocol -p
  codex-mcp` — 579 passed
  - `just write-app-server-schema`
  - `just fmt`

  felixxia-oai · 2026-06-25 21:50:36 +00:00
  a6d20ed297
• [codex] Add managed MCP server matchers (#29648)

  ## Summary
  
  This PR extends the existing managed `mcp_servers` identity requirement
  so that one name-qualified rule can use either:
  
  - the released exact command or URL identity;
  - an exact stdio executable with an exact-length, ordered argument
  matcher list; or
  - a direct MCP URL matcher.
  
  Matcher-based rules stay under the released `identity` key and use the
  same `McpServerRequirement` abstraction and `mcp_servers.<server_name>`
  namespace.
  
  ## Behavior
  
  Policy activation and name qualification are unchanged:
  
  - If `mcp_servers` is absent, ordinary configured MCP servers remain
  unrestricted.
  - If `mcp_servers` is present, a server needs a matching same-name
  requirement.
  - `mcp_servers = {}` continues to deny every configured MCP server.
  - Existing exact identity requirements keep their released semantics.
  
  Plugin-bundled MCP servers use the same requirement shapes under
  `plugins.<plugin_name>.mcp_servers.<server_name>`. Top-level non-empty
  rules continue to govern only ordinary configured servers; plugin rules
  remain explicitly plugin-scoped. The existing globally empty
  `mcp_servers = {}` plugin kill switch is preserved.
  
  Requirements layers continue to use the existing regular TOML merge
  behavior. Atomic replacement of named MCP requirements is intentionally
  out of scope here and is tracked independently in #30118.
  
  ## Requirement contract
  
  The released exact identity contract remains valid:
  
  ```toml
  [mcp_servers.docs.identity]
  command = "codex-mcp"
  
  [mcp_servers.remote.identity]
  url = "https://example.com/mcp"
  ```
  
  Command identities continue to check only `command`; they do not inspect
  arguments, `cwd`, `env`, or `env_vars`.
  
  A command matcher uses an exact executable plus an exact-length, ordered
  argument list. Each argument position supports `exact`, `prefix`, or
  full-value `regex` matching:
  
  ```toml
  [mcp_servers.internal_mcp_proxy.identity]
  command = { executable = "company-cli", args = [
    { match = "exact", value = "mcp" },
    { match = "exact", value = "proxy" },
    { match = "exact", value = "--server" },
    { match = "regex", expression = '^https://[A-Za-z0-9-]+\.mcp\.internal\.example\.com(?::443)?(?:/.*)?$' },
  ] }
  ```
  
  Direct streamable HTTP MCP definitions can use the same value matcher
  types through `identity.url`:
  
  ```toml
  [mcp_servers.internal_http.identity]
  url = {
    match = "regex",
    expression = '^https://[A-Za-z0-9-]+\.mcp\.internal\.example\.com(?:/.*)?$',
  }
  ```
  
  Plugin-bundled MCP matchers use the same contract inside the
  plugin-qualified allowlist:
  
  ```toml
  [plugins."sample@test".mcp_servers.internal_mcp_proxy.identity]
  command = { executable = "company-cli", args = [
    { match = "exact", value = "mcp" },
    { match = "exact", value = "proxy" },
  ] }
  ```
  
  Regexes are validated while managed requirements are loaded, and regex
  matching must cover the complete value. Command matchers constrain only
  the executable and arguments.
  
  ## Why
  
  Enterprise administrators need to allow MCP servers by executable and
  positional-argument shape, including fixed arguments plus constrained
  values such as internal MCP URLs passed to a proxy.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `just test -p codex-config` (198 passed)
  - `just test -p codex-core mcp_servers_by_matchers --lib` (2 passed)

  felixxia-oai · 2026-06-25 22:15:50 +01:00
  db541f4553
• Represent MCP authentication with an enum (#29924)

  ## Why
  
  MCP authentication has distinct OAuth and ChatGPT-session flows.
  Representing that choice as `use_chatgpt_auth` makes one flow implicit
  and allows the configuration model to express the distinction only
  through a boolean.
  
  ChatGPT credential forwarding also needs a first-party trust boundary. A
  configurable `chatgpt_base_url` controls routing, but must not grant an
  MCP server permission to receive session credentials.
  
  This change builds on #29733, where the boolean was introduced.
  
  ## What changed
  
  - Replace `use_chatgpt_auth` with an `auth` field backed by the
  exhaustive `McpServerAuth` enum.
  - Support `auth = "oauth"` and `auth = "chatgpt"`, with OAuth remaining
  the default.
  - Trust only the origin derived from the existing hardcoded
  `CHATGPT_CODEX_BASE_URL` when granting ChatGPT auth to an MCP server.
  - Keep configured bearer tokens and authorization headers ahead of the
  selected authentication flow.
  - Update config writers, schema output, fixtures, and integration-test
  setup to use the enum.
  
  ## Verification
  
  Integration coverage exercises the complete streamable HTTP startup path
  in two independent configurations:
  
  - A directly constructed MCP configuration verifies that matching an
  overridden `chatgpt_base_url` does not grant ChatGPT auth.
  - A persisted `config.toml` containing an attacker-controlled
  `chatgpt_base_url` and `auth = "chatgpt"` verifies the same boundary
  through normal config parsing.
  
  Both tests complete MCP initialization and tool listing and assert that
  the full captured request sequence contains no authorization headers.
  Separate integration coverage verifies that configured authorization
  takes precedence over ChatGPT auth.

  Ahmed Ibrahim · 2026-06-24 19:51:51 -07:00
  f8937b7d86
• Allow ChatGPT-hosted MCP servers to use session auth (#29733)

  ## Why
  
  ChatGPT session authentication was inferred from the reserved Codex Apps
  server name. That couples credential routing to Codex Apps-specific
  behavior and prevents other MCP endpoints hosted by ChatGPT from
  explicitly using the current session.
  
  The opt-in also needs a clear security boundary: an arbitrary MCP
  configuration must not be able to redirect ChatGPT credentials to
  another origin.
  
  ## What changed
  
  - Add `use_chatgpt_auth` to HTTP MCP server configuration, defaulting to
  `false`.
  - Honor the setting only when the parsed server URL has the same HTTP(S)
  origin as the configured `chatgpt_base_url`; otherwise remove the
  capability before startup.
  - Resolve bearer tokens and static or environment-backed authorization
  headers before selecting authentication, with configured authorization
  taking precedence over ChatGPT session auth.
  - Enable the setting for the built-in Codex Apps and hosted plugin
  runtime endpoints while keeping Codex Apps caching and tool
  normalization scoped to the reserved server.
  - Persist the setting through MCP config rewrite paths and expose it in
  the generated config schema.
  - Load the current login state for `codex mcp list` so reported auth
  status matches runtime behavior.
  
  ## Verification
  
  Core integration coverage exercises the complete streamable HTTP MCP
  startup path and verifies that:
  
  - a same-origin opted-in server receives the current ChatGPT access
  token;
  - an explicitly configured authorization header takes precedence;
  - a different-origin server completes MCP initialization and tool
  listing without receiving any ChatGPT authorization header.

  Ahmed Ibrahim · 2026-06-24 19:21:28 -07:00
  4c0706e24a
• config: own layer provenance types (#29722)

  ## Why
  
  Config layer provenance describes how effective configuration was
  assembled, so it belongs with the config loader rather than in
  app-server's serialized API types.
  
  ## What changed
  
  - Moved `ConfigLayerSource`, `ConfigLayerMetadata`, and `ConfigLayer`
  ownership into `codex-config`.
  - Kept app-server's wire payloads unchanged and added explicit
  conversions at the app boundary.
  - Removed lower-level app-server-protocol dependencies from config
  consumers.
  
  ## Stack
  
  This is PR 3 of 6, stacked on [PR
  #29721](https://github.com/openai/codex/pull/29721). Review only the
  delta from `codex/split-auth-domain-types`. Next: [PR
  #29723](https://github.com/openai/codex/pull/29723).
  
  ## Validation
  
  - `codex-config` coverage passed.
  - App-server config-manager and config RPC coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 04:03:04 +00:00
  1d65ccabd5
• [plugins] Add marketplace source requirements (#29690)

  ## Why
  
  Managed deployments need a mergeable way to declare which marketplace
  sources Codex may use. An enterprise-keyed TOML table avoids array merge
  ambiguity and lets every requirements layer use the existing config
  precedence rules without a marketplace-specific merger.
  
  ## Requirements shape
  
  ```toml
  [marketplaces]
  restrict_to_allowed_sources = true
  
  [marketplaces.allowed_sources.company_plugins]
  source = "git"
  url = "https://github.com/example/company-plugins.git"
  ref = "main"
  
  [marketplaces.allowed_sources.internal_git]
  source = "host_pattern"
  host_pattern = "^git\\.example\\.com$"
  
  [marketplaces.allowed_sources.local_plugins]
  source = "local"
  path = "/opt/company/codex-plugins"
  ```
  
  `restrict_to_allowed_sources` follows normal scalar precedence.
  `allowed_sources` follows normal recursive TOML table merge behavior:
  distinct keys accumulate and fields under the same key use normal layer
  precedence. The final `source` value later selects which fields the
  marketplace admission policy interprets.
  
  The raw rule fields remain optional while requirements layers are
  composed, so a higher-priority layer can override only `ref`, `url`, or
  another individual field. Source-specific validation and normalization
  intentionally belong to the marketplace admission layer, not
  requirements merging.
  
  This initial shape includes `git`, `host_pattern`, and `local` sources.
  It does not add npm or path-pattern rules.
  
  ## What changed
  
  - Add the marketplace requirements TOML shape to
  `ConfigRequirementsToml`, `ConfigRequirementsWithSources`, and
  `ConfigRequirements`.
  - Carry marketplace requirements through the existing regular
  requirements merge path.
  - Keep allowed-source entries as raw partial tables for downstream
  policy interpretation.
  - Cover partial same-key overlays, source changes, unknown fields, and
  unmodified local paths.
  
  This PR defines and composes the requirements only. Source admission is
  implemented by the next PR in the stack.
  
  ## Stack
  
  This is PR 1 of 3. #29753 adds source admission on top of this PR; draft
  #29691 will add runtime enforcement after it is rebased later.
  
  ## Test plan
  
  - `just test -p codex-config marketplace_`

  xl-openai · 2026-06-23 19:42:13 -07:00
  2696e7199b
• chore(core) rm AskForApproval::OnFailure (#28418)

  ## Summary
  Deletes the OnFailure variant of the `AskForApproval` enum. This option
  has been deprecated since #11631.
  
  ## Testing
  - [x] Tests pass

  Dylan Hurd · 2026-06-23 12:13:54 -07:00
  2cf2a6a844
• mcp: accept foreign absolute cwd for remote stdio (#29493)

  ## Why
  
  Remote stdio MCP servers can run in an environment whose path convention
  differs from the Codex host. A Windows cwd such as
  `C:\Users\openai\share` is absolute for the executor but was rejected by
  a POSIX orchestrator.
  
  Built on #29501, now merged, which only clarifies the host-native
  `PathUri` constructor name.
  
  ## What changed
  
  - Deserialize MCP cwd values as `LegacyAppPathString` so config does not
  apply host path rules.
  - Interpret that spelling as host-native for local launches and convert
  it to `PathUri` at executor launch.
  - Skip host filesystem and command resolution checks for remote stdio in
  `codex doctor`.
  - Add host-independent config and executor-boundary coverage using the
  foreign path convention for each test platform.
  
  ## Validation
  
  - `just test -p codex-utils-path-uri -p codex-config -p codex-mcp -p
  codex-rmcp-client` (408 passed)
  - `just test -p codex-cli -p codex-rmcp-client` (372 passed)
  - `cargo check --workspace --tests`
  - `just test` (11,311 passed; 43 unrelated environment/timing failures)
  - `just fix -p codex-cli -p codex-config -p codex-core -p codex-mcp -p
  codex-mcp-extension -p codex-rmcp-client -p codex-tui`

  Adam Perry @ OpenAI · 2026-06-23 01:33:51 +00:00
  67009bc53f
• [codex] add configurable token budget compaction reminder (#29255)

  ## Why
  
  The token-budget feature reports coarse remaining-context milestones,
  but it does not give the model a configurable wrap-up prompt before
  automatic compaction. A strict threshold-crossing check can also miss
  resumed or reconfigured windows that are already inside the threshold.
  
  ## What changed
  
  - Add structured `[features.token_budget]` configuration for an absolute
  `reminder_threshold_tokens` and bounded `reminder_message_template`;
  `{n_remaining}` is expanded when the reminder is delivered.
  - Compute remaining tokens against the next effective auto-compaction
  boundary, including scoped `body_after_prefix` accounting and the full
  context-window limit.
  - Make reminder delivery level-triggered before and after sampling, with
  one-shot state owned by `AutoCompactWindow` and re-armed on compaction,
  `new_context`, restore, or history replacement.
  - Leave the existing initial full-window token-budget context, 25/50/75%
  notices, and token-budget tools unchanged.
  - Persist the resolved feature configuration in the session config lock
  and regenerate the config schema.
  
  ## Validation
  
  - `just test -p codex-core token_budget`
  - `just test -p codex-core
  token_budget_reminder_emits_after_crossing_compaction_threshold`
  - `just test -p codex-core auto_compact_window`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just test -p codex-features`
  - `just test -p codex-config`

  pakrym-oai · 2026-06-20 19:13:42 -07:00
  6df037d47f
• Add config toggles for orchestrator skills and MCP (#28942)

  ## Why
  
  Orchestrator-provided skills and Codex Apps MCP tools add model-visible
  instructions, resources, and tools beyond the local workspace. Hosts
  need config-level switches to disable those orchestrator-owned surfaces
  independently, without disabling regular skills or regular MCP servers.
  
  ## What changed
  
  - Adds `[orchestrator.skills].enabled` and `[orchestrator.mcp].enabled`
  config entries, both defaulting to `true`.
  - Includes the new settings in `config.schema.json` and in the config
  lock so resolved thread configuration preserves the same orchestrator
  exposure decisions.
  - Threads `orchestrator.skills.enabled` through the app-server skills
  extension so disabled orchestrator skills do not expose the `skills`
  namespace or inject orchestrator skill context.
  - Gates Codex Apps MCP exposure, app instructions, and app auth
  eligibility on `orchestrator.mcp.enabled` while leaving non-Codex-Apps
  MCP tools available.
  - Updates the thread-manager sample config to disable both
  orchestrator-owned surfaces.
  
  ## Verification
  
  - Added config parsing, loading, defaulting, and schema coverage for the
  new settings.
  - Added MCP exposure coverage that `orchestrator.mcp.enabled = false`
  removes Codex Apps tools while preserving regular MCP tools.
  - Added app-server coverage that `orchestrator.skills.enabled = false`
  prevents orchestrator skill tools, prompts, and resource reads from
  reaching the model turn.

  jif · 2026-06-19 14:42:26 +02:00
  81b000421d
• Add indexed web search mode (#28489)

  ## Summary
  
  - Add `web_search = "indexed"` alongside `disabled`, `cached`, and
  `live`.
  - Use that same resolved mode for both hosted and standalone web search.
  - For hosted search, send `index_gated_web_access: true` with external
  web access enabled only when `indexed` is selected.
  - For standalone search, preserve the existing boolean wire values for
  existing modes (`cached` maps to `false` and `live` to `true`) and send
  `"indexed"` only for `indexed`; `disabled` keeps the tool unavailable.
  - Carry the mode through managed configuration requirements and
  generated schemas.
  
  ## Why
  
  Indexed search provides a middle ground between cached-only search and
  unrestricted live page fetching. Search queries can remain live while
  direct page fetches are limited to URLs admitted by the server.
  
  The existing `web_search` setting remains the single source of truth, so
  hosted and standalone executors cannot drift into different access
  modes. Without an explicit `indexed` selection, the existing
  model-visible tool and request shapes are unchanged.
  
  ```toml
  web_search = "indexed"
  
  [features]
  standalone_web_search = true
  ```
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-api` (`126 passed`)
  - `just test -p codex-web-search-extension` (`7 passed`)
  - `just test -p codex-core
  code_mode_can_call_indexed_standalone_web_search` (`1 passed`)
  - Focused configuration, hosted request, standalone request, and
  managed-requirement coverage is included in the PR; remaining suites run
  in CI.
  
  The full workspace test suite was not run locally.

  Winston Howes · 2026-06-19 05:35:57 -07:00
  3a2712ea14
• Always use AVAS for realtime WebRTC calls (#28856)

  ## Summary
  
  - Remove the realtime `architecture` selector from core protocol,
  app-server protocol, config parsing, generated schemas, and callers.
  - Always create WebRTC realtime calls with the AVAS query params:
  `intent=quicksilver&architecture=avas`.
  - Keep direct websocket realtime behavior on the existing config/default
  path, while WebRTC starts without an explicit version now default to
  realtime v1 because AVAS requires v1.
  
  ## Notes
  
  - WebRTC realtime now means AVAS. If a caller explicitly asks to start
  WebRTC with realtime v2, Codex rejects that request because the AVAS
  WebRTC path only supports realtime v1. Websocket realtime is separate
  and can still use realtime v2.
  - The old `[realtime] architecture = "realtimeapi" | "avas"` config knob
  is removed. Local configs that still set it will need to delete that
  line.
  - Some app-server tests that were only trying to exercise realtime v2
  protocol behavior now use websocket transport, because WebRTC is
  intentionally locked to AVAS/v1. Separate WebRTC tests cover the AVAS
  query params, v1 startup, SDP flow, and sideband join.
  
  ## Validation
  
  - Merged fresh `origin/main` at `83e6a786a2`.
  - `just fmt`
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `git diff --check`
  - `just test -p codex-api -p codex-core -p codex-app-server-protocol -p
  codex-app-server realtime` (176 passed)
  - `just test -p codex-protocol -p codex-config` (413 passed)

  Peter Bakkum · 2026-06-18 19:11:21 -05:00
  8e7c213f8f
• Add Config for Time Reminders (varlatency 1/n) (#28822)

  ## Summary
  
  Example:
  
  > [features.current_time_reminder]
  enabled = true
  reminder_interval_model_requests = 1
  clock_source = "system"
  
  ## Testing
  
  - `just test -p codex-core varlatency`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just fix -p codex-core -p codex-config -p codex-features`

  rka-oai · 2026-06-18 11:39:02 -07:00
  df5f122854
• [codex] add rollout token budget configuration (varlength 1/N) (#28746)

  ## What
  
  This PR defines the structured configuration contract for shared rollout
  token budgets (across ALL agent threads under 1 rollout).
  
  ```toml
  [features.rollout_budget]
  enabled = true
  limit_tokens = 100000
  reminder_interval_tokens = 10000
  sampling_token_weight = 1.0
  prefill_token_weight = 0.1
  ```
  
  The reminder interval defaults to 10% of the rollout limit. Sampling and
  prefill weights default to `1.0`.
  
  ## Scope
  
  This PR only defines and validates configuration. It does not track
  usage, inject reminders, or stop a rollout. Accounting and reminders are
  implemented in the stacked follow-up #28494.
  
  The existing `token_budget` feature remains unchanged. `rollout_budget`
  has its own feature key and configuration type.
  
  ## Tests
  
  The config test verifies that the structured fields resolve into
  `RolloutBudgetConfig` and do not enable the existing `token_budget`
  feature.
  
  Local checks:
  
  - `just write-config-schema`
  - `just test -p codex-core load_config_resolves_rollout_budget`
  - `cargo check -p codex-thread-manager-sample`
  - `git diff --check`
  
  The full workspace test suite was not run locally.

  rka-oai · 2026-06-18 04:29:47 -07:00
  ecc4c30e28
• [ez][codex-rs] Support apps._default.default_tools_approval_mode (#27965)

  [from codex]
  
  ## Summary
  
  - add `default_tools_approval_mode` to `[apps._default]` and expose it
  through app-server v2 `config/read`
  - apply it after managed, per-tool, and per-app approval settings,
  before the built-in `auto` fallback
  - document the precedence, regenerate config/app-server schemas, and add
  unit plus end-to-end approval coverage
  
  ## Configuration
  
  ```toml
  [apps._default]
  default_tools_approval_mode = "prompt"
  ```
  
  The effective precedence is managed requirements, tool-specific
  `approval_mode`, app-specific `default_tools_approval_mode`,
  `apps._default.default_tools_approval_mode`, then `auto`.
  
  ## Test plan
  
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just write-app-server-schema --experimental`
  - `just test -p codex-core app_tool_policy`
  - `just test -p codex-core mcp_turn_metadata`
  - `just test -p codex-config`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server config_read_includes_apps`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server`
  - `just fmt`

  Alex Zamoshchin · 2026-06-17 08:50:39 -07:00
  c78911e37f
• PAC 1 - Add system proxy feature config surface (#26706)

  ## Summary
  
  Introduces the default-off `respect_system_proxy` feature flag used to
  gate first-class system PAC/proxy support for Codex-owned native
  clients.
  
  With the feature disabled or absent, behavior remains unchanged. This PR
  establishes the configuration and managed-requirement surface; proxy
  discovery and request routing are implemented by follow-up PRs.
  
  ## Configuration
  
  User configuration uses the standard boolean feature form:
  
  ```toml
  [features]
  respect_system_proxy = true
  ```
  
  Managed feature requirements use the corresponding boolean key. The
  effective runtime configuration is exposed as a boolean and defaults to
  `false`.
  
  ## Implementation
  
  - Registers `respect_system_proxy` as an under-development, default-off
  feature.
  - Resolves user configuration and managed feature requirements into
  `Config.respect_system_proxy`.
  - Provides bootstrap resolution for startup paths that must evaluate the
  feature before full configuration loading completes.
  - Uses the standard feature CLI and config-editing behavior.
  - Excludes `features.respect_system_proxy` from project-local
  configuration.
  - Updates the generated configuration schema.
  
  ## End-user behavior
  
  - No networking behavior changes when the feature is absent or disabled.
  - Enabling the feature makes the boolean available to the native
  proxy-routing implementation in follow-up PRs.
  - Repository-local configuration cannot enable the feature.
  
  ## Test coverage
  
  Covers scalar configuration and CLI override resolution, managed
  requirement constraints, bootstrap resolution, and project-local
  filtering.

  canvrno-oai · 2026-06-16 16:54:37 -07:00
  f0cb96bcb1
• [codex] exec-server: stream files in chunks (#28354)

  ## Why
  
  `fs/readFile` buffers the entire file in one response, which makes large
  remote reads expensive and prevents callers from applying backpressure.
  We need an opt-in streaming path with bounded block sizes while
  preserving the existing single-call API for small and sandboxed reads.
  
  ## What changed
  
  - Add `ExecServerClient::stream`, returning a named `FileReadStream`
  that implements `futures::Stream` and yields immutable 1 MiB byte
  blocks.
  - Add internal `fs/open`, `fs/readBlock`, and `fs/close` RPCs.
  `fs/readBlock` accepts an explicit offset and length.
  - Keep unsandboxed files open between block reads, cap open handles per
  connection, and clean them up on EOF, error, stream drop, explicit
  close, or connection shutdown.
  - Reject platform-sandboxed streaming opens instead of turning the
  one-shot sandbox helper into a persistent server. Existing `fs/readFile`
  behavior is unchanged.
  
  ## Testing
  
  - `just test -p codex-exec-server`
  - Integration coverage for 1 MiB chunking, exact block-boundary EOF,
  sandbox rejection, and continued reads from the opened file after path
  replacement.
  - Handle-manager coverage for non-sequential offsets, variable block
  lengths, the 128-handle limit, and capacity release after close.

  pakrym-oai · 2026-06-16 09:50:55 -07:00
  a4711b88dd
• perf(config): defer remote sandbox hostname lookup (#28542)

  ## Why
  
  [#18763](https://github.com/openai/codex/pull/18763) added canonical
  hostname resolution for `remote_sandbox_config`. Requirements
  composition currently performs that synchronous DNS lookup on every
  fresh process, even when none of the loaded requirements layers contains
  `[[remote_sandbox_config]]`. On hosts with slow local DNS resolution,
  this can add several seconds to Codex startup.
  
  ## What
  
  - defer hostname resolution until a parsed requirements layer actually
  contains `remote_sandbox_config`
  - cache the resolver result once per requirements composition,
  preserving the existing single-lookup behavior across multiple layers
  - keep the existing FQDN resolution and per-layer requirements
  precedence unchanged
  - cover both the ordinary no-lookup path and the multi-layer
  single-lookup path
  
  ## How to Test
  
  On a host where local canonical-name resolution is slow:
  
  1. Start Codex without `[[remote_sandbox_config]]` in any managed
  requirements layer and confirm startup no longer waits for hostname
  resolution.
  2. Add a matching `[[remote_sandbox_config]]` entry and confirm its
  `allowed_sandbox_modes` still overrides the layer's top-level value.
  3. Add remote sandbox entries to multiple requirements layers and
  confirm precedence remains unchanged while the hostname is resolved only
  once.
  
  Targeted tests:
  
  - `just test -p codex-config hostname_resolver`
  - `just test -p codex-config` (181 passed)

  Felipe Coury · 2026-06-16 11:17:41 -04:00
  40e7dda4d2
• feat(app-server): enforce managed remote control disable (#27961)

  ## Why
  
  Managed deployments need a reliable deny gate for remote control.
  Persisted enablement and explicit startup requests currently remain able
  to start the transport, while the removed `features.remote_control` key
  is intentionally only a compatibility no-op.
  
  This adds a dedicated requirement that administrators can use to force
  remote control off without deleting the user's persisted preference.
  Removing the requirement and restarting restores the prior choice.
  
  ## What Changed
  
  - Added top-level `allow_remote_control` requirements parsing, sourced
  layer precedence, debug output, and `configRequirements/read` exposure
  as `allowRemoteControl`.
  - Added a typed transport policy captured from the startup requirements
  snapshot. Managed disable forces the initial state to disabled and
  prevents enrollment, refresh, connection, and persisted-preference
  mutation.
  - Rejected every `remoteControl/*` RPC before parameter deserialization
  with JSON-RPC `-32600` and `remote control is disabled by managed
  requirements`.
  - Preserved the existing disabled status notification and the previous
  behavior when the requirement is `true` or omitted.
  - Regenerated app-server protocol schemas and documented the new
  requirement.
  
  ## Verification
  
  - Confirmed all remote-control RPCs, including a malformed request,
  return the managed-policy error while the initial status notification
  remains `disabled`.
  - Confirmed explicit ephemeral startup and persisted enablement make no
  backend connection and leave the SQLite preference unchanged.
  - Confirmed `allow_remote_control = true` does not enable or block
  remote control and `configRequirements/read` returns
  `allowRemoteControl: false` for the deny policy.
  
  Related issue: N/A (managed-policy hardening).

  Anton Panasenko · 2026-06-12 20:10:12 -07:00
  b9dc3b7a8b
• [codex] make PathUri::from_abs_path infallible (#27976)

  ## Why
  
  `PathUri::from_abs_path` can fail for absolute paths that do not have a
  normal `file:` URI representation, forcing filesystem call sites to
  handle a conversion error even though the original path can be preserved
  losslessly.
  
  ## What
  
  Make `from_abs_path` infallible and migrate its callers. Unrepresentable
  paths use `file:///%00/bad/path/<base64>`, encoding Unix bytes or
  Windows UTF-16LE; `to_abs_path` validates and decodes that fallback. The
  leading encoded null reserves a namespace that cannot collide with a
  real Unix or Windows path, and fallback URIs remain opaque to lexical
  path operations.
  
  ## Validation
  
  Added path-URI coverage for Unix null and non-UTF-8 paths, Windows
  device/verbatim and non-Unicode paths, serialization, malformed
  fallbacks, opaque lexical operations, invalid native payloads, and
  literal `/bad/path` collision resistance.

  Adam Perry @ OpenAI · 2026-06-12 16:58:42 -07:00
  968a3ac9c1
• feat: add secret auth storage configuration (#27504)

  ## Why
  
  Windows Credential Manager limits generic credential blobs to 2,560
  bytes. The encrypted local secrets backend avoids storing large
  serialized auth payloads directly in the OS keyring, but selecting that
  backend needs an independently reviewable feature/config layer before
  the auth and secrets implementation is wired in.
  
  ## What Changed
  
  - Added the stable `secret_auth_storage` feature, enabled by default on
  Windows and disabled by default elsewhere.
  - Added `AuthKeyringBackendKind` and config resolution for full and
  bootstrap config loading.
  - Applied managed feature requirements when resolving the bootstrap auth
  backend.
  - Updated the generated config schema and added focused tests.
  
  This is the base PR for #17931. The auth, secrets, MCP, CLI, TUI, and
  app-server implementation remains in that follow-up PR.
  
  ## Validation
  
  - `just test -p codex-features`
  - `just test -p codex-config`
  - `just test -p codex-core
  resolve_bootstrap_auth_keyring_backend_kind_uses_secret_auth_storage_feature`
  - `just write-config-schema`
  - `just fix -p codex-core`
  
  The full `just test -p codex-core` run compiled successfully and ran
  2,690 tests; 2,589 passed, one was flaky, and 101 environment-sensitive
  tests failed because this shell injects a `pyenv` rehash warning into
  command output or because sandboxed subprocesses timed out.

  Celia Chen · 2026-06-12 19:15:21 +00:00
  b724f5966e
• realtime: add AVAS architecture override (#27720)

  ## Summary
  
  Adds a `RealtimeConversationArchitecture` option for realtime
  conversation startup, with `realtimeapi` as the default and `avas` as an
  opt-in architecture.
  
  The AVAS path is limited to realtime v1 conversational WebRTC starts,
  and WebRTC call creation appends `intent=quicksilver&architecture=avas`
  to `/v1/realtime/calls`. The existing sideband websocket still joins by
  `call_id`.
  
  This also exposes the per-session architecture override through
  app-server v2 `thread/realtime/start` params and updates the config
  schema for `[realtime].architecture`.
  
  ## Validation
  
  - `just fmt`
  - `just write-config-schema`
  - `just test -p codex-api sends_avas_session_call_query_params`
  - `just test -p codex-core -E
  'test(~conversation_webrtc_start_uses_avas_architecture_query)'`
  - `just test -p codex-core -E 'test(realtime_loads_from_config_toml)'`
  - `just test -p codex-app-server-protocol -E
  'test(~serialize_thread_realtime_start) |
  test(generated_ts_optional_nullable_fields_only_in_params)'`
  - `just test -p codex-app-server -E
  'test(realtime_webrtc_start_emits_sdp_notification)'`

  Peter Bakkum · 2026-06-12 18:11:13 +00:00
  6652e82dd0
• [ez][codex-rs] Support approvals reviewer in app defaults (#27075)

  [from codex]
  
  ## Summary
  
  - add `approvals_reviewer` support to `[apps._default]`
  - resolve connected-app reviewers in per-app, app-default, then global
  order
  - expose the setting through the v2 config API and regenerate schema
  fixtures
  
  ## Context
  
  PR #25167 added `apps.<connector_id>.approvals_reviewer`, but the shared
  app defaults table could not specify the reviewer. This extends the same
  behavior to `[apps._default]` while preserving per-app overrides.
  
  Managed `allowed_approvals_reviewers` requirements still constrain both
  default and per-app values. A disallowed app value falls back to the
  global reviewer, and non-app MCP servers continue using the global
  reviewer.
  
  ## Testing
  
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just fmt`
  - `just test -p codex-config`
  - `just test -p codex-core app_approvals_reviewer`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server config_read_includes_apps`

  Alex Zamoshchin · 2026-06-12 09:06:58 -07:00
  3cac2e0d3f
• [codex] Remove async_trait from first-party code (#27475)

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

  Adam Perry @ OpenAI · 2026-06-11 18:16:39 -07:00
  5a56caf18c
• Warn when hooks.json has unsupported top-level fields (#26426)

  Addresses #25875.
  
  ## Summary
  
  `hooks.json` accepted unknown top-level fields. A file with
  `SessionStart` at the root parsed as an empty hook configuration without
  warning.
  
  ## Repro
  
  ```json
  { "SessionStart": [...] }
  ```
  
  Previously: zero hooks, zero warnings.
  
  Now:
  
  ```text
  unknown field `SessionStart`, expected `hooks`
  ```
  
  The supported shape remains:
  
  ```json
  { "hooks": { "SessionStart": [...] } }
  ```
  
  ## Fix
  
  Reject unknown top-level fields and surface the parse warning in human
  and JSONL `codex exec` output.

  Abhinav · 2026-06-11 23:08:07 +00:00
  eddc5c75ed
• [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
• Use plugin-service MCP as the hosted plugin runtime (#27198)

  ## Stack
  
  - Base: #27191
  - This PR is the third vertical and should be reviewed against
  `jif/external-plugins-2`, not `main`.
  
  ## Why
  
  #27191 moves the host-owned Apps MCP registration behind an extension
  contributor, but deliberately preserves the existing endpoint-selection
  feature while that contribution contract lands. App-server can therefore
  resolve the server through extensions, yet the hosted plugin endpoint is
  still selected through temporary `apps_mcp_path_override` plumbing.
  
  That is not the long-term plugin model. A plugin can bundle skills,
  connectors, MCP servers, and hooks, and those components do not all need
  the same source or execution environment. In particular, an
  authenticated HTTP MCP server can expose plugin capabilities directly
  from a backend without an executor or an orchestrator filesystem.
  
  This PR completes that hosted vertical. App-server's MCP extension now
  owns the aggregate hosted plugin runtime at `/ps/mcp`. Connector actions
  continue to arrive as MCP tools, while backend-provided skills arrive as
  MCP resources and use Codex's existing resource list/read paths. No
  second backend client, skill filesystem, or generic plugin activation
  framework is introduced.
  
  The backend route remains the hosted implementation. This change
  replaces Codex's temporary endpoint-selection mechanism, not the service
  behind the endpoint.
  
  ## What changed
  
  ### Hosted plugin runtime
  
  The MCP extension now contributes `codex_apps` as the hosted plugin
  runtime rather than as a configurable Apps endpoint:
  
  - `https://chatgpt.com` resolves to
  `https://chatgpt.com/backend-api/ps/mcp`;
  - a bare custom ChatGPT base resolves to `/api/codex/ps/mcp`;
  - the existing product-SKU header and ChatGPT authentication behavior
  are preserved;
  - executor availability is never consulted for this streamable HTTP
  transport.
  
  The same MCP connection carries both component shapes supported by the
  hosted endpoint:
  
  - connector actions are discovered and invoked as MCP tools;
  - hosted skills are enumerated and read as MCP resources through the
  existing `list_mcp_resources` and `read_mcp_resource` paths.
  
  This keeps component access in the subsystem that already owns the
  protocol instead of downloading backend skills into an orchestrator
  filesystem or inventing a parallel hosted-skill client.
  
  ### Explicit runtime ordering
  
  `McpManager` now resolves the reserved `codex_apps` entry in three
  ordered phases:
  
  1. install the legacy Apps fallback for compatibility;
  2. apply ordered extension `Set` or `Remove` overlays;
  3. apply the final ChatGPT-auth gate without synthesizing the server
  again.
  
  This ordering is important:
  
  - an ordinary configured or plugin MCP server cannot claim the
  auth-bearing `codex_apps` name;
  - an extension-contributed hosted runtime wins over the fallback;
  - an extension `Remove` remains authoritative;
  - a host without the MCP extension retains the legacy Apps endpoint and
  current local-only behavior.
  
  The temporary `legacy_apps_mcp_loader_enabled` coordination flag is no
  longer needed.
  
  ### Remove the path override
  
  The `apps_mcp_path_override` feature and its runtime plumbing are
  removed, including:
  
  - the feature registry entry and structured feature config;
  - `Config` and `McpConfig` fields;
  - config schema output;
  - config-lock materialization;
  - URL override handling in `codex-mcp`.
  
  Existing boolean and structured forms still deserialize as ignored
  compatibility input. They are omitted from new serialized config, and
  config-lock comparison normalizes the removed input so older locks
  remain replayable.
  
  ### App-server coverage
  
  App-server MCP fixtures now serve the hosted route at
  `/api/codex/ps/mcp`. Existing resource-read and tool/elicitation flows
  therefore exercise the extension-owned endpoint rather than succeeding
  through the legacy fallback.
  
  The stack also adds the missing `codex_chatgpt::connectors` re-export
  for the manager-backed connector helper introduced in #27191.
  
  ## Compatibility
  
  - App-server installs the extension and uses `/ps/mcp` for the hosted
  runtime.
  - CLI and other hosts that do not install the extension retain the
  legacy Apps endpoint.
  - Apps disabled or non-ChatGPT authentication removes `codex_apps` from
  the effective runtime view.
  - Existing local plugins, local skills, executor-selected skills,
  configured MCP servers, and MCP OAuth behavior are otherwise unchanged.
  - Backend plugin enablement remains account/workspace state owned by the
  hosted endpoint; this PR does not add thread-local backend plugin
  selection.
  
  ## Architectural fit
  
  The stack now proves two independent runtime shapes:
  
  1. #27184 resolves filesystem-backed skills through the executor that
  owns a selected root.
  2. #27191 and this PR resolve a backend-hosted HTTP MCP through an
  extension with no executor.
  
  Together they preserve the intended separation:
  
  - selection identifies a plugin/root when explicit selection is needed;
  - each component's owning extension resolves its concrete access
  mechanism;
  - execution stays with the runtime required by that component;
  - existing skills, MCP, connector, and hook subsystems remain the
  downstream consumers.
  
  ## Planned follow-ups
  
  1. **Executor stdio MCP:** selecting an executor plugin registers a
  manifest-declared stdio MCP server and executes it in the environment
  that owns the plugin.
  2. **Optional backend selection:** only if CCA needs thread-local
  selection distinct from backend account/workspace enablement, add a
  concrete backend-owned capability location and surface those selected
  skills through the skills catalog.
  3. **Connector metadata and hooks:** activate those plugin components
  through their existing owning subsystems, with executor hooks remaining
  environment-bound.
  4. **Propagation and persistence:** define explicit resume, fork,
  subagent, refresh, and environment-removal semantics once selected roots
  have multiple real consumers.
  5. **Local convergence:** migrate legacy local skill, MCP, connector,
  and hook paths behind their owning extensions one vertical at a time,
  then remove duplicate core managers and compatibility plumbing after
  parity.
  
  ## Verification
  
  Coverage in this change exercises:
  
  - extension-owned `/backend-api/ps/mcp` registration without an
  executor;
  - preservation of the legacy endpoint in hosts without the extension;
  - extension `Set` and `Remove` precedence over the legacy fallback;
  - ChatGPT-auth gating for the reserved server;
  - hosted MCP resource reads with and without an active thread;
  - connector tool invocation and MCP elicitation through the hosted
  route;
  - ignored boolean and structured forms of the removed path override;
  - config-lock replay compatibility for the removed feature.
  
  `cargo check -p codex-features -p codex-mcp-extension -p
  codex-app-server` passes. Tests and Clippy were not run locally under
  the current development instruction; CI provides the full validation
  pass.

  jif · 2026-06-10 12:54:21 +02:00
  9cd11e9e62
• fix: preserve auto review across config and delegation (#26230)

  ## Why
  
  Auto Review should remain the effective approval reviewer when settings
  cross runtime boundaries. A config or app-server round trip must not
  change the reviewer identity, and delegated work must not silently fall
  back to user review.
  
  This requires both a stable canonical serialized value and propagation
  of the effective setting. `auto_review` is the canonical value across
  protocol and app-server output, while `guardian_subagent` remains
  accepted as backward-compatible input.
  
  ## What changed
  
  - serialize `ApprovalsReviewer::AutoReview` consistently as
  `auto_review` across core protocol and app-server v2
  - continue accepting `guardian_subagent` when reading existing config or
  client requests
  - carry the active turn's approval reviewer into spawned agents
  - update config/debug expectations and add delegated-task regression
  coverage
  
  ## Scope
  
  This does not change Guardian policy or remove compatibility with
  existing `guardian_subagent` inputs. It preserves the selected reviewer
  across serialization, config reloads, app-server settings, and delegated
  task setup.
  
  Related Guardian changes are split independently:
  
  - #26231 adds denials and soft denials
  - #26334 retries transient reviewer failures
  - #26333 reuses narrowly scoped low-risk approvals
  - #26232 adds TUI denial recovery
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` (224 passed)
  - regression coverage for delegated task reviewer propagation
  - serialization coverage for canonical `auto_review` output and legacy
  `guardian_subagent` input
  
  ---------
  
  Co-authored-by: saud-oai <saud@openai.com>

  viyatb-oai · 2026-06-08 18:59:50 +00:00
  9e0d7f02c9
• permissions: enforce managed permission profile allowlists (#24852)

  ## Why
  
  Permission profile allowlists are an enterprise security boundary, but
  they also need to compose across the managed requirements layers added
  in #24620.
  
  A map representation lets each requirements layer add, allow, or revoke
  individual profiles without replacing an entire array.
  
  ## Managed Contract
  
  Administrators configure the mergeable allow map with
  `allowed_permission_profiles`. A recommended enterprise configuration
  explicitly lists every built-in and custom profile users should be able
  to select:
  
  ```toml
  default_permissions = "review_only"
  
  [allowed_permission_profiles]
  ":read-only" = true
  ":workspace" = true
  review_only = true
  # ":danger-full-access" is intentionally omitted, so it is denied.
  
  [permissions.review_only]
  extends = ":read-only"
  ```
  
  - Profiles whose effective merged value is `true` are allowed.
  - Missing profiles and profiles set to `false` are denied.
  - This is a closed allowlist: built-in profiles and profiles introduced
  in future versions are denied unless explicitly allowed.
  - Explicitly list each built-in profile the enterprise wants to make
  available. Omit built-ins such as `:danger-full-access` when they should
  remain unavailable.
  - Set `default_permissions` explicitly to the allowed profile users
  should receive when they have no local selection.
  - Higher-precedence layers override only the profile keys they define.
  - `false` is only needed when a higher-precedence layer must revoke a
  `true` inherited from a lower layer.
  - Explicit keys must refer to known built-in or managed profiles.
  
  A custom or narrowed allowlist requires an allowed
  `default_permissions`. For compatibility, if both `:workspace` and
  `:read-only` are explicitly allowed, an omitted default resolves to
  `:workspace`; customer configurations should still set the intended
  default explicitly.
  
  When `allowed_permission_profiles` is absent, existing implicit
  permission and legacy `sandbox_mode` behavior is unchanged.
  
  ## What Changed
  
  - Add `allowed_permission_profiles` as a `BTreeMap<String, bool>` that
  merges per profile across requirements layers.
  - Enforce managed defaults, strict denial of omitted profiles, and the
  explicitly allowed standard-pair fallback.
  - Expose `allowedPermissionProfiles` through `configRequirements/read`
  and regenerate its schemas.
  - Add regression coverage for map composition and revocation, managed
  defaults, strict denial of omitted built-ins, and API output.
  
  ## Verification
  
  - Focused `codex-config` coverage for layered map composition and
  revocation
  - Focused `codex-core` coverage for managed defaults, invalid defaults,
  strict denial of omitted built-ins, and the standard built-in pair
  - Focused `codex-app-server` coverage for requirements API output
  - Scoped Clippy for `codex-config`, `codex-core`,
  `codex-app-server-protocol`, and `codex-app-server`
  
  ## Documentation
  
  The managed `requirements.toml` documentation should introduce
  `allowed_permission_profiles` as a closed permission-profile allowlist
  before this setting is published on developers.openai.com.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-05 18:06:29 -07:00
  2f108f9fd9
• core: allow excluding tool namespaces from code mode (#26320)

  ## Why
  
  Research and training setups need to control which tool namespaces
  appear inside code mode's nested `tools` surface without disabling those
  tools entirely. This makes it possible to train against a deliberately
  reduced nested-tool setup while preserving the normal direct and
  deferred tool paths.
  
  ## What
  
  - Extend `features.code_mode` to accept structured configuration while
  preserving the existing boolean syntax.
  - Add an exact `excluded_tool_namespaces` list under
  `[features.code_mode]`:
  
    ```toml
    [features.code_mode]
    enabled = true
    excluded_tool_namespaces = ["mcp__codex_apps", "multi_agent_v1"]
    ```
  
  - Filter matching canonical `ToolName` namespaces when constructing code
  mode's nested router and code-mode-specific direct tool descriptions.
  - Keep excluded tools registered, directly exposed in mixed code mode,
  and discoverable through top-level `tool_search` when otherwise
  eligible.
  - Derive deferred nested-tool guidance after namespace filtering so the
  `exec` description does not advertise excluded-only deferred tools.
  - Preserve the boolean/table representation when materializing config
  locks and update the generated config schema.
  
  ## Testing
  
  - `just test -p codex-features`
  - `just test -p codex-config`
  - `just test -p codex-core load_config_resolves_code_mode_config`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just test -p codex-core
  excluded_deferred_namespaces_do_not_enable_nested_tool_guidance`
  - `just test -p codex-core
  code_mode_excludes_configured_nested_tool_namespaces`
  - `cargo check -p codex-thread-manager-sample`

  sayan-oai · 2026-06-04 18:40:18 +00:00
  8b1238856b
• config: express implicit sandbox defaults as permission profiles (#25926)

  ## Why
  
  `PermissionProfile` is becoming the default way to represent Codex
  permissions, but the implicit default behavior should stay the same for
  now:
  
  - trusted projects use `:workspace`
  - untrusted projects also use `:workspace`
  - roots without a trust decision use `:read-only`
  - unsandboxed Windows falls back to `:read-only`
  
  This keeps the existing sandbox semantics while making silent config
  defaults observable as built-in permission profiles instead of treating
  the legacy `SandboxPolicy` projection as the primary shape.
  
  ## What Changed
  
  - Refactored legacy sandbox derivation to resolve the configured sandbox
  mode once, then apply the implicit project fallback only when no sandbox
  mode was configured.
  - Preserved the existing trust-decision fallback: trusted and untrusted
  projects default to workspace-write where supported.
  - Added empty-config coverage asserting that an untrusted project
  resolves to the built-in active permission profile (`:workspace` outside
  unsandboxed Windows).
  
  ## Verification
  
  - `just fmt`
  - `just test -p codex-core 'config::'`
  - `just test -p codex-config`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25926).
  * __->__ #25926

  Michael Bolin · 2026-06-02 16:26:36 -07:00
  a28b32a835
• config: remove dead profile sandbox fallback (#25943)

  ## Why
  
  `profile_sandbox_mode` was left over from the old selected legacy
  profile path. Production now always derives permissions without that
  value, and legacy profile contents are ignored, so keeping a parameter
  that is always `None` makes `derive_permission_profile` look like it
  still supports a fallback that no longer exists.
  
  ## What Changed
  
  - Removed the `profile_sandbox_mode` argument from
  `ConfigToml::derive_permission_profile`.
  - Updated the production caller and legacy sandbox-policy test helper to
  match.
  - Dropped the stale unselected legacy-profile sandbox test that only
  protected the removed fallback shape.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-core 'config::'`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25943).
  * #25926
  * __->__ #25943

  Michael Bolin · 2026-06-02 22:05:04 +00:00
  c6d76750e8
• 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
• core: derive built-in permission profiles from raw policies (#25739)

  ## Why
  
  Permission profiles that extend a built-in profile should behave like
  other TOML inheritance: parent entries provide defaults, and child keys
  override matching fields before the profile is compiled.
  
  That was not true for `:workspace`. Previously, a profile with `extends
  = ":workspace"` seeded the compiled runtime
  `PermissionProfile::workspace_write()` policy and then appended child
  filesystem entries. A child override such as `":tmpdir" = "read"`
  therefore left the inherited `":tmpdir" = "write"` entry in the final
  policy. Since same-target `write` wins over `read` during runtime
  resolution, the child override was ineffective.
  
  This also needs a clear source of truth for the built-in profiles. The
  protocol-level sandbox policy constructors now define the raw built-in
  filesystem entries, and both `PermissionProfile` presets and
  config-profile inheritance derive from those same values.
  
  ## What Changed
  
  - Add a canonical `FileSystemSandboxPolicy::read_only()` constructor
  while keeping the read-only and workspace-write raw filesystem entries
  explicit and independent.
  - Derive `PermissionProfile::read_only()` from
  `FileSystemSandboxPolicy::read_only()`;
  `PermissionProfile::workspace_write()` continues to derive from
  `FileSystemSandboxPolicy::workspace_write()`.
  - Build extensible `:read-only` and `:workspace` parent profiles by
  projecting those canonical sandbox policies into
  `PermissionProfileToml`, then merge user overrides at the TOML layer
  before compilation.
  - Add config parsing support for `:slash_tmp` so the built-in
  `:workspace` parent can be expressed in the same TOML-shaped filesystem
  table as user profiles.
  - Document that `PermissionsToml::resolve_profile()` returns an
  already-merged `PermissionProfileToml`, and return that profile directly
  after removing the resolved-profile wrapper.
  - Extend the config test for `extends = ":workspace"` to assert that
  inherited `":slash_tmp" = "write"` is preserved and that a child
  `":tmpdir" = "read"` entry replaces the inherited `write` entry.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-protocol`
  - `just test -p codex-core
  permissions_profiles_resolve_extends_parent_first_with_child_overrides`
  - `just test -p codex-core
  default_permissions_profile_can_extend_builtin_workspace`
  - `just test -p codex-core`
    - Result: 2596 passed, 4 failed, 1 timed out.
  - The failures were existing sandbox/environment-sensitive tests
  unrelated to this permissions change:
  
  `suite::user_shell_cmd::user_shell_command_does_not_set_network_sandbox_env_var`,
  
  `suite::user_shell_cmd::user_shell_command_history_is_persisted_and_shared_with_model`,
  
  `suite::abort_tasks::interrupt_persists_turn_aborted_marker_in_next_request`,
      `suite::abort_tasks::interrupt_tool_records_history_entries`, and
  
  `thread_manager::tests::start_thread_uses_all_default_environments_from_codex_home`.

  Michael Bolin · 2026-06-02 10:57:35 -07:00
  593df8773d
• [app-server][core] Add connector-level Guardian reviewer overrides (#25167)

  Context: https://openai.slack.com/archives/C0B4JAF0Q2C/p1779912328647229
  
  ```
  approvals_reviewer = "auto_review"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "user"
  default_tools_approval_mode = "prompt"
  ```
  
  <img width="230" height="84" alt="Screenshot 2026-05-31 at 11 56 34 AM"
  src="https://github.com/user-attachments/assets/e319f8f7-0983-42a7-98cd-3302732fa406"
  />
  
  <img width="841" height="233" alt="Screenshot 2026-05-31 at 11 52 42 AM"
  src="https://github.com/user-attachments/assets/7ac76645-4e90-4d00-8242-f031146a22a5"
  />
  
  -------
  
  ```
  approvals_reviewer = "user"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "auto_review"
  default_tools_approval_mode = "prompt"
  ```
  <img width="195" height="83" alt="Screenshot 2026-05-31 at 12 02 27 PM"
  src="https://github.com/user-attachments/assets/3d374dc8-8aa2-466f-a13f-e4ed8567aa2e"
  />
  <img width="771" height="207" alt="Screenshot 2026-05-31 at 12 05 42 PM"
  src="https://github.com/user-attachments/assets/105c2575-68d6-4ca6-8e69-dc8c82da36a2"
  />
  
  
  
  ## Summary
  - add `apps.<connector_id>.approvals_reviewer` to override Guardian or
  user review routing per connected app
  - apply overrides across direct app MCP calls, delegated MCP prompts,
  and app-server MCP elicitation review while preserving global behavior
  for non-app MCP servers
  - expose and document the config through app-server v2 and generated
  schemas, while honoring global managed reviewer requirements
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Alex Zamoshchin · 2026-06-02 17:04:11 +02:00
  4d80d808b4
• exec-server: canonicalize bound filesystem paths (#25149)

  ## Summary
  - add executor filesystem canonicalization as a bound-path operation
  - route remote canonicalization through the exec-server filesystem RPC
  surface
  - keep path normalization attached to the filesystem that owns the path
  
  ## Stack
  - 2/5 in the skills path authority stack extracted from
  https://github.com/openai/codex/pull/25098
  - follows merged https://github.com/openai/codex/pull/25121
  
  ## Validation
  - `cd
  /Users/starr/code/codex-worktrees/pr-25098-restack-review-pr1b/codex-rs
  && just fmt`
  - Not run: tests/checks (not requested)
  - GitHub CI pending on rewritten head

  starr-openai · 2026-06-01 11:53:31 -07:00
  53ac02356e
• Add cloud-managed config layer support (#24620)

  ## Summary
  
  PR 3 of 5 in the cloud-managed config client stack.
  
  Adds enterprise-managed cloud config as a first-class config layer
  source. The layer metadata is preserved through config loading,
  diagnostics, debug output, hook attribution, and app-server protocol
  surfaces.
  
  ## Details
  
  - Enterprise-managed config becomes a normal config layer source with
  backend-supplied `id` and display `name` attached for provenance.
  - These layers are designed to behave like non-file managed config: they
  can surface syntax/type diagnostics by layer name even though there is
  no physical config file.
  - Relative path settings are resolved from a stored config base so
  cloud-delivered config remains consistent with existing MDM-delivered
  config semantics.
  - Hook attribution distinguishes config-delivered hooks from
  requirements-delivered hooks via `HookSource::CloudManagedConfig`.
  - This remains pull-based and snapshot-oriented; the PR adds layer
  identity/diagnostics, not dynamic reload behavior.
  
  ## Validation
  
  Validated through the targeted stack checks after rebasing onto current
  `main`:
  
  - Rust crate tests for
  config/hooks/cloud-config/backend-client/app-server-protocol
  - Filtered `codex-core` and `codex-app-server` `cloud_config_bundle`
  tests
  - Python generated-file contract test
  - `cargo shear --deny-warnings`
  - Targeted `argument-comment-lint` for config/hooks

  joeflorencio-openai · 2026-05-31 15:54:31 -07:00
  8a556296f0
• Compose requirements layers (#24619)

  ## Summary
  
  PR 2 of 5 in the cloud-managed config client stack.
  
  Adds a shared requirements-layer composition engine. The composer
  defines how ordered requirements layers combine, with focused tests for
  the merge semantics and provenance behavior. The final PR in the stack
  wires runtime requirements sources into this path.
  
  ## Details
  
  - Mental model: requirements layers are ordered lowest priority first,
  matching `ConfigLayerStack`; lower-priority layers provide defaults
  while higher-priority layers win scalar/list conflicts.
  - Regular fields use config-style TOML merging, including recursive
  table merging, so requirements layering follows the same broad model as
  `config.toml` layering.
  - Domain-specific fields keep explicit semantics: `rules.prefix_rules`
  and hooks preserve high-priority-first output, hooks fail closed on
  active managed-dir conflicts, and `permissions.filesystem.deny_read`
  dedupes as a stable high-priority-first union.
  - `remote_sandbox_config` is evaluated within each layer before the
  regular TOML merge, so host-specific sandbox constraints do not leak
  across layers.
  - Provenance points at the exact source when one layer owns a value and
  uses composite provenance when a table field is assembled from multiple
  layers.
  
  ## Validation
  
  Local validation:
  
  - `just fmt`
  - `cargo check -p codex-config`
  - `just test -p codex-config requirements_composition`
  - `git diff --check`
  
  CI will run the broader test matrix.

  joeflorencio-openai · 2026-05-31 15:14:06 -07:00
  20debf746b
• feat(tui): allow function keys through f24 in keymaps (#25329)

  ## Why
  
  Closes #25006.
  
  `tui.keymap` currently rejects `F13` even though Codex's terminal event
  layer can report higher function keys. This prevents users from using
  common remappings such as Caps Lock to `F13`.
  
  ## What Changed
  
  - Define a shared portable upper bound of `F24` for stored TUI
  keybindings.
  - Accept `f13` through `f24` in config normalization and runtime
  parsing.
  - Allow `/keymap` capture to persist `F13` through `F24`.
  - Update the unsupported-function-key error and add boundary tests for
  `F13`, `F24`, and `F25`.
  
  ## How to Test
  
  1. Add a binding such as:
  
     ```toml
     [tui.keymap.global]
     open_transcript = "f13"
     ```
  
  2. Start Codex and press the remapped `F13` key.
  3. Confirm Codex loads the config without the previous `F1 through F12`
  error and the action runs.
  4. Open `/keymap`, capture `F13` for an action, and confirm the saved
  binding is `f13`.
  5. As a regression check, try to capture `F25` and confirm Codex reports
  that only `F1` through `F24` can be stored.
  
  Targeted tests:
  
  - `just test -p codex-config`
  - `just test -p codex-tui function_keys`
  
  Full `just test -p codex-tui` completed with 2,752 passing tests, 4
  skipped tests, and two unrelated guardian feature-flag failures:
  
  -
  `app::tests::update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default`
  -
  `app::tests::update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`

  Felipe Coury · 2026-05-31 15:42:39 -03:00
  2f0726ad6d
• feat(config) experimental_request_user_input toggle (#24541)

  ## Summary
  Experimental flag to allow toggling `request_user_input`:
  
  ```
  tools.experimental_request_user_input = false
  ```
  
  ## Testing
  - [x] Added unit tests

  Dylan Hurd · 2026-05-29 21:35:53 -07:00
  e0435afb72
• Constrain Windows sandbox requirements (#23766)

  # Why
  
  Managed requirements can already constrain sandbox policy choices, but
  Windows sandbox implementation selection was still resolved
  independently from those requirements. That left the TUI able to
  continue through the unelevated fallback even when an organization wants
  to require the elevated Windows sandbox implementation.
  
  # What
  
  - Add `[windows].allowed_sandbox_implementations` requirements support
  for the Windows `elevated` and `unelevated` implementations.
  - Apply that allowlist during core config resolution so disallowed
  configured or feature-selected Windows sandbox implementations fall back
  to an allowed implementation with the existing requirements warning
  path.
  - Reuse the existing TUI Windows setup prompts to block disallowed
  unelevated continuation, keep required elevated setup in front of the
  user, and refuse to persist a TUI-selected Windows sandbox mode that
  requirements disallow.
  
  # Semantics
  
  | Allowed | Selected | Effective |
  | --- | --- | --- |
  | `["elevated"]` | `unelevated` / unset | `elevated` |
  | `["unelevated"]` | `elevated` / unset | `unelevated` |
  | `["elevated", "unelevated"]` | `elevated` | `elevated` |
  | `["elevated", "unelevated"]` | `unelevated` | `unelevated` |
  | `["elevated", "unelevated"]` | unset | `elevated` |
  
  Availability is handled by interactive setup surfaces after allowlist
  resolution. If the effective elevated implementation is not ready,
  elevated-only requirements block on setup. When unelevated is also
  allowed, the UI may offer the existing unelevated fallback.
  
  ## TUI Screens
  
  If elevated setup is not already complete:
  ```
    Your organization requires the default Codex agent sandbox to continue. Set it up to protect your files and control
    network access.
    Learn more <https://developers.openai.com/codex/windows>
  
  › 1. Set up default sandbox (requires Administrator permissions)
    2. Quit
  ```
  
  If admin setup fails under `["elevated"]`:
  ```
    Couldn't set up your sandbox with Administrator permissions
  
    Your organization requires the default sandbox before Codex can continue.
    Learn more <https://developers.openai.com/codex/windows>
  
  › 1. Try setting up admin sandbox again
    2. Quit
  ```
  
  # Next Steps
  
  
  - extend the requirements/readout surface, such as
  `configRequirements/read`, so clients can inspect the loaded
  `[windows].allowed_sandbox_implementations` requirement instead of
  inferring it from Windows setup state
  - consider extending `windowsSandbox/readiness` as well
  - update the App startup guide, setup flow, and banner surfaces so an
  elevated-only requirement omits any continue-unelevated escape hatch and
  blocks startup until a permitted implementation is ready;
  - preserve the existing unelevated fallback path when requirements allow
  it, including the `["unelevated"]` case where elevated is disallowed

  Abhinav · 2026-05-29 16:31:33 -07:00
  a5a94ee5a7
• [codex] Fix Vim normal mode editing (#25022)

  ## Summary
  - add Vim normal-mode `s` support to substitute the character under the
  cursor and enter insert mode
  - fix Vim normal-mode `o` so opening below the final line moves the
  cursor onto the new blank line
  - update keymap config/schema and keymap picker snapshots for the new
  action
  
  ## Validation
  - `just fmt`
  - `just write-config-schema`
  - `just test -p codex-config`
  - focused `just test -p codex-tui` coverage for the Vim `s` and `o`
  behavior, keymap conflict handling, and keymap picker snapshots
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`
  - `git diff --check`
  
  ## Notes
  A full `just test -p codex-tui` run still has two unrelated Guardian
  feature-flag failures in this checkout:
  -
  `app::tests::update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default`
  -
  `app::tests::update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`

  Jinghan Xu · 2026-05-29 14:01:27 -07:00
  f2e7b462a9
• fix(config): use deny for Unix socket permissions (#24970)

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

  viyatb-oai · 2026-05-28 23:53:26 +00:00
  bf72be5927
• feat(tui): make turn interruption keybind configurable (#24766)

  ## Why
  
  Interrupting an active turn is currently fixed to `Esc`, which is easy
  to hit accidentally and cannot be customized through `/keymap`. This
  gives users a less accidental binding while preserving the existing
  default.
  
  ## What Changed
  
  - Adds `tui.keymap.chat.interrupt_turn` to `/keymap`, defaulting to
  `esc` and supporting remapping or unbinding.
  - Uses the configured interrupt binding for running-turn status, queued
  steer interruption, and `request_user_input`, including the visible
  hints.
  - Preserves local `Esc` behavior for popups, Vim insert mode, and
  `/agent` editing while validating conflicts with fixed/backtrack and
  request-input navigation bindings.
  - Adds behavior and snapshot coverage for remapped interruption paths.
  
  ## How to Test
  
  1. Run Codex and open `/keymap`, then set **Interrupt Turn** to `f12`.
  2. Start a turn and confirm `Esc` no longer interrupts it while `f12`
  does; the running hint should display `f12 to interrupt`.
  3. Queue a steer while a turn is running and confirm the preview
  displays `f12`; pressing it should interrupt and submit the steer
  immediately.
  4. Trigger a `request_user_input` prompt and confirm its footer uses
  `f12`; with notes open, `Esc` should still clear notes while `f12`
  interrupts the turn.
  5. Clear the Interrupt Turn binding and confirm the key-specific
  interrupt hint is removed while `Ctrl+C` remains available.
  
  Targeted validation:
  
  - `just write-config-schema`
  - `just fix -p codex-config`
  - `just fix -p codex-tui`
  - `just fmt`
  - `just argument-comment-lint-from-source -p codex-config -p codex-tui`
  - `just test -p codex-config`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`
  - `just test -p codex-tui keymap_setup::tests`
  - `just test -p codex-tui` (fails in two pre-existing guardian
  feature-flag tests unrelated to this diff; the intentional picker
  snapshot updates were reviewed and accepted)

  Felipe Coury · 2026-05-27 18:59:17 +00:00
  2d1ad374a7
• feat(tui): add vim text object bindings (#24382)

  ## Why
  
  Vim mode currently supports some normal-mode operators and motions, but
  common text-object combinations like `ciw`, `daw`, `di(`, and
  quote/bracket variants are still missing. That makes the composer feel
  incomplete for users who expect operator + text object editing to work
  inside prompts.
  
  Closes #21383.
  
  ## What Changed
  
  - Add Vim pending-state support for operator/text-object sequences.
  - Add `c` as a normal-mode operator for text objects, so combinations
  like `ciw` delete the object and enter insert mode.
  - Support word, WORD, delimiter, and quote text objects:
    - `iw`, `aw`, `iW`, `aW`
    - `i(`, `a(`, `i)`, `a)`, `ib`, `ab`
    - `i[`, `a[`, `i]`, `a]`
    - `i{`, `a{`, `i}`, `a}`, `iB`, `aB`
    - `i"`, `a"`, `i'`, `a'`, `i\``, `a\``
  - Add configurable keymap entries and keymap picker coverage for the new
  Vim text-object context.
  - Regenerate the config schema and update keymap picker snapshots.
  
  ## How to Test
  
  Manual smoke test:
  
  1. Start Codex with Vim composer mode enabled.
  2. Type a draft such as:
     ```text
     alpha beta gamma
     call(foo[bar], {"x": "hello world"})
     say "one \"two\" three" now
     ```
  3. Put the cursor on `beta`, press `ciw`, and confirm `beta` is removed
  and the composer enters insert mode.
  4. Escape back to normal mode, put the cursor on `gamma`, press `daw`,
  and confirm `gamma` plus surrounding whitespace is removed.
  5. Put the cursor inside `foo[bar]`, press `di[`, and confirm only `bar`
  is removed.
  6. Put the cursor inside `call(...)`, press `da(`, and confirm the whole
  parenthesized section is removed.
  7. Put the cursor inside the quoted text, press `ci"`, and confirm the
  quote contents are removed and insert mode starts.
  8. Verify cancellation does not edit text: press `d` then `Esc`, and
  press `d` then `i` then `Esc`.
  
  Targeted tests:
  
  - `cargo test -p codex-tui --lib vim_`
  - `cargo nextest run -p codex-tui keymap_setup::tests`
  
  Additional local checks:
  
  - `just write-config-schema`
  - `just fmt`
  - `just fix -p codex-tui`
  - `git diff --check`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`
  
  Local full-suite note: `just test -p codex-tui` ran to completion. The
  keymap snapshot failures were expected and accepted. Two unrelated
  guardian feature-flag tests still fail locally:
  -
  `app::tests::update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default`
  -
  `app::tests::update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`
  
  `just argument-comment-lint` is currently blocked locally by Bazel
  analysis before the lint runs because `compiler-rt` has an empty
  `include/sanitizer/*.h` glob in the local Bazel cache. The touched Rust
  diff was manually inspected for opaque positional literals.

  Felipe Coury · 2026-05-27 15:15:03 -03:00
  8d398d3c52
• fix(tui): complete vim word-end and line-end behavior (#24380)

  ## Why
  
  The TUI Vim composer currently diverges from normal Vim editing in two
  common workflows: pressing `e` repeatedly can remain stuck at an
  existing word end, and normal mode does not support `C` for changing
  through the end of the line. The existing `D` behavior also removes the
  newline when the cursor is already at the line boundary, which makes the
  new `C` action and existing deletion action surprising in multiline
  prompts.
  
  Closes #23926.
  Closes #24238.
  
  ## What Changed
  
  - Make normal-mode `e` advance from the current word end to the next
  word end, including for operator motions such as `de`.
  - Add configurable Vim normal-mode `change_to_line_end` behavior, bound
  to `C` by default, which deletes to the end of the current line and
  enters Insert mode.
  - Keep the newline intact when `D` or `C` is pressed at the end-of-line
  boundary.
  - Add regression coverage for repeated `e`, `de`, `C`, and the multiline
  `C`/`D` boundary behavior.
  - Regenerate the config schema and update the keymap picker snapshots
  for the new Vim action.
  
  ## How to Test
  
  1. Run Codex with Vim composer mode enabled:
     ```bash
     cd codex-rs
     cargo run --bin codex -- -c tui.vim_mode_default=true
     ```
  2. Enter `alpha beta gamma`, press `Esc`, `0`, then press `e`
  repeatedly.
  Confirm the cursor advances through the ends of `alpha`, `beta`, and
  `gamma`.
  3. Enter `hello world`, press `Esc`, `0`, `w`, then `C`.
     Confirm `world` is deleted and the composer enters Insert mode.
  4. Enter a multiline prompt with `hello` above `world`, press `Esc`,
  `k`, `$`, and then `D`.
     Confirm the newline is preserved and the two lines do not join.
  5. At the same boundary, press `C` and type `!`.
  Confirm the composer enters Insert mode and yields `hello!` above
  `world`, preserving the newline.
  
  Targeted automated verification:
  - `just fix -p codex-tui`
  - `just argument-comment-lint-from-source -p codex-tui -p codex-config`
  - `cargo insta pending-snapshots` reports no pending snapshots.
  - `just test -p codex-tui` validates the new Vim and keymap snapshot
  coverage, but the command remains red due to two reproducible unrelated
  failures in `app::tests::update_feature_flags_disabling_guardian_*`.
  
  ## Validation Note
  
  The workspace-wide `just argument-comment-lint` form is currently
  blocked during Bazel analysis by the existing LLVM `compiler-rt` missing
  `include/sanitizer/*.h` failure; package-scoped source linting for the
  changed Rust crates passed.

  Felipe Coury · 2026-05-27 07:36:52 -07:00
  aa184548b1
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• feat: gate dedicated memories tools in config (#24600)

  ## Why
  
  The memories extension already has dedicated `list`, `read`, `search`,
  and `add_ad_hoc_note` tools, but app-server registration was still
  disabled. The memories app collaborator needs an explicit config switch
  so those native extension tools can be exposed intentionally, without
  making ordinary memory prompt usage automatically register the dedicated
  tool surface.
  
  ## What changed
  
  - Added `[memories].dedicated_tools`, defaulting to `false`, to
  `MemoriesToml` / `MemoriesConfig`.
  - Regenerated `core/config.schema.json` for the new setting.
  - Registered the memories extension as a `ToolContributor`, while
  keeping tool contribution gated on both memories being enabled and
  `dedicated_tools = true`.
  - Added tests for the disabled default, the enabled dedicated-tools
  path, and installer registration.
  
  ## Verification
  
  - `just test -p codex-config -p codex-memories-extension`

  jif-oai · 2026-05-26 18:18:58 +02:00
  ef6528c6c7