551 Commits

• [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
• [codex] add current time reminder delivery mode config (#30031)

  ```python
  delivery_mode = "any_inference" # default
  delivery_mode = "after_user_or_tool_output" # new mode
  ``` 
  
  ## Validation
  - just test -p codex-core load_config_resolves_current_time_reminder
  - just test -p codex-core
  lock_contains_prompts_and_materializes_features

  rka-oai · 2026-06-25 19:06:43 +00:00
  e8d4a1a411
• [codex] current time reminder interval to be set to 0 (#30029)

  A zero interval lets callers request a reminder at every
  otherwise-eligible inference boundary.
  
  ## Validation
  - just test -p codex-core load_config_resolves_current_time_reminder

  rka-oai · 2026-06-25 18:30:53 +00:00
  cc78903379
• core: raise token budget message limits (#29970)

  ## Why
  
  Token-budget reminder and guidance messages can require more than 1,000
  bytes to provide useful model-facing instructions. At the same time,
  these strings are injected into model-visible context, so their size
  must remain tightly bounded in response to the P0 context-growth
  concern. A 2,000-byte runtime cap provides additional room without
  allowing the substantially larger context growth of a 4 KiB limit.
  
  ## What changed
  
  - raises the runtime byte limits for token-budget reminder templates and
  guidance messages from 1,000 to 2,000
  - raises the corresponding JSON Schema `maxLength` values to 2,000
  - regenerates `codex-rs/core/config.schema.json`
  
  ## Testing
  
  - `just test -p codex-features`
  - `just test -p codex-core load_config_resolves_token_budget_config
  load_config_rejects_invalid_token_budget_reminder_template`
  
  The full `codex-core` test run completed 2,858 tests successfully and
  encountered seven unrelated environment-sensitive failures involving
  Seatbelt/network environment assertions, MCP capability setup, and abort
  timing.

  Michael Bolin · 2026-06-25 05:05:32 +00:00
  22f12568e1
• 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
• core: add configurable <context_window_guidance> message (#29936)

  ## Why
  
  This PR adds a configurable `<context_window_guidance>` developer
  section immediately after `<context_window>`. Harness integrations need
  this section to give the model deployment-specific instructions for
  preparing for context-window transitions.
  
  ## What changed
  
  - Add an optional `features.token_budget.guidance_message` config with a
  1,000-byte runtime cap and generated schema support.
  - Render configured guidance as a developer `ContextualUserFragment`
  wrapped in `<context_window_guidance>` immediately after
  `<context_window>`.
  - Omit the section when guidance is unset, empty, or whitespace-only.
  - Preserve the resolved value in config locks and classify persisted
  guidance as contextual developer content.
  - Add integration coverage for rendered content and ordering.

  Michael Bolin · 2026-06-24 18:03:44 -07:00
  f15df624a6
• [codex] nest sleep config under current time reminder (#29910)

  ## Summary
  
  - move sleep tool enablement from top-level `[features].sleep_tool` to
  `[features.current_time_reminder].sleep_tool`
  - remove the standalone `Feature::SleepTool` flag and gate `clock.sleep`
  from resolved current-time configuration
  - update config schema, config-lock materialization, and existing sleep
  coverage
  
  Stacked on #29907.

  rka-oai · 2026-06-24 17:49:00 -07:00
  35f5d02464
• Add a connector declaration snapshot (#29851)

  ## Why
  
  Connector declarations currently enter Codex through broad plugin
  capability summaries, then MCP setup, turn tooling, and `app/list` each
  reconstruct the same information. That makes executor-selected
  connectors difficult to add without coupling connector behavior to the
  host plugin loader.
  
  This PR introduces a small connector-owned value that later stack layers
  can populate before thread startup.
  
  ## What changed
  
  - Move the pure app-declaration parser into `codex-connectors`,
  preserving declaration order and category cleanup while leaving
  host-side validation and deduplication unchanged.
  - Add an immutable `ConnectorSnapshot` with ordered connector IDs and
  plugin display-name provenance.
  - Adapt the existing local-plugin capability summaries into that
  snapshot at current consumer boundaries.
  - Use the snapshot for MCP tool provenance, turn connector inventory,
  and `app/list`.
  - Keep the crate API narrow: no test-only snapshot accessors are
  exposed.
  
  The externally visible behavior is unchanged. Connector tools still come
  from the orchestrator-owned `/ps/mcp` server, and local plugin
  enablement remains owned by the existing plugin loader.
  
  ## Stack scope
  
  This is the foundation only. It does not read selected executor packages
  or change thread startup. #29852 adds the executor-backed declaration
  reader, and #29856 composes selected declarations into a thread
  snapshot.

  jif · 2026-06-24 23:24:01 +01:00
  4e0f863df3
• 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
• [core] debounce current-time reminders by elapsed time (#29659)

  ## Summary
  - rename `reminder_interval_model_requests` to
  `reminder_interval_seconds`
  - read the configured time provider before every model request and
  inject a reminder only after the configured number of seconds has
  elapsed
  - preserve immediate first delivery and forced delivery after compaction
  changes the context window
  
  ## Tests
  - `just test -p codex-core current_time_reminder`

  rka-oai · 2026-06-23 10:13:27 -07:00
  9fe689783d
• Namespace multi-agent v2 tools under collaboration (#29067)

  ## Summary
  
  Multi-agent v2 tools now use the fixed `collaboration` namespace when
  namespace tools are available. This keeps the model-visible hint and the
  actual tool surface aligned around `functions.collaboration.*`, without
  exposing an unshipped namespace knob to users.
  
  The PR also removes the old `features.multi_agent_v2.tool_namespace`
  config/schema surface, updates the MAv2 test fixtures for namespaced
  calls, and fixes stale `TurnContext.features` references that were
  breaking `codex-core` builds.
  
  ## Changes
  
  - Expose MAv2 tools under `collaboration` instead of relying on a
  configurable namespace.
  - Remove `tool_namespace` from MAv2 TOML config, resolved config,
  validation, schema, and tests.
  - Update tool-planning and integration fixtures to assert or emit
  namespaced MAv2 tool calls.
  - Read feature state through `TurnContext.config.features` in the
  multi-agent mode context paths.
  
  ## Testing
  
  - `just write-config-schema`
  - `just test -p codex-features`

  jif · 2026-06-23 14:15:20 +02:00
  49614a0391
• 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
• Register full CDP requirements feature (#28769)

  register cdp requirements feature flag

  Samuel Yuan · 2026-06-22 22:08:15 +00:00
  ff37f4a6ef
• fix(config): address permission profile review follow-ups (#29479)

  ## Summary
  
  - rename `Config::permission_profile_allowed` to
  `is_permission_profile_allowed`
  - use `BUILT_IN_PERMISSION_PROFILE_DANGER_FULL_ACCESS` in the TUI and
  its assertion
  - follow up on the late review comments from #26678
  
  The previous `:danger-no-sandbox` value was an invalid built-in profile
  ID. #26678 corrected it to `:danger-full-access`; this PR centralizes
  the value to prevent future drift.
  
  ## Testing
  
  - Not run per request; `cargo fmt` only
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-22 21:05:50 +00:00
  6db576895a
• permission profiles: expose availability to clients (#26678)

  ## Why
  
  `permissionProfile/list` currently advertises every built-in and
  configured profile even when effective enterprise requirements prevent
  selecting it. That forces each client to reconstruct policy from
  lower-level requirement fields, which is easy to miss and difficult to
  keep consistent.
  
  The catalog should remain complete so clients can explain that an option
  was disabled by an administrator, while also reporting whether each
  profile is selectable.
  
  ## What
  
  - Add an `allowed` field to each permission profile summary.
  - Build a shared catalog from the effective config and current
  requirements, including `allowed_sandbox_modes`, `allowed_permissions`,
  and filesystem restrictions.
  - Use the shared catalog in app-server and the TUI so disallowed
  profiles remain visible but cannot be selected.
  - Use the canonical `:danger-full-access` profile ID in the TUI.
  - Update the app-server schemas, API documentation, behavioral tests,
  and TUI snapshots.
  
  ## Scope
  
  This PR targets `main` directly and is independent of #24852. It
  preserves the current behavior where built-in profiles are constrained
  by sandbox-mode requirements and `allowed_permissions` applies to
  configured profiles.
  
  ## Testing
  
  - `just test -p codex-core
  permission_profile_catalog_marks_profiles_disallowed_by_requirements`
  - `just test -p codex-app-server permission_profile_list`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-tui profile_permissions`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`
  - `just fmt`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Joey Trasatti <joey.trasatti@openai.com>

  viyatb-oai · 2026-06-22 13:48:09 -07:00
  ced3e4b9a7
• [codex] configure rollout budget reminder thresholds (#29423)

  ## Summary
  
  Instead of:
  
      reminder_interval_tokens = 65_536
  
  allow users to configure explicit remaining-token reminder thresholds:
  
  reminder_at_remaining_tokens = [65_536, 32_768, 16_384, 8_192, 4_096,
  2_048, 1_024, 512]
  
  ## Validation
  
  - CARGO_INCREMENTAL=0 just test -p codex-core rollout_budget: 9 passed
  - just fix -p codex-core
  - just fmt

  rka-oai · 2026-06-22 13:25:48 -07:00
  bd5bd953fb
• PAC 2 - Add shared auth system proxy contract (#26707)

  ## Summary
  
  Stacked on #26706.
  
  Adds the shared auth/system-proxy contract that later platform resolver
  PRs plug into. This PR moves Codex-owned auth and startup HTTP clients
  through a common route-aware boundary, but does not yet add Windows or
  macOS system proxy resolution.
  
  The default path remains unchanged when `respect_system_proxy` is absent
  or disabled.
  
  ## Implementation
  
  - Adds `codex-client/src/outbound_proxy.rs` with the shared
  route-selection model:
    - `OutboundProxyConfig`;
    - `ClientRouteClass`;
    - `RouteFailureClass`;
    - `build_reqwest_client_for_route`.
  - Preserves the existing reqwest/default-client behavior when no route
  config is supplied.
  - Uses the fixed MVP routing policy when route config is supplied:
  platform system/PAC/WPAD discovery, then explicit env proxy variables,
  then direct connection.
  - Keeps platform-specific system discovery behind the shared client
  boundary. This PR provides the contract and fallback behavior; later
  resolver PRs plug in Windows and macOS discovery.
  - Adds `login::AuthRouteConfig` so auth call sites depend on a small
  policy type instead of platform resolver details.
  - Maps the resolved `Config.respect_system_proxy` boolean into
  `AuthRouteConfig` for auth-owned clients.
  - Wires the route config through browser login, device-code login,
  access-token login, login status, logout/revoke, token refresh, API-key
  exchange, app-server account login, TUI/app startup, cloud-config
  bootstrap, cloud tasks, plugin auth, and exec startup config loading.
  
  ## End-user behavior
  
  - No behavior changes by default.
  - When `respect_system_proxy = true`, auth-owned clients opt into the
  shared route-aware client path.
  - On platforms without a resolver implementation in this PR, system
  discovery is unavailable and the route-aware path falls back to explicit
  env proxy handling, then direct connection.
  - Custom CA handling remains separate from proxy route selection and
  still runs through the shared client builder.
  - No proxy URLs, PAC contents, or resolved platform details are exposed
  through the public config surface introduced here.
  
  ## Tests
  
  Adds or updates coverage for:
  
  - preserving default auth-client fallback behavior when no route config
  is provided;
  - injected environment-proxy fallback without mutating process
  environment;
  - existing login-server E2E flows using explicit `auth_route_config:
  None` to guard unchanged default behavior;
  - updated auth manager, login, logout, cloud-config, startup, and
  plugin-auth call sites passing route config explicitly.

  canvrno-oai · 2026-06-22 13:03:11 -07:00
  1659c4a629
• core: remove unused permissions cwd plumbing (#29468)

  ## Why
  
  `compile_scoped_filesystem_pattern()` accepted a `_policy_cwd` parameter
  even though scoped glob compilation no longer uses the policy working
  directory. Keeping that unused argument forced the surrounding
  permissions compilation path to keep forwarding `policy_cwd` through
  call sites that did not need it, making the API look more dependent on
  cwd resolution than it is.
  
  ## What changed
  
  Removed the unused cwd parameter from
  `compile_scoped_filesystem_pattern()` and the callers that only
  forwarded it: `compile_filesystem_permission()`,
  `compile_permission_profile()`, and
  `compile_permission_profile_selection()`. Workspace root resolution
  still keeps `policy_cwd`, because that path still resolves relative
  roots against the active policy cwd.
  
  Relevant code:
  [`codex-rs/core/src/config/permissions.rs`](https://github.com/openai/codex/blob/b8b9816102e064dae4488ec130cf560f63c1ab78/codex-rs/core/src/config/permissions.rs#L346).
  
  ## Verification
  
  - `just test -p codex-core config::permissions`
  - `just test -p codex-core` was also run after building
  `test_stdio_server`; it passed the touched permissions coverage but
  still reported unrelated existing failures in `cli_stream` and shell
  snapshot tests.

  Michael Bolin · 2026-06-22 12:31:52 -07:00
  e48ab86693
• Simplify multi-agent mode controls (#29324)

  ## Why
  
  Multi-agent delegation policy was split across `multiAgentMode`,
  `features.multi_agent_mode`, and `usage_hint_enabled`. These controls
  could disagree: a requested mode could be downgraded by the feature
  flag, and disabling usage hints also disabled mode instructions.
  
  Some clients also need multi-agent tools without adding
  delegation-policy text to model context. The previous two-mode API could
  not express that directly.
  
  ## What changed
  
  `multiAgentMode` is now the only live delegation-policy control:
  
  | Mode | Behavior |
  | --- | --- |
  | `none` | Keep multi-agent tools available without adding mode
  instructions. |
  | `explicitRequestOnly` | Only delegate after an explicit user request.
  |
  | `proactive` | Delegate when parallel work materially improves speed or
  quality. |
  
  - new threads default to `explicitRequestOnly`; omitting the mode on
  later turns keeps the current value
  - thread start, resume, fork, and settings responses always report the
  concrete current mode instead of `null`
  - mode selection remains sticky across turns and resume
  - usage-hint text no longer controls whether mode instructions apply
  - `features.multi_agent_mode` and `usage_hint_enabled` remain accepted
  as ignored compatibility settings so existing configs continue to load
  - app-server documentation and generated schemas describe the three-mode
  API
  
  ## Tests
  
  - `just test -p codex-core multi_agent_mode`
  - `just test -p codex-core multi_agent_v2_config_from_feature_table`
  - `just test -p codex-core spawn_agent_description`
  - `just test -p codex-features`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server multi_agent_mode`

  jif · 2026-06-22 10:05:36 +02:00
  c03742ca0a
• [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
• Add per-turn multi-agent mode (#28685)

  ## Why
  
  Multi-agent v2 currently carries an explicit-request-only delegation
  rule in its static usage hint. That provides a safe default, but it
  prevents clients from selecting proactive delegation per turn without
  changing static guidance or rewriting prior model context.
  
  This change makes delegation mode a session selection that can be
  updated through `turn/start`, while deriving the effective model-visible
  mode separately for each turn. Eligible multi-agent v2 turns remain
  explicit-request-only unless proactive mode is both selected and
  enabled.
  
  ## What changed
  
  - Add the experimental `turn/start.multiAgentMode` parameter with
  `explicitRequestOnly` and `proactive` values. Omission retains the
  loaded session's current optional selection.
  - Add the default-off `features.multi_agent_mode` feature gate. Eligible
  multi-agent v2 turns use the selected mode when enabled; an unset
  selection or disabled gate resolves to `explicitRequestOnly`.
  - Treat mode prompting as inapplicable for multi-agent v1 and other
  unsupported session configurations, producing no multi-agent mode
  developer message rather than rejecting the turn.
  - Move the explicit-request-only rule out of the static v2 usage hint
  and into a bounded, tagged developer context fragment.
  - Emit the effective mode in initial context and only when that
  effective mode changes on later turns.
  - Persist the effective mode in `TurnContextItem` as the durable
  baseline for resume and context-update comparisons.
  
  Historical rollout items are not rewritten. Later mode developer
  messages establish the current rule incrementally.
  
  ## Not covered
  
  - Initial selection through `thread/start` and selected-mode reporting
  from thread lifecycle/settings APIs; those are isolated in the stacked
  #28792.
  - A TUI control or slash command for selecting the mode.
  - Persisting a preferred mode to `config.toml`; selection remains
  session/turn scoped.
  - Changes to multi-agent concurrency limits, tool availability, or model
  catalog capability declarations.
  - Rewriting historical rollout prompt items. Cold resume restores the
  latest persisted effective mode when available while leaving historical
  developer messages intact.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-core multi_agent_mode`
  - Focused app-server coverage verifies that `turn/start.multiAgentMode`
  produces proactive developer instructions for an eligible v2 turn.
  
  ## Stack
  
  Followed by #28792, which adds `thread/start` initialization and
  lifecycle/settings observability.

  Shijie Rao · 2026-06-18 22:47:51 -07:00
  fc8c6b7384
• 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
• Expose selecte namespaces as direct model tools (#28825)

  ## Why
  
  Som tools, such as history and notes, must remain top-level when MCP
  deferral is enabled while staying unavailable through code-mode `exec`.
  
  ## What changed
  
  - Added `features.code_mode.direct_only_tool_namespaces`.
  - Classified matching MCP tools as `DirectModelOnly`.
  - Kept those tools top-level in `code_mode_only`.
  - Excluded them from `tool_search` deferral and the nested `exec`
  surface.
  - Updated the generated config schema.
  
  ## Validation
  
  - `code_mode_only_exposes_direct_model_only_mcp_namespaces`
  - `load_config_resolves_code_mode_config`

  Won Park · 2026-06-18 04:07:54 +00:00
  78a9e169bb
• Replace SkillsManager with SkillsService (#28705)

  ## Why
  
  Host skill discovery was still exposed as a manager even though it is a
  process-owned service shared by sessions, the app-server catalog, and
  file-watcher invalidation. The skills extension also consumed an ad hoc
  loaded-skills wrapper instead of a named immutable snapshot.
  
  ## What changed
  
  - replace `SkillsManager` with concrete `SkillsService`
  - make the service cache and return immutable `HostSkillsSnapshot`
  values
  - migrate the skills extension host provider to the snapshot boundary
  - migrate app-server catalog, watcher, and invalidation paths to the
  service
  
  This keeps the service limited to host discovery, caching, roots, and
  invalidation. Catalog rendering and invocation remain extension
  responsibilities for the next stacked change.

  jif · 2026-06-17 17:01:06 +02:00
  0318381762
• 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
• feat: render typed envelopes for multi-agent v2 messages (#28368)

  ## Why
  
  Multi-agent v2 messages need a consistent, model-visible envelope that
  identifies what kind of interaction occurred, who sent it, and which
  agent it targets. Previously, encrypted deliveries exposed only
  `encrypted_content`, while child completion used the legacy
  `<subagent_notification>` shape. That meant the client could not
  consistently present `NEW_TASK`, `MESSAGE`, and `FINAL_ANSWER` using the
  same format.
  
  This change adds the routing envelope as plaintext while keeping task
  and message payloads encrypted. No new Responses API field is required:
  an encrypted delivery is represented as an `input_text` header
  immediately followed by its existing `encrypted_content` item.
  
  Every envelope now follows this shape:
  
  ```text
  Message Type: <NEW_TASK | MESSAGE | FINAL_ANSWER>
  Task name: <recipient agent path>
  Sender: <author agent path>
  Payload:
  <message payload>
  ```
  
  ## Message types
  
  ### `NEW_TASK`
  
  `NEW_TASK` is used when the recipient should begin a new turn, including
  an initial `spawn_agent` task and a later `followup_task`.
  
  For a root agent spawning `/root/worker`, the request contains a
  plaintext envelope followed by the encrypted task:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root",
    "recipient": "/root/worker",
    "content": [
      {
        "type": "input_text",
        "text": "Message Type: NEW_TASK\nTask name: /root/worker\nSender: /root\nPayload:\n"
      },
      {
        "type": "encrypted_content",
        "encrypted_content": "<encrypted task payload>"
      }
    ]
  }
  ```
  
  Conceptually, the model receives:
  
  ```text
  Message Type: NEW_TASK
  Task name: /root/worker
  Sender: /root
  Payload:
  Review the authentication changes and report any regressions.
  ```
  
  ### `MESSAGE`
  
  `MESSAGE` is used for a queued `send_message` delivery. It communicates
  with an existing agent without starting a new turn.
  
  For `/root/worker` reporting progress to the root agent, the request
  contains:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root/worker",
    "recipient": "/root",
    "content": [
      {
        "type": "input_text",
        "text": "Message Type: MESSAGE\nTask name: /root\nSender: /root/worker\nPayload:\n"
      },
      {
        "type": "encrypted_content",
        "encrypted_content": "<encrypted message payload>"
      }
    ]
  }
  ```
  
  Conceptually, the model receives:
  
  ```text
  Message Type: MESSAGE
  Task name: /root
  Sender: /root/worker
  Payload:
  The protocol tests pass; I am checking the resume path now.
  ```
  
  ### `FINAL_ANSWER`
  
  `FINAL_ANSWER` is emitted when a child agent reaches a terminal state
  and reports its result to its parent. Completion payloads are already
  available locally, so the complete envelope is represented as plaintext
  rather than as a plaintext header plus encrypted content.
  
  For `/root/worker` completing work for the root agent, the request
  contains:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root/worker",
    "recipient": "/root",
    "content": [
      {
        "type": "input_text",
        "text": "Message Type: FINAL_ANSWER\nTask name: /root\nSender: /root/worker\nPayload:\nNo regressions found."
      }
    ]
  }
  ```
  
  The model-visible form is:
  
  ```text
  Message Type: FINAL_ANSWER
  Task name: /root
  Sender: /root/worker
  Payload:
  No regressions found.
  ```
  
  Errored, shut down, and missing agents also use `FINAL_ANSWER`, with a
  terminal-status description in the payload.
  
  ## What changed
  
  - Render `NEW_TASK` or `MESSAGE` in
  `InterAgentCommunication::to_model_input_item`, based on whether the
  encrypted delivery starts a turn.
  - Replace the multi-agent v2 `<subagent_notification>` completion
  payload with a model-visible `FINAL_ANSWER` envelope.
  - Document `Task name`, `Sender`, and `Payload` consistently in the
  multi-agent developer instructions.
  - Prevent local-only history projections from treating an encrypted
  message's plaintext header as the complete assistant message.
  - Preserve rollout-trace interaction edges when an agent message
  contains both plaintext and encrypted content.
  
  Legacy multi-agent behavior remains unchanged.
  
  ## Verification
  
  - `just test -p codex-protocol`
  - `just test -p codex-rollout-trace`
  - `just test -p codex-web-search-extension`
  - `just test -p codex-core
  encrypted_multi_agent_v2_spawn_sends_agent_message_to_child`
  - `just test -p codex-core
  plaintext_multi_agent_v2_completion_sends_agent_message`
  - `just test -p codex-core
  multi_agent_v2_followup_task_completion_notifies_parent_on_every_turn`
  - `just test -p codex-core
  multi_agent_v2_completion_queues_message_for_direct_parent`

  jif · 2026-06-16 11:46:59 +02:00
  5b22a8e5b1
• [codex] update multi-agent v2 prompts (#28283)

  ## Summary
  
  - align the default multi-agent v2 root and subagent hints with the
  evaluated prompt guidance for direct collaboration-tool calls, parallel
  delegation, and shared workspaces
  - keep the current `interrupt_agent` tool name and existing
  concurrency-hint placement, with the explicit no-spawn instruction last
  - document the context tradeoff between `fork_turns="none"` and
  `fork_turns="all"` in the v2 `spawn_agent` description
  - extend the focused prompt and tool-surface tests
  
  ## Why
  
  The evaluated multi-agent prompt includes operational guidance that is
  missing from the current Codex defaults. This applies that guidance to
  the current tool surface without restoring stale `close_agent` or
  duplicated concurrency wording.
  
  ## User impact
  
  Multi-agent v2 receives clearer instructions about when and how to
  parallelize work, how agent workspaces interact, and how `fork_turns`
  affects subagent context. The existing default opt-out behavior remains
  in place.
  
  ## Testing
  
  - `just fmt`
  - `just test -p codex-core
  multi_agent_v2_default_usage_hints_use_configured_thread_cap`
  - `just test -p codex-core
  multi_agent_feature_selects_one_agent_tool_family`

  jif · 2026-06-15 12:21:02 +02:00
  127224cacc
• Add selected-plugin precedence and attribution to the MCP catalog (#27884)

  ## Why
  
  **In short:** this PR resolves already-discovered MCP registrations. It
  does not read selected plugins or discover their MCP servers.
  
  The resolved MCP catalog currently builds config and auto-discovered
  plugin registrations before runtime contributors are applied. A
  thread-selected plugin needs a distinct precedence tier in that same
  initial resolution pass: otherwise a disabled lower-precedence winner
  can leave stale name-level state behind, and the winning MCP tools
  cannot be attributed to the selected package reliably.
  
  This PR adds that catalog boundary before executor discovery is
  connected.
  
  ## What changed
  
  - Added an explicit selected-plugin registration tier between
  auto-discovered plugins and explicit config.
  - Collected selected-plugin contributions before the initial catalog
  build, while leaving compatibility and generic extension overlays in
  their existing runtime phase.
  - Retained the winning plugin ID and display name directly on
  plugin-owned catalog registrations.
  - Derived MCP tool provenance from the winning catalog entry instead of
  joining against local-only plugin summaries.
  - Retained the winning selected server's tool approval policy in the
  running connection manager, so a selected registration cannot inherit
  approval behavior from a losing local plugin.
  - Kept remembered approval session-scoped for selected plugins until
  there is an authority-aware persistence contract; Codex will not write
  approval back to an unrelated local plugin.
  - Preserved existing name-level disabled vetoes for discovered plugins
  and config, while keeping a selected package's own disabled registration
  scoped to that registration.
  - Preserved deterministic selection order and existing config,
  compatibility, and extension precedence.
  
  The resulting order is:
  
  ```text
  auto-discovered plugin
    < selected plugin
    < explicit config
    < compatibility registration
    < extension overlay
  ```
  
  ## Behavior and scope
  
  This is a catalog and provenance change only. No production host
  contributes selected-plugin MCP registrations yet, so existing local MCP
  behavior remains unchanged.
  
  The stacked follow-up, #27870, installs the executor plugin provider
  that produces these registrations. App-server activation remains a
  separate final step.
  
  ## Verification
  
  Focused tests cover precedence, deterministic selected-plugin conflicts,
  disabled-veto behavior across catalog phases, managed requirements
  before selected-plugin resolution, winning-server approval policy, and
  attribution when local and selected packages share an ID or server name.
  CI owns execution of the test suite.

  jif · 2026-06-15 11:10:51 +02:00
  c3a479620f
• 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: use encrypted local secrets for MCP OAuth (#27541)

  ## Summary
  
  - store MCP OAuth credentials in the configured auth credential backend
  - support encrypted-local OAuth storage, including legacy keyring
  migration
  - propagate the credential backend through MCP refresh, session, CLI,
  and app-server paths
  
  ## Stack
  
  1. #27504 — config and feature flag
  2. #27535 — auth-specific secret namespaces
  3. #27539 — encrypted CLI auth storage
  4. this PR — encrypted MCP OAuth storage
  
  This is a parallel review stack; the original #17931 remains unchanged.
  
  ## Tests
  
  - `just test -p codex-rmcp-client` (the transport round-trip test passed
  after building the required `codex` binary and retrying)
  - `just test -p codex-mcp`
  - `just test -p codex-app-server
  refresh_config_uses_latest_auth_keyring_backend`
  - `just test -p codex-core
  refresh_mcp_servers_is_deferred_until_next_turn`
  - `just test -p codex-cli mcp`
  - `just fix -p codex-rmcp-client -p codex-mcp -p codex-core -p codex-cli
  -p codex-app-server -p codex-protocol`
  - `just bazel-lock-check`

  Celia Chen · 2026-06-12 22:03:51 +00:00
  9915d34684
• feat: use encrypted local secrets for CLI auth (#27539)

  ## Why
  
  Windows Credential Manager limits generic credential blobs to 2,560
  bytes. Large serialized ChatGPT auth payloads can exceed that limit, so
  keyring-mode CLI auth needs a backend that keeps only the encryption key
  in the OS keyring and stores the payload in Codex's encrypted
  local-secrets file.
  
  This is the third PR in the encrypted-auth stack:
  
  1. #27504 — feature and config selection
  2. #27535 — auth-specific local-secrets namespaces
  3. This PR — CLI auth implementation and activation
  4. MCP OAuth implementation and activation
  
  ## What Changed
  
  - Added encrypted CLI-auth storage using the `CliAuth` secrets
  namespace.
  - Preserved direct keyring storage for platforms/configurations where it
  remains selected.
  - Selected the backend consistently for login, logout, refresh,
  device-code login, auth loading, and login restrictions.
  - Threaded resolved bootstrap/full config through CLI, exec, TUI,
  app-server account handling, cloud config, and cloud tasks.
  - Removed stale `auth.json` fallback data after successful encrypted
  saves and removed encrypted, direct-keyring, and fallback data during
  logout.
  - Added storage and integration coverage for both direct and encrypted
  keyring modes.
  
  MCP OAuth persistence is intentionally left to the next PR.
  
  ## Validation
  
  - `just test -p codex-login` — 131 passed
  - `just test -p codex-cli` — 280 passed
  - `just test -p codex-app-server v2::account` — 25 passed
  - `just test -p codex-cloud-config service` — 21 passed, 7 skipped
  - `just fix -p codex-login`
  - `just fix -p codex-cli`
  - `just fmt`

  Celia Chen · 2026-06-12 21:23:50 +00:00
  56c97e3b5c
• 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
• chore: prompt MAv2 (#27919)

  Prompt update of MAv2

  jif · 2026-06-12 20:17:12 +02:00
  84520225b9
• 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
• [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
• Resolve MCP server registrations through a catalog (#27634)

  ## Why
  
  MCP servers currently come from user config, local plugins,
  compatibility Apps synthesis, and host extensions. Those sources were
  composed by mutating a shared map, leaving registration identity,
  precedence, removal, and provenance implicit in assembly order.
  
  Before adding executor-owned MCPs, Codex needs one durable resolution
  boundary above `McpConnectionManager`. This PR introduces that boundary
  while preserving current server configuration, policy, and runtime
  behavior. Executor-scoped registrations and explicit policy layers
  remain follow-ups.
  
  ## What changed
  
  - Add typed `McpServerRegistration` inputs and an immutable
  `ResolvedMcpCatalog` in `codex-mcp`.
  - Retain each registration's complete `McpServerConfig`, including its
  environment binding, while recording its source and provenance.
  - Preserve the existing structural precedence between plugin, config,
  compatibility, and ordered extension sources.
  - Resolve equal-precedence actions by contribution order; provenance IDs
  are used only for diagnostics and cannot affect the winner.
  - Preserve extension removals and the existing name-scoped `enabled =
  false` veto.
  - Report same-tier conflicts with every contender and the final catalog
  outcome, including whether the winning action registers or removes the
  server.
  - Require MCP contributors to provide a stable diagnostic identity.
  - Derive materialized server maps and plugin ownership from the resolved
  catalog.
  
  `McpConnectionManager`, transport startup, tool calls, and resource
  routing continue to consume the same effective `McpServerConfig` values.
  
  ## Scope
  
  This PR does not add new MCP capabilities or change user-visible
  behavior. It does not add executor plugin discovery, thread-scoped
  registrations, dynamic refresh generations, or new user/managed policy
  semantics.
  
  ## Verification
  
  - Added focused catalog coverage for source precedence, complete
  configuration preservation, disabled vetoes, plugin ownership,
  contribution-order tie breaking, removal outcomes, and conflict
  diagnostics.
  - Extended hosted Apps coverage for ordered extension removal and
  Apps-disabled hosts with and without the hosted extension installed.
  - `cargo check -p codex-mcp --tests -p codex-extension-api -p
  codex-core`

  jif · 2026-06-11 21:54:52 +02:00
  4a5a676499
• [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
• multi-agent: move concurrency guidance into v2 usage hints (#27569)

  ## Why
  
  Native Codex currently teaches multi-agent concurrency through the
  `spawn_agent` tool description, while bridge-driven evals frame the same
  limit as a shared pool of active agent slots. That mismatch makes the
  model-facing story harder to reason about, especially because the
  tool-level wording does not make it explicit that the limit covers the
  whole agent team, including the current agent.
  
  This change gives native Codex the same mental model: tell the root
  agent and subagents how many active slots exist, and remove the separate
  `spawn_agent` limit wording.
  
  ## What changed
  
  - Extend the built-in `multi_agent_v2` root and subagent usage hints
  with shared-slot guidance derived from the resolved
  `max_concurrent_threads_per_session` value.
  - Keep the complete default hints in `MultiAgentV2Config` so initial
  context and forked histories consume the same canonical strings.
  - Drop the redundant `spawn_agent` description text and remove the
  now-unused limit plumbing from the tool spec path.
  
  ## Testing
  
  - `just test -p codex-core usage_hint`
  - `just test -p codex-core
  multi_agent_v2_default_session_thread_cap_counts_root`
  - `just test -p codex-core
  multi_agent_v2_default_usage_hints_use_configured_thread_cap`
  - `just test -p codex-core
  spawn_agent_tool_v2_requires_task_name_and_lists_visible_models`
  - `just test -p codex-core
  multi_agent_feature_selects_one_agent_tool_family`

  jif · 2026-06-11 12:41:44 +02:00
  0870352241
• 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
• Route hosted Apps MCP through extensions (#27191)

  ## Stack
  
  - Base: #27184
  - This PR is the second vertical and should be reviewed against
  `jif/external-plugins-1`, not `main`.
  
  ## Why
  
  CCA is moving toward a split runtime where the orchestrator may have no
  filesystem or executor, but it still needs to activate remotely hosted
  plugin components. HTTP MCP servers are the simplest complete example:
  they need configuration and host authentication, but they do not need an
  executor process.
  
  The Apps MCP endpoint is currently synthesized by a special-purpose
  loader inside the MCP runtime. That works locally, but it leaves hosted
  MCP activation outside the extension model being established in #27184.
  It also makes the Apps path a poor foundation for plugins whose skills,
  MCP servers, connectors, and hooks may come from different sources or
  execute in different places.
  
  This PR moves that one behavior behind an extension-owned contribution
  while preserving the existing local fallback. It deliberately does not
  introduce a generic plugin activation framework.
  
  ## What changed
  
  ### MCP extension contribution
  
  `codex-extension-api` gains an ordered `McpServerContributor` contract.
  A contributor returns typed `Set` or `Remove` overlays for MCP server
  configuration; later contributors win for the names they own.
  
  The contract stays at the existing MCP configuration boundary.
  Extensions do not create a second connection manager or transport
  abstraction.
  
  ### Hosted Apps MCP extension
  
  A new `codex-mcp-extension` contributes the reserved `codex_apps` server
  from the existing Apps feature, ChatGPT base URL, path override, and
  product SKU configuration.
  
  When `apps_mcp_path_override` is enabled for `https://chatgpt.com`, the
  resulting streamable HTTP endpoint is
  `https://chatgpt.com/backend-api/ps/mcp`. The existing ChatGPT-auth gate
  remains authoritative, so this server can run in an orchestrator-only
  process without being exposed for API-key sessions.
  
  ### One resolved runtime view
  
  `McpManager` now distinguishes three views:
  
  - **configured:** config- and plugin-backed servers before extension
  overlays;
  - **runtime:** configured servers plus host-installed extension
  contributions;
  - **effective:** runtime servers after auth gating and compatibility
  built-ins.
  
  App-server installs the hosted MCP extension and uses the runtime view
  for thread startup, refresh, status, threadless resource reads,
  connector discovery, and MCP OAuth lookup. This keeps
  `mcpServer/oauth/login` consistent with the servers exposed by the other
  MCP APIs. The hosted Apps server itself continues to use existing
  ChatGPT host authentication rather than MCP OAuth.
  
  ## Compatibility
  
  Hosts that do not install the MCP extension retain the existing Apps MCP
  synthesis path. This preserves current local-only, CLI, and
  standalone-host behavior while app-server exercises the extension path.
  
  Disabling Apps removes the reserved `codex_apps` entry, and losing
  ChatGPT auth removes it from the effective runtime view. Executor
  availability is not consulted for this HTTP transport.
  
  ## Follow-ups
  
  The next vertical will resolve a manifest-declared stdio MCP server from
  an executor-selected plugin root and execute it in the environment that
  owns that root. Later verticals can add backend-owned skills, connector
  metadata, hooks, durable selection semantics, and incremental local
  convergence without changing the component-specific runtime boundaries
  introduced here.
  
  ## Verification
  
  Focused coverage was added for:
  
  - contributing the hosted Apps MCP at `/backend-api/ps/mcp` without an
  executor;
  - requiring ChatGPT auth in the effective runtime view;
  - removing a reserved configured Apps server when the Apps feature is
  disabled.
  
  `cargo check -p codex-app-server -p codex-mcp-extension -p
  codex-extension-api -p codex-mcp` passed. Tests and Clippy were not run
  locally under the current development instruction; CI provides the full
  validation pass.

  jif · 2026-06-09 22:44:16 +02:00
  4ec3b8eeea
• Add extra config to StoredThread, leave empty for now (#27092)
  Boyang Niu · 2026-06-09 00:38:35 +00:00
  e127a0cf99