6947 Commits

• [codex] Forward turn moderation metadata through app-server (#25710)

  ## Why
  First-party backends can supply turn-scoped moderation metadata that
  app-server clients need for client-side presentation. Exposing this as
  an experimental typed notification lets opted-in clients consume it
  without interpreting raw Responses API events.
  
  ## What changed
  - forward `response.metadata.openai_chatgpt_moderation_metadata` from
  Responses API SSE and WebSocket streams as turn-scoped moderation
  metadata
  - emit the experimental app-server v2 `turn/moderationMetadata`
  notification with `{ threadId, turnId, metadata }`
  - add app-server integration coverage for the typed moderation metadata
  notification
  
  ## Testing
  - `just test -p codex-core
  build_ws_client_metadata_includes_window_lineage_and_turn_metadata`
  - `just test -p codex-core` (fails locally: 46 failures and 1 timeout,
  primarily missing `test_stdio_server` and shell snapshot timeouts)
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  turn_moderation_metadata_emits_typed_notification_v2`
  - `just test -p codex-app-server` (fails locally: 792 passed, 10 failed,
  and 5 timed out; failures are in existing environment-sensitive tests,
  primarily because nested macOS `sandbox-exec` is not permitted)
  - `just write-app-server-schema --experimental --schema-root
  /tmp/codex-app-server-schema-experimental`

  carlc-oai · 2026-06-05 02:41:06 -07:00
  55aa071b17
• nit: doc (#26566)

  Matching CBv9

  jif · 2026-06-05 11:10:32 +02:00
  6dc28ba6e0
• Encrypt multi-agent v2 message payloads (#26210)

  ## Why
  
  Multi-agent v2 currently routes agent instructions through normal tool
  arguments and inter-agent context. That means the parent model can emit
  plaintext task text, Codex can persist it in history/rollouts, and the
  recipient can receive it as ordinary assistant-message JSON.
  
  This changes the v2 path so agent instructions stay encrypted between
  model calls: Responses encrypts the `message` argument returned by the
  model, Codex forwards only that ciphertext, and Responses decrypts it
  internally for the recipient model.
  
  ## What changed
  
  - Mark the v2 `message` parameter as encrypted for `spawn_agent`,
  `send_message`, and `followup_task`.
  - Treat multi-agent v2 tool `message` values as ciphertext
  unconditionally.
  - Store v2 inter-agent task text in
  `InterAgentCommunication.encrypted_content` with empty plaintext
  `content`.
  - Convert encrypted inter-agent communications into the Responses
  `agent_message` input item before sending the child request.
  - Preserve `agent_message` items across history, rollout, compaction,
  telemetry, and app-server schema paths.
  - Leave multi-agent v1 unchanged.
  
  ## Message shape
  
  The model still calls the v2 tools with a `message` argument, but that
  value is now ciphertext:
  
  ```json
  {
    "name": "spawn_agent",
    "arguments": {
      "task_name": "worker",
      "message": "<ciphertext>"
    }
  }
  ```
  
  Codex stores the task as encrypted inter-agent communication:
  
  ```json
  {
    "author": "/root",
    "recipient": "/root/worker",
    "content": "",
    "encrypted_content": "<ciphertext>",
    "trigger_turn": true
  }
  ```
  
  When Codex builds the recipient request, it forwards the ciphertext
  using the new Responses input item:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root",
    "recipient": "/root/worker",
    "content": [
      {
        "type": "encrypted_content",
        "encrypted_content": "<ciphertext>"
      }
    ]
  }
  ```
  
  Responses decrypts that item internally for the recipient model.
  
  ## Context impact
  
  - Parent context no longer carries plaintext v2 agent task instructions
  from these tool arguments.
  - Codex rollout/history stores ciphertext for v2 agent instructions.
  - Recipient requests receive an `agent_message` item instead of
  assistant commentary JSON for encrypted task delivery.
  - Plaintext completion/status notifications are still plaintext because
  they are Codex-generated status messages, not encrypted model tool
  arguments.
  
  ## Validation
  
  - `just test -p codex-tools`
  - `just test -p codex-protocol`
  - `just test -p codex-rollout`
  - `just test -p codex-rollout-trace`
  - `just test -p codex-otel`
  - `just write-app-server-schema`

  jif · 2026-06-05 10:25:57 +02:00
  5f4d06ef18
• [codex] Add environment shell info (#26480)

  ## Why
  
  Shell detection needs to be available through the `Environment`
  abstraction so callers can ask the selected local or remote environment
  for shell metadata without adding a separate HTTP endpoint or parallel
  info-source path. This keeps shell metadata shaped like the existing
  environment-owned filesystem capability and lets remote environments
  answer through exec-server JSON-RPC.
  
  ## What changed
  
  - Added `environment/info` to the exec-server protocol/client/server and
  exposed `Environment::info()`.
  - Added local and remote environment info providers on `Environment`,
  following the existing capability-provider pattern used for filesystem
  access.
  - Moved the shared shell detection logic into `codex-shell-command` and
  kept core shell APIs as wrappers around that implementation.
  - Returned shell metadata as `EnvironmentInfo { shell: ShellInfo }`
  using the existing shell detection path.
  - Added a remote environment test that calls `Environment::info()`
  through an exec-server-backed environment.
  
  ## Validation
  
  - `git diff --check`
  - `just test -p codex-shell-command`
  - `just test -p codex-core -E 'test(/shell::tests::/)'`\n- `just test -p
  codex-exec-server environment`

  pakrym-oai · 2026-06-04 22:36:25 -07:00
  6a6a5f925e
• feat(remote-control): allow pairing while disabled (#26215)

  ## Why
  
  `remoteControl/pairing/start` creates authorization for future
  remote-control connections, so it should not require the live websocket
  to already be enabled. Requiring enable first made pairing depend on
  presence instead of the persisted server enrollment that pairing
  actually uses.
  
  Pairing also needs to recover when that persisted server row is stale.
  If `/server/pair` returns `404`, making the first pairing attempt fail
  forces a manual retry even though the client can clear the stale row and
  create a replacement enrollment immediately.
  
  ## What Changed
  
  - Allow `remoteControl/pairing/start` to reuse or create the persisted
  remote-control server enrollment while remote control is disabled.
  - Keep the selected in-memory enrollment across disable and share it
  with websocket connect so a later enable uses the same selected server.
  - Thread the app-server client name through pairing so stdio persistence
  keeps using the websocket-owned enrollment key.
  - Recover pairing server-token auth failures through the existing
  refresh/auth-recovery path.
  - Recover stale pairing enrollment on `/server/pair` `404` by clearing
  the stale selected enrollment, re-enrolling once, and retrying pairing
  once.
  - Add focused disabled-pairing and stale-pairing recovery coverage.
  
  ## Verification
  
  -
  `remote_control_pairing_start_returns_pairing_artifacts_while_disabled`
  exercises pairing before enable.
  - `remote_control_handle_reenrolls_after_stale_pairing_enrollment`
  exercises stale `/server/pair` `404` recovery without a manual retry.
  
  Related: N/A

  Anton Panasenko · 2026-06-05 05:12:23 +00:00
  64e0829cab
• core: derive exec policy filesystem policy from profile (#26499)

  ## Why
  
  `PermissionProfile` already owns the runtime filesystem sandbox policy
  through `file_system_sandbox_policy()`. Keeping a separate
  `FileSystemSandboxPolicy` on exec-policy fallback contexts made it
  possible for callers and tests to construct split states that the
  production permission model should not rely on.
  
  ## What changed
  
  - Removed `file_system_sandbox_policy` from `UnmatchedCommandContext`,
  `ExecApprovalRequest`, and the intercepted Unix exec-policy context.
  - Derived filesystem sandbox policy inside unmatched-command decision
  logic from `PermissionProfile::file_system_sandbox_policy()`.
  - Simplified shell/unified-exec callers and tests that were only
  plumbing the duplicate policy through.
  
  ## Testing
  
  Local tests not run per request; relying on remote CI.

  Michael Bolin · 2026-06-04 21:48:45 -07:00
  a2f5874b7a
• [codex] Keep Bazel startup options stable across commands (#26256)

  ## Why
  
  `just bazel-clippy` ran target discovery with
  `--noexperimental_remote_repo_contents_cache`, then ran the build with
  the workspace default `--experimental_remote_repo_contents_cache`. Bazel
  therefore killed and restarted its server on each transition, slowing
  repeated commands and discarding the in-memory analysis cache. An audit
  found the same class of startup-option variation in several CI command
  sequences.
  
  ## What changed
  
  - Keep local lint target-discovery queries on the workspace-default
  Bazel server, while making CI target discovery explicitly use the CI
  startup options.
  - Normalize GitHub Actions launches through the BuildBuddy wrapper to
  share `BAZEL_OUTPUT_USER_ROOT` and
  `--noexperimental_remote_repo_contents_cache`.
  - Route the CI lockfile check and Windows test-shard query through the
  same startup configuration.
  - Document the startup-option invariant and add wrapper regression
  coverage.
  
  ## Validation
  
  - Confirmed consecutive local clippy target-discovery runs retained the
  same Bazel server PID.

  Adam Perry @ OpenAI · 2026-06-04 20:23:37 -07:00
  1d9c9c9f33
• fix(rmcp): refresh expired OAuth tokens before startup (#26482)

  ## Why
  
  Codex persists OAuth expiry as an absolute `expires_at`, then
  reconstructs RMCP’s relative `expires_in` when credentials are loaded.
  For an already-expired token, Codex reconstructed `expires_in` as
  missing.
  
  [RMCP 0.15 treated a missing `expires_in` as zero when a refresh token
  was
  present](https://github.com/modelcontextprotocol/rust-sdk/blob/9cfc905a9ef17c8bba6748dc0a9bdd2452681733/crates/rmcp/src/transport/auth.rs#L704-L723),
  so this still triggered a refresh. [RMCP 1.7 treats missing expiry
  information as unknown and uses the access token
  as-is](https://github.com/modelcontextprotocol/rust-sdk/blob/3529c3675ff64db805bd947ca6ece6090809e43d/crates/rmcp/src/transport/auth.rs#L1233-L1265),
  causing the stale token to be sent during `initialize`.
  
  ## What changed
  
  - Represent a known-expired persisted token as `expires_in = 0`,
  preserving `None` for genuinely unknown expiry.
  - Add Streamable HTTP coverage requiring the token to refresh before the
  startup handshake.
  
  ## Validation
  
  - The new regression test fails on RMCP 1.7 before the fix and passes
  afterward.
  - The same scenario passes on the commit immediately before the RMCP 1.7
  update, using RMCP 0.15.
  - `just test -p codex-rmcp-client` (63 passed).

  Adam Perry @ OpenAI · 2026-06-05 02:31:06 +00:00
  4de7a2b9d8
• [codex] Add use_responses_lite 'override' logic (#26487)

  ## Summary
  
  - add a defaulted `ModelInfo.use_responses_lite` catalog field
  - support serializing `reasoning.context` while preserving the existing
  effort and summary path
  - has not been turned on for any models yet
  
  I've added an override to parallel tools if responses_lite is on. I've
  also forced persistent reasoning when using responses_lite. It would be
  ideal if we could centralize all the responses_lite plumbing, but I
  think this is best for now to keep the plumbing & diffs small.
  
  ## Testing
  
  - `cargo test -p codex-protocol
  model_info_defaults_availability_nux_to_none_when_omitted`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-core
  responses_lite_sets_all_turns_context_and_disables_parallel_tool_calls`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-core
  configured_reasoning_summary_is_sent`
  - `cargo check -p codex-core --tests`
  - `RUST_MIN_STACK=8388608 cargo clippy -p codex-core --tests` (passes
  with pre-existing warnings in `codex-code-mode` and
  `codex-core-plugins`)

  rka-oai · 2026-06-04 18:49:51 -07:00
  e0096db6dc
• [codex] Emit sandbox outcome telemetry event (#25955)

  ## Summary
  
  Adds a dedicated `codex.sandbox_outcome` telemetry event so we can query
  sandbox edge outcomes without threading sandbox metadata through
  tool-result output types.
  
  This is meant to make sandbox failures and approved escalation retries
  visible in OTEL while keeping the existing `codex.tool_result` event
  shape focused on tool completion data.
  
  ## What changed
  
  - Adds `SessionTelemetry::sandbox_outcome(...)`, which emits
  `codex.sandbox_outcome` as both a log and trace event.
  - Records the tool name, call id, sandbox outcome, initial attempt
  duration, and escalated attempt duration when a retry runs.
  - Emits `denied` when the sandbox blocks execution and no retry is run.
  - Emits `timed_out` and `signal` when those sandbox errors surface from
  tool execution.
  - Emits `escalated` when the initial sandboxed attempt fails and the
  approved unsandboxed retry succeeds.
  - Adds OTEL coverage for the new event payload, including timing fields.
  
  ## Validation
  
  - `RUST_MIN_STACK=8388608 just test -p codex-core
  sandbox_outcome_event_records_outcome
  handle_sandbox_error_user_approves_retry_records_tool_decision`
  - `just test -p codex-otel
  otel_export_routing_policy_routes_tool_result_log_and_trace_events
  runtime_metrics_summary_collects_tool_api_and_streaming_metrics`
  - `just fix -p codex-core`
  - `just fix -p codex-otel`

  rreichel3-oai · 2026-06-04 20:58:14 -04:00
  ecae412740
• ci: test windows cross build (#25000)

  We cross build when using bazel for windows. This causes a couple
  hiccups in that v8 does a mksnapshot step that is expecting to snapshot
  on the host arch which wasn't matching when we were doing the
  crossbuild. This was causing segfault failiures when starting up
  codemode from a cross built artifact.
  
  This changes things such that we cross build the library and then run
  and link a snapshot on the host machine/arch which is windows. This
  gives us a functional snapshot and library that can start code-mode on
  windows.
  
  This fixes the build and then fixes two test regressions we had.

  Channing Conger · 2026-06-04 17:51:13 -07:00
  4be1a168fc
• Pull plugin service less frequently (#26431)

  # Summary
  Reduce download traffic to `github.com/openai/plugins` while continuing
  to check for updates on every Codex startup.
  
  # Root cause
  The startup sync replaced the local repository with a fresh shallow
  clone whenever the remote revision changed. At Codex's global scale,
  repeatedly downloading the repository created excessive GitHub traffic.
  
  # Changes
  - Run `git ls-remote` on each startup to read the remote HEAD SHA.
  - Skip all repository downloads when the local and remote SHAs match.
  - Update existing checkouts with an exact-SHA shallow `git fetch`,
  followed by reset and clean.
  - Bootstrap new installations with `git init` plus the same shallow
  fetch, rather than cloning.
  - Keep the existing file lock so concurrent Codex processes serialize
  updates and do not duplicate fetches.
  - Preserve the existing GitHub HTTP and export archive fallback
  behavior.
  
  # Impact
  Each startup makes one lightweight remote HEAD check. Repository objects
  are downloaded only when the revision changes, and existing Git objects
  are reused during updates.
  
  # Validation
  - `just test -p codex-core-plugins startup_sync` (15 tests passed)
  - `just test -p codex-core-plugins` (201 tests passed)
  - `just clippy -p codex-core-plugins` (passes with one pre-existing
  `large_enum_variant` warning)
  - Production app-server smoke test against GitHub:
    - Fresh home: `ls-remote`, `git init`, one exact-SHA shallow fetch
  - Unchanged restart: `ls-remote` and local `rev-parse` only; no fetch or
  clone
  - Bench smoke passed

  beggers-openai · 2026-06-04 17:47:58 -07:00
  72d0bfb6ba
• Improve Windows sandbox setup refresh diagnostics (#26471)

  ## Why
  
  Users have been seeing opaque Windows sandbox setup refresh failures
  such as `windows sandbox: spawn setup refresh`, including reports in
  #24391 and #21208. The setup refresh path already runs the Windows
  sandbox setup helper, but it was not using the same structured
  `setup_error.json` reporting path that elevated setup uses. As a result,
  when the helper exited non-zero, Codex only surfaced a generic refresh
  status instead of the helper's `SetupFailure` code and message.
  
  ## What changed
  
  - Clear stale `setup_error.json` before non-elevated setup refresh
  launches the helper.
  - When the refresh helper exits non-zero, read the helper-written report
  through the existing `report_helper_failure` path.
  - Keep a parent-side launch diagnostic for cases where the helper never
  starts, including the helper path, cwd, sandbox log path, and spawn
  error.
  - Clear the setup error report after a successful refresh.
  - Add regression coverage for report consumption and stale-report
  avoidance.
  
  ## Verification
  
  - `cargo test -p codex-windows-sandbox setup::tests::`

  iceweasel-oai · 2026-06-04 16:52:10 -07:00
  0b2e7b5eb1
• [codex] Expose unavailable app templates in plugin detail (#26317)

  ## Summary
  - Adds `unavailable_app_templates` to the app-server protocol and
  generated schemas/types.
  - Parses plugin-service `release.unavailable_app_templates` in the
  remote plugin client.
  - Maps remote unavailable templates into app-server `PluginDetail`.
  - Defaults local plugins to an empty unavailable app template list.
  
  ## Validation
  - `just write-app-server-schema`
  - `cargo +1.95.0 fmt --manifest-path codex-rs/Cargo.toml --all --check`
  - `cargo +1.95.0 test --manifest-path codex-rs/Cargo.toml -p
  codex-app-server-protocol schema_fixtures`
  - `cargo +1.95.0 check --manifest-path codex-rs/Cargo.toml -p
  codex-app-server-protocol -p codex-core-plugins -p codex-app-server`
  - `git diff --check`
  
  Note: default `cargo check` uses rustc 1.89 locally and failed because
  dependencies require newer Rust, so validation was rerun with installed
  Rust 1.95.

  charlesgong-openai · 2026-06-04 23:42:27 +00:00
  b9ff450902
• fix(app-server): expose remote MCP servers in plugin read (#26453)

  ## Why
  
  Remote plugin detail responses include MCP server metadata under
  `release.mcp_servers`, but Codex did not deserialize or propagate that
  field. As a result, `plugin/read` always returned an empty `mcpServers`
  list for remote plugins, so the plugin details pane omitted the MCP
  Servers section even when the remote plugin declares one.
  
  This affects uninstalled plugins as well: the remote detail API is the
  source of truth and returns MCP server keys without requiring a local
  plugin bundle.
  
  ## What changed
  
  - Deserialize MCP server entries from remote plugin detail responses.
  - Normalize their keys into a sorted, deduplicated list on
  `RemotePluginDetail`.
  - Return those keys from app-server `plugin/read` instead of hardcoding
  an empty list.
  - Add regression coverage proving an uninstalled remote plugin returns
  its MCP server names.
  
  ## Test plan
  
  - `just test -p codex-core-plugins`
  - `just test -p codex-app-server plugin_read`

  Eric Ning · 2026-06-04 22:10:24 +00:00
  769c231aa1
• [codex] Preserve logical paths during AGENTS.md discovery (#26465)

  ## Intent
  
  Follow up on #26205 by avoiding unnecessary filesystem canonicalization
  during `AGENTS.md` discovery. The configured working directory is
  already absolute, and canonicalization incorrectly switches symlinked
  workspaces from their logical parent hierarchy to the target's
  hierarchy.
  
  ## User-facing behavior
  
  For a symlinked working directory such as:
  
  ```text
  test-root/
  |-- logical-repo/
  |   |-- AGENTS.md              ("logical parent doc")
  |   `-- workspace ------------> physical-repo/workspace/
  `-- physical-repo/
      |-- AGENTS.md              ("physical parent doc")
      `-- workspace/
          `-- AGENTS.md          ("workspace doc")
  ```
  
  Before this change, Codex canonicalized `logical-repo/workspace` to
  `physical-repo/workspace` before discovery. It therefore loaded
  `physical-repo/AGENTS.md` and `physical-repo/workspace/AGENTS.md`,
  ignoring the instructions from the repository through which the user
  entered the workspace.
  
  After this change, ancestor discovery walks the configured logical path,
  so Codex loads `logical-repo/AGENTS.md`. Opening
  `logical-repo/workspace/AGENTS.md` still follows the symlink through the
  host filesystem, so the workspace document is also loaded.
  `physical-repo/AGENTS.md` is not loaded.
  
  ## Implementation
  
  Use the logical absolute working directory when discovering project
  instructions and reporting instruction sources. Filesystem reads still
  follow the working-directory symlink, so an `AGENTS.md` in the target
  workspace continues to load while ancestor discovery uses the symlink's
  parents.
  
  ## Validation
  
  Added integration coverage proving that discovery loads the logical
  parent's instructions and the target workspace's instructions, but not
  the target parent's instructions.

  Adam Perry @ OpenAI · 2026-06-04 15:08:52 -07:00
  59ca34206b
• [codex] Use model-advertised reasoning effort order (#26446)

  ## Summary
  - preserve the model catalog order for app-server
  `supportedReasoningEfforts` and document that client contract
  - render TUI reasoning choices in the advertised order
  - step reasoning shortcuts by adjacent list position instead of deriving
  order from known effort names
  - anchor unsupported configured values to the advertised default, or the
  first option when needed
  - remove canonical effort ordering helpers and the unused upgrade effort
  mapping
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.
  
  Stacked on #26444.

  Ahmed Ibrahim · 2026-06-04 14:01:14 -07:00
  f6e529656f
• [codex] Support model-defined reasoning efforts (#26444)

  ## Summary
  - accept non-empty model-defined reasoning effort values while
  preserving built-in effort behavior
  - propagate the non-Copy effort type through core, app-server, TUI,
  telemetry, and persistence call sites
  - preserve string wire encoding and expose an open-string schema for
  clients
  - update model selection and shortcut behavior for model-advertised
  effort values
  
  ## Root cause
  `ReasoningEffort` gained a string-backed custom variant, so it could no
  longer implement `Copy` or rely on derived closed-enum serialization.
  Existing consumers still moved effort values from shared references and
  assumed a fixed built-in value set.
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.

  Ahmed Ibrahim · 2026-06-04 13:36:24 -07:00
  8ac304c299
• Cleanup experimentalFeature/enablement/set (#26312)

  ## Why
  
  `experimentalFeature/enablement/set` still allowed several keys that no
  longer need to be managed through this API. Keeping those keys also
  preserved corresponding special-case logic, including refreshing the
  apps list when the `apps` key was enabled.
  
  The endpoint also rejected an entire request when any key was invalid or
  unsupported. That makes clients brittle when they send a mix of current
  and stale keys, even when the valid entries can still be applied safely.
  
  ## What changed
  
  - remove the feature keys that no longer need to be supported by
  `experimentalFeature/enablement/set`
  - remove the corresponding apps-list refresh path and its auth/config
  plumbing
  - ignore and warn on invalid or unsupported keys while still applying
  valid keys from the same request
  - update the app-server documentation and integration coverage for the
  reduced key set and partial-acceptance behavior
  
  ## Test plan
  
  - `just test -p codex-app-server experimental_feature_enablement_set` (6
  passed)
  - `just test -p codex-app-server` exercised the changed tests
  successfully; unrelated sandbox-dependent and watcher/timing tests
  failed locally

  Matthew Zeng · 2026-06-04 13:35:31 -07:00
  4a70e0ac1b
• Remove response.processed websocket request (#26447)

  ## Why
  
  The Responses websocket client no longer needs to send a follow-up
  `response.processed` request after a turn response has already been
  recorded. Keeping that extra acknowledgement path adds feature-gated
  control flow and a second websocket request shape that no longer carries
  useful behavior.
  
  ## What Changed
  
  - Removed the `response.processed` websocket request type and sender.
  - Removed the `responses_websocket_response_processed` feature flag and
  schema entry.
  - Removed turn and remote-compaction plumbing that only tracked response
  IDs to send the acknowledgement.
  - Removed tests that existed solely to cover the deleted feature path.
  
  ## Validation
  
  - `just fix -p codex-core -p codex-api -p codex-features`

  pakrym-oai · 2026-06-04 13:15:50 -07:00
  d312a53e2a
• build: use ThinLTO for release binaries (#23710)

  ## Why
  
  Fat LTO makes release builds substantially slower without providing
  enough measured runtime benefit to justify the release CI long pole. The
  build-profile investigation found that keeping Cargo's default release
  `opt-level=3` and switching from fat LTO to ThinLTO (`3/thin/1`) reduced
  a clean `codex-cli` release build from 2073.893 seconds to 1243.172
  seconds, a 40.06% improvement.
  
  The resulting binary increased from 196.7 MiB to 211.8 MiB (+7.63%).
  Measured runtime changes were small: the worst image workload median was
  +0.86% and app-server startup was +0.31% relative to fat LTO. ThinLTO
  retains cross-crate optimization while avoiding most of the fat-LTO
  build cost.
  
  This deliberately avoids global size optimization: final-executable
  testing showed a substantial regression on the image request path, which
  is expected to become more important as image usage grows.
  
  ## What changed
  
  - Set the workspace release profile to `lto = "thin"`, retaining Cargo's
  default release `opt-level=3`.
  - Remove release and CI workflow-specific LTO overrides so
  release-profile builds consistently use the workspace setting.
  - Remove the now-unused Windows release workflow input and related
  diagnostic output.
  
  ## Validation
  
  - Confirmed the release profile parses with `cargo metadata --no-deps
  --format-version 1`.
  - CI validates release builds across the supported target matrix.

  Adam Perry @ OpenAI · 2026-06-04 20:07:53 +00:00
  f97d5c3275
• [codex] Fix Windows sandbox build script lint (#26445)

  ## Why
  
  The Windows ARM64 Cargo clippy job on `main` is failing because
  workspace lints deny `clippy::expect_used`, and the
  `codex-windows-sandbox` build script used `expect()` while reading
  `CARGO_MANIFEST_DIR`.
  
  ## What changed
  
  `codex-rs/windows-sandbox-rs/build.rs` now returns `Result<(), String>`
  from `main()` and converts a missing `CARGO_MANIFEST_DIR` into an
  explicit build-script error. The non-Windows early return and Windows
  linker argument behavior are unchanged.
  
  ## Verification
  
  - `just clippy -p codex-windows-sandbox -- -D warnings`
  - `just test -p codex-windows-sandbox`

  pakrym-oai · 2026-06-04 13:03:47 -07:00
  555f8caeff
• Route AGENTS.md loading through environment filesystems (#26205)

  ## Why
  
  Workspace-specific `AGENTS.md` loading needs to use the selected
  environment filesystem so remote workspaces and child agents read
  instructions from their actual environment instead of the host
  filesystem. The app-server should report the same instruction sources
  the initialized thread actually loaded, rather than independently
  rescanning configuration and filesystem state.
  
  ## What changed
  
  - Introduce `LoadedAgentsMd` to retain ordered user, project, and
  internal instructions with their provenance.
  - Load and canonicalize workspace `AGENTS.md` paths through the primary
  `EnvironmentManager` environment, then render the loaded instructions
  when constructing turn context.
  - Expose cached loaded instruction sources from initialized threads and
  use them for app-server start, resume, and fork responses.
  - Preserve global `CODEX_HOME` loading and separator behavior while
  excluding empty project files that did not supply model-visible
  instructions.
  - Add integration coverage for CLI injection, selected-environment
  provenance and rendering, empty environment selection, and cached
  sources on loaded-thread resume.
  
  ## Validation
  
  - `just test -p codex-core agents_md`
  - `just test -p codex-core
  selected_environment_sources_match_model_visible_instructions`
  - `just test -p codex-exec agents_md`
  - `just test -p codex-app-server instruction_sources`
  - `just test -p codex-app-server --status-level fail`

  Adam Perry @ OpenAI · 2026-06-04 12:43:07 -07:00
  e64b469bbc
• 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
• [codex-analytics] emit forked thread id on initialization (#26248)

  ## Why
  - Thread initialization analytics do not identify the source thread for
  forked threads.
  - The session viewer needs this lineage to construct thread trees.
  - Depends on openai/openai#987854. Do not release this change before
  that backend schema change is deployed.
  
  ## What Changed
  - Adds optional `forked_from_thread_id` to `codex_thread_initialized`.
  - Populates it from the existing thread fork lineage for app-server and
  in-process subagent initialization paths.
  - Keeps it null for non-forked threads.
  
  ## Verification
  - `just fmt`
  - `just test -p codex-analytics`
  - `just test -p codex-app-server
  thread_fork_tracks_thread_initialized_analytics`

  kbazzi · 2026-06-04 11:24:12 -07:00
  9e41f8ddbe
• external-agent-migration: avoid mixed MCP transport configs (#26435)

  ## Why
  
  MCP migration could recursively merge an imported server into an
  existing same-named Codex server. When one definition used stdio and the
  other used HTTP, this produced an invalid mixed configuration containing
  both `command` and `url`.
  
  ## What changed
  
  - Merge MCP configuration at the server level instead of field by field.
  - Preserve an existing same-named Codex MCP server unchanged.
  - Report only MCP servers that would actually be added during detection.
  - Add regression coverage for mixed command/HTTP source configurations.
  - Use neutral fixture names and reserved `example.com` URLs.
  
  ## Test plan
  
  - `just test -p codex-app-server repo_mcp`
    - 5 tests passed.
  - `just test -p codex-external-agent-migration
  mcp_migration_prefers_command_transport_for_mixed_server_config`
    - 1 test passed.

  stefanstokic-oai · 2026-06-04 14:16:03 -04:00
  c8fdc74b42
• app-server: support -c config overrides (#26436)

  ## Why
  
  The standalone `codex-app-server` binary already routed a
  `CliConfigOverrides` value into app-server startup, but its own clap
  args did not expose the shared `-c/--config` option. That meant
  `codex-app-server -c key=value` was rejected before the existing config
  override path could run, unlike the main `codex` CLI.
  
  ## What Changed
  
  - Flatten `CliConfigOverrides` into `AppServerArgs` in
  `codex-rs/app-server/src/main.rs`.
  - Pass parsed overrides to `run_main_with_transport_options` instead of
  always using `CliConfigOverrides::default()`.
  - Add a binary parser test covering both `-c` and `--config` for the
  standalone app-server.
  
  ## Verification
  
  - `just test -p codex-app-server
  app_server_accepts_cli_config_overrides`
  
  The broader `just test -p codex-app-server` run was also attempted. It
  compiled and ran 812 tests, with 796 passing, but failed in this local
  sandbox on unrelated `sandbox-exec: sandbox_apply: Operation not
  permitted` command-exec/turn integration paths and a skills watcher
  timeout.

  Michael Bolin · 2026-06-04 18:05:54 +00:00
  881cf191d7
• Expose configured marketplace source in plugin list JSON (#26417)

  ## Summary
  - Follow-up to #25330
  - Add `marketplaceSource` to `codex plugin list --json` entries for
  configured marketplaces
  - Keep the existing per-plugin `source` field unchanged; this still
  reports the local plugin source path
  - Include only the configured marketplace `sourceType` and `source` from
  `config.toml`
  - Keep human-readable output unchanged
  - Add CLI coverage for configured local and git marketplace sources
  
  Example:
  
  ```json
  {
    "source": {
      "source": "local",
      "path": "/path/to/.codex/.tmp/marketplaces/debug/plugins/sample"
    },
    "marketplaceSource": {
      "sourceType": "git",
      "source": "https://example.com/acme/agent-skills.git"
    }
  }
  ```
  
  ## Validation
  - `just fmt`
  - `just fix -p codex-cli`
  - `just test -p codex-cli plugin_list`

  mpc-oai · 2026-06-04 12:20:32 -05:00
  cdc1d592df
• Bound external agent session detection work (#26291)

  ## Why
  
  External agent migration detection parsed and hashed every JSONL session
  file. For users with many large conversations, launching migration could
  consume substantial CPU and disk resources.
  
  Detection only needs the most recent sessions for the migration UI, so
  full-content work should be bounded.
  
  ## What
  
  - Use file modification metadata to select the 50 most recent eligible
  sessions before parsing JSONL content.
  - Skip unchanged imported sessions using metadata stored in the import
  ledger.
  - Preserve content hashing when metadata indicates a session may have
  changed.
  - Stream SHA-256 calculation through a 64 KiB buffer instead of loading
  an entire session into memory.
  - Continue detecting older sessions in subsequent batches after newer
  sessions are imported.
  
  ## Validation
  
  - `RUST_MIN_STACK=8388608 cargo nextest run --no-fail-fast -p
  codex-external-agent-sessions`
    - 20 tests passed.
  - Benchmarked release builds against 250 valid JSONL sessions totaling
  501 MiB:
    - Median detection time decreased from 1,138.8 ms to 47.0 ms.
    - CPU instructions decreased by 95.8%.
    - Both versions returned the expected 50 sessions.
  
  The benchmark used warm filesystem caches and measured the reduction in
  parsing, hashing, and CPU work.

  stefanstokic-oai · 2026-06-04 13:13:05 -04:00
  cbf62f64cb
• Add saved image path hint to standalone image generation (#25947)

  ## Why
  
  Standalone image generation returns image bytes to the model, but the
  model also needs the host artifact path to reference the generated file
  in follow-up work.
  
  ## What changed
  
  - Append the default saved-image path hint alongside the generated image
  tool output.
  - Reuse the existing core image-generation hint text.
  - Pass the thread ID and Codex home directory needed to compute the
  artifact path.
  - Add app-server and extension coverage for the model-visible hint.
  
  ## Validation
  
  - `just fmt`
  - `just bazel-lock-check`
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`

  Won Park · 2026-06-04 09:39:20 -07:00
  12e8764a9c
• Simplify Codex CLI README (#26313)

  ## Summary
  
  The codex-rs README was left over from before we moved the docs into the
  developer site. Its contents were very much out of date, and we received
  some bug reports about it.

  Eric Traut · 2026-06-04 09:16:03 -07:00
  68db0bb5ec
• Load plugin hooks without other plugin capabilities (#26272)

  ## Summary
  
  `hooks/list` only consumes plugin hook declarations, but previously
  loaded every enabled plugin's skills, MCP configuration, apps, and
  capability summary before discarding them.
  
  In a local benchmark, this reduced `hooks/list` latency by over 100ms
  (e.g., from 594 to 467ms on startup, and 168 to 16ms when making a
  `hooks/list` call later in the same TUI session). This is on the
  critical path to rendering the TUI, so every 10s of ms should be eyed
  skeptically (IMO).
  
  This change adds a hook-specific plugin loading path that preserves
  plugin enablement, remote/local conflict resolution, deterministic
  ordering, manifest resolution, and hook-loading warnings while skipping
  unrelated capabilities. (I think there's room for a more general design
  here that allows you to project the capabilities you need at load-time,
  but that seems unnecessary right now.)

  Charlie Marsh · 2026-06-04 11:21:40 -04:00
  4ae7930f58
• Reduce SQLite contention from OpenTelemetry SDK debug logs (#26396)

  ## Summary
  
  - skip `opentelemetry_sdk` DEBUG and TRACE events before formatting or
  queueing them for the SQLite log sink
  - preserve INFO, WARN, and ERROR events from the SDK, along with TRACE
  events from application targets
  - add a persistence-level regression test for the target and level
  policy
  
  ## Why
  
  OpenTelemetry's batch log processor emits internal
  `BatchLogProcessor.ExportingDueToTimer` meta-events every second per
  Codex process. In measured high-fanout `logs_2.sqlite` databases,
  low-level `opentelemetry_sdk` events accounted for over 30% of retained
  rows (30-60% on the machines of people I asked to check).
  
  Persisting this SDK bookkeeping across many processes adds substantial
  write volume and contention without representing application activity.
  
  ## Validation
  
  - `just test -p codex-state` (132/132 tests passed, plus bench smoke)
  - `just fix -p codex-state`
  - `just fmt`

  Zanie Blue · 2026-06-04 10:12:08 -05:00
  d81fcdf8ef
• Optimize unbounded byte scans with memchr (#26265)

  ## Summary
  
  This PR adds `memchr` for some low-hanging performance improvements
  (namely, in MCP stdio, Ollama streaming, and full message-history
  newline counts).
  
  Codex produced the following release benchmarks:
  
  | Operation | Before | After | Speedup |
  | --- | ---: | ---: | ---: |
  | MCP 1 MiB chunked line | 2.172 s | 3.984 ms | 545x |
  | Ollama 1 MiB chunked line | 1.673 s | 2.790 ms | 600x |
  | Count newlines in 10 MiB history | 132.83 ms | 20.05 ms | 6.6x |
  
  With a "real" MCP setup (`ExecutorStdioServerLauncher` started a Python
  MCP server, completed `initialize`, requested `tools/list`, and
  deserialized a 1 MiB tool description over newline-delimited stdio),
  it's about 16x faster end-to-end:
  
  | Branch | 50 calls | Per call |
  | --- | ---: | ---: |
  | `main` | 862.53 ms | 17.25 ms |
  | this branch | 53.89 ms | 1.08 ms |
  
  `memchr` is already in our dependency tree and extremely widely used for
  this kind of optimized scanning.

  Charlie Marsh · 2026-06-04 09:53:08 -04:00
  7da4af622f
• Bridge host-loaded skills into the skills extension (#26172)

  ## Why
  
  The skills extension needs to become the path that exposes local host
  skills without losing the behavior already owned by core skill loading.
  Host skill discovery is not just `$CODEX_HOME/skills`: it also includes
  config layers, bundled-skill settings, plugin roots, runtime extra
  roots, and the filesystem for the selected primary environment.
  
  Rather than making the extension reload host skills and risk drifting
  from that authoritative load, this PR bridges the already-loaded
  per-turn skills outcome into the extension. That lets the extension
  advertise host skills and inject explicit `$skill` prompts while
  preserving the same roots, disabled/hidden state, rendered paths, and
  environment-backed file reads that the legacy path uses.
  
  ## What Changed
  
  - Adds `HostLoadedSkills` in `core-skills` to wrap the turn's
  `SkillLoadOutcome` and read `SKILL.md` through the filesystem that
  loaded that skill.
  - Stores `HostLoadedSkills` in turn extension data for normal turns and
  review turns, so the skills extension can consume the loaded host
  catalog without reloading it.
  - Adds `HostSkillProvider` under `ext/skills/src/provider/host.rs`,
  mapping host-loaded skill metadata into the skills-extension
  catalog/read contract.
  - Registers the host provider by default from
  `codex_skills_extension::install()`.
  - Preserves host skill metadata such as dependencies, disabled state,
  hidden-from-prompt policy, and slash-normalized display paths.
  - Passes host-loaded skills through `SkillListQuery` and
  `SkillReadRequest` so explicit skill invocation reads only resources
  from the loaded host catalog.
  - Adds integration coverage for a real legacy
  `$CODEX_HOME/skills/.../SKILL.md` skill being listed and injected
  through the installed extension.
  
  ## Testing
  
  - Added `installed_extension_loads_host_skills_from_legacy_roots` in
  `ext/skills/tests/skills_extension.rs`.
  - `just test -p codex-skills-extension`

  jif · 2026-06-04 15:28:06 +02:00
  d46a98d31a
• Gate automatic idle turns in Plan mode (#26147)

  ## Why
  
  Goal idle continuation is extension-triggered model-visible work, so it
  should follow one core-owned rule for when automatic work may start. In
  particular, it should not jump ahead of queued user/client work, start
  while another task is active, or inject a continuation turn while the
  thread is in Plan mode.
  
  Keeping this policy in `try_start_turn_if_idle` avoids passing
  `collaboration_mode` or review-specific state through
  `ThreadLifecycleContributor::on_thread_idle`. Active `/review` is
  covered by the same active-task gate because Review turns are not
  steerable.
  
  ## What Changed
  
  - Teach `Session::try_start_turn_if_idle` to reject automatic idle turns
  in Plan mode, both before reserving an idle turn and after building the
  turn context.
  - Document `CodexThread::try_start_turn_if_idle` as the extension-facing
  gate for automatic idle work, including Plan-mode and active Review-task
  behavior.
  - Add focused coverage for Plan-mode rejection and active Review-task
  rejection without queuing synthetic input.
  
  ## Testing
  
  - `just test -p codex-core try_start_turn_if_idle`

  jif · 2026-06-04 14:44:45 +02:00
  d297616d3e
• chore: calm down (#26367)

  Prompt update to address feedback

  jif · 2026-06-04 12:46:02 +02:00
  16d02ec77c
• [codex-analytics] report compaction request token counts (#25946)

  ## Why
  
  Compaction analytics need token counts that better represent the request
  being compacted. The existing session snapshot can diverge from the
  actual remote compaction request after output rewriting, and remote v2
  can use server-side Responses usage when available.
  
  ## What changed
  
  - Add an optional `active_context_tokens_before` override to
  `CompactionAnalyticsAttempt::track(...)` for remote compaction when it
  has a better before-token value than the begin-time session snapshot.
  The local `/compact` path passes no override.
  - For remote v1 `responses_compact`, subtract the estimated token delta
  from pre-compaction output rewriting from the session snapshot, capped
  by locally-added tokens since the last successful API response.
  - For remote v2 `responses_compaction_v2`, use the same bounded
  output-rewrite fallback as remote v1, then overwrite
  `active_context_tokens_before` with server `token_usage.input_tokens`
  from the `response.completed` event when present.
  - Keep the existing v2 compaction-output validation while carrying the
  completed response token usage through `collect_compaction_output`.
  
  ## Verification
  
  - `just fmt`
  - `just test -p codex-core
  collect_compaction_output_accepts_additional_output_items`
  - `git diff --check`

  rhan-oai · 2026-06-04 03:00:44 +00:00
  c143a86de8
• cli: add package path from install context (#26189)

  ## Why
  
  Codex package installs include helper binaries in `codex-path`, such as
  the bundled `rg`. Package-layout launches should add that directory
  before user commands run, but standalone launches were missing it while
  npm launches only worked because `codex.js` had its own legacy `PATH`
  rewrite. That made npm and standalone package behavior diverge.
  
  Shell snapshot restoration can also reset `PATH` after runtime setup.
  Any package-owned `PATH` prepend has to be recorded as an explicit
  runtime override so shells, unified exec, and user-shell commands keep
  access to `codex-path` after a snapshot is sourced.
  
  ## Repro
  
  Before this change, a curl-installed package could contain `rg` under
  `codex-path` but still fail to put it on `PATH`:
  
  ```shell
  mkdir /tmp/test-codex-curl
  curl -fsSL https://chatgpt.com/codex/install.sh \
    | CODEX_HOME=/tmp/test-codex-curl CODEX_NON_INTERACTIVE=1 sh
  /tmp/test-codex-curl/packages/standalone/current/bin/codex exec \
    --skip-git-repo-check 'print `which -a rg`'
  find /tmp/test-codex-curl -name rg
  ```
  
  The `which -a rg` output omitted the packaged helper even though `find`
  showed it under
  `/tmp/test-codex-curl/packages/standalone/releases/.../codex-path/rg`.
  
  The npm install path behaved differently only because
  `codex-cli/bin/codex.js` had legacy `PATH` rewriting:
  
  ```shell
  mkdir /tmp/test-codex-npm
  cd /tmp/test-codex-npm
  npm install @openai/codex
  ./node_modules/.bin/codex exec --skip-git-repo-check 'print `which -a rg`'
  ```
  
  That printed the npm package's `vendor/<target>/codex-path/rg` first.
  This PR moves that behavior into Rust-side package launch setup so
  curl/standalone and npm/bun launches agree without JS rewriting `PATH`.
  
  ## What Changed
  
  - `codex-rs/arg0` now uses
  `InstallContext::current().package_layout.path_dir` to prepend the
  package helper directory before any threads are created.
  - Package helper `PATH` setup is independent from the temporary arg0
  alias setup, so `codex-path` is still added even if CODEX_HOME tempdir,
  lock, or symlink setup fails.
  - `codex-rs/install-context` detects the canonical package layout we
  ship: `bin/`, `codex-resources/`, and `codex-path/` next to
  `codex-package.json`.
  - Shell, local unified exec, and user-shell runtimes now record package
  `codex-path` prepends in `explicit_env_overrides`, matching the existing
  zsh-fork behavior so shell snapshots cannot restore over the package
  helper path.
  - Remote unified exec requests do not receive the local app-server
  package path overlay.
  - `codex-cli/bin/codex.js` no longer computes or overrides `PATH`; it
  only locates the native binary in the canonical package layout and
  passes npm/bun management metadata.
  - Added regression tests for `PATH` ordering, package layout detection,
  and shell snapshot preservation of package path prepends.
  
  ## Verification
  
  - `node --check codex-cli/bin/codex.js`
  - `just test -p codex-install-context -p codex-arg0`
  - `just test -p codex-core
  user_shell_snapshot_preserves_package_path_prepend`
  - `just test -p codex-core tools::runtimes::tests`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-install-context -p codex-arg0 -p codex-core`

  Michael Bolin · 2026-06-03 19:08:19 -07:00
  6bcccb0ee6
• feat(tui): add /app desktop handoff (#25638)
  Felipe Coury · 2026-06-03 20:30:15 -03:00
  80b65e9945
• fix(tui): add reasoning effort fallback shortcuts (#25623)
  Felipe Coury · 2026-06-03 20:28:31 -03:00
  8285cd278b
• log plugin MCP server names (#26002)

  ## Summary
  - emit the plugin capability summary's exact MCP server names in
  `codex_plugin_used`
  
  ## Test
  - `just test -p codex-analytics`
  - `just test -p codex-core
  explicit_plugin_mentions_track_plugin_used_analytics`
  - `just fix -p codex-analytics`

  Chris Dong · 2026-06-03 16:06:52 -07:00
  4d4837c495
• Use Windows setup marker as completion signal (#26074)

  # Why
  
  When an organization requires the elevated Windows sandbox, Codex
  launches an elevated helper to provision users, configure firewall and
  ACL rules, and lock persistent sandbox directories.
  
  We observed that closing the helper after setup started could leave the
  machine partially initialized while the TUI still announced **Sandbox
  ready**. Model-only turns continued to work, but the first shell command
  retried setup and failed with Windows cancellation error `1223`.
  
  This was not an enforcement bypass; command execution continued to fail
  closed. The issue was a false readiness signal: `setup_marker.json` was
  written during user provisioning, before the remaining setup stages had
  completed.
  
  # What
  
  Treat `setup_marker.json` as the commit record for Windows sandbox
  setup:
  
  1. Before full or provisioning setup begins, remove the existing marker
  and create the final marker path with a protected ACL.
  2. Keep the marker empty and therefore invalid while setup is in
  progress. Sandbox users cannot read, modify, or replace it.
  3. Run every synchronous setup stage.
  4. After setup succeeds, write the valid marker contents without
  changing its ACL.
  5. After the helper exits successfully, verify the existing readiness
  check before enabling the sandbox.
  
  If setup is canceled or fails, the marker remains invalid and Codex
  reports setup as incomplete instead of announcing readiness.
  
  Refresh-only and read-ACL-only helper runs continue to leave the marker
  untouched. The setup version remains `5` to avoid forcing all existing
  Windows users through elevated setup again.
  
  # Verification
  
  - Added coverage confirming sandbox users cannot read or modify the
  setup marker after elevated setup.
  - Added coverage confirming a successful helper exit without complete
  setup artifacts is rejected.
  - Ran `just test -p codex-windows-sandbox`.

  Abhinav · 2026-06-03 15:33:34 -07:00
  0ed2735d19
• Rewrite oversized tool outputs during remote compaction (#26251)

  ## Why
  
  When trying to fit history under compaction limit rewrite output items
  instead of removing them entirely. Otherwise we're breaking
  incrementality in relation to the previous response.

  pakrym-oai · 2026-06-03 15:25:50 -07:00
  4231472c03
• feat: catalog multi-agent v2 config (#26254)

  ## Why
  
  Model metadata can now select multi-agent v2 even when a user has not
  enabled `features.multi_agent_v2` in their config. Some existing configs
  still set the legacy `agents.max_threads` knob for v1 multi-agent
  behavior, so treating every v2 runtime as incompatible with
  `agents.max_threads` would break users whose only v2 signal came from
  the model catalog.
  
  The incompatible configuration is specifically enabling
  `features.multi_agent_v2` while also setting `agents.max_threads`.
  Catalog-forced v2 should use the v2 concurrency setting and ignore the
  legacy v1 cap instead of rejecting the config.
  
  ## What changed
  
  - Split config validation from runtime concurrency calculation:
  `effective_agent_max_threads` now just returns the effective cap for the
  resolved multi-agent runtime.
  - Added explicit validation for `features.multi_agent_v2` +
  `agents.max_threads` at session startup.
  - Preserved catalog-selected v2 behavior when `features.multi_agent_v2`
  is disabled, so existing configs with `agents.max_threads` keep
  starting.
  - Updated model-runtime selector coverage so a catalog v2 model still
  exposes v2 tools even when `agents.max_threads` is set and the config
  flag is disabled.
  
  ## Validation
  
  - `cargo check -p codex-core --lib`
  - `just test -p codex-core --lib -E
  "test(multi_agent_v2_feature_rejects_agents_max_threads) |
  test(catalog_v2_allows_agents_max_threads_when_feature_disabled)"`

  jif · 2026-06-04 00:24:40 +02:00
  11bceb8f8b
• Restore Windows coverage for code-mode image generation exposure (#25960)

  ## Summary
  
  Restore Windows coverage for standalone image generation in code mode.
  
  The previous test executed a V8-backed code-mode cell on Windows CI,
  where that runtime path is intentionally excluded because it is
  unreliable. The test was then ignored entirely on Windows, removing
  useful coverage.
  
  This splits the test into two checks:
  
  - All platforms verify that `image_gen__imagegen` is exposed to the
  model when image generation is configured for code mode only.
  - Non-Windows platforms continue to execute the full V8-backed flow and
  verify that the nested image-generation call succeeds.
  
  ## Verification
  
  - `just fmt`
  - `git diff --check`
  - `just test -p codex-app-server standalone_image_generation`
  
  Result: 3 tests passed, plus the required bench smoke check.

  Won Park · 2026-06-03 14:02:55 -07:00
  0eb7e6d79b
• Fix forked thread name inheritance (#26075)

  Fixes #25950.
  
  ## Why
  Forking a renamed thread could fall back to the source thread's
  first-prompt title because the fork path did not preserve the source's
  explicit name. That meant fork-of-renamed-fork flows could show stale
  sidebar labels even though the user had renamed the parent.
  
  ## What changed
  `thread/fork` now reads the source thread's distinct `name`, normalizes
  it, persists it onto materialized forks, and applies it to the returned
  API thread. Because the source `name` already excludes first-prompt
  pseudo-titles, forks inherit only an explicit user rename instead of
  stale generated metadata.

  Eric Traut · 2026-06-03 12:56:54 -07:00
  d8121f93c8
• [profile-switcher][rust] -- [1/2] Add app-server account session protocol (#25469)

  ## Summary
  
  Adds the app-server v2 `accountSession/*` protocol used by the Desktop
  profile switcher and the backend account metadata client needed to
  populate workspace choices.
  
  This is the protocol layer only. The app-server lifecycle and
  consolidated saved-session storage are split into a follow-up PR.
  
  ## Rust Stack
  
  1. This PR
  2. [openai/codex#25383](https://github.com/openai/codex/pull/25383) adds
  app-server session lifecycle behavior and consolidated saved-session
  storage.
  
  ## Validation
  
  - Generated app-server schema fixtures are included from the existing
  generation flow in the lifecycle PR where the routes are registered.
  - Did not run tests per requested scope.

  dhruvgupta-oai · 2026-06-04 01:25:11 +05:30
  a2ebe07b39
• Expose local image paths to models (#25944)

  ## Why
  
  Local image attachments include image bytes, but the adjacent
  model-visible label omits the source path. Exposing the path lets
  model-selected workflows refer back to the intended local image
  explicitly.
  
  ## What changed
  
  - Include an escaped `path` attribute in model-visible local image
  opening tags.
  - Reuse the path-aware marker generator in rollout coverage.
  - Update protocol, replay, and rollout coverage for the new request
  shape.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-protocol`
  - `just test -p codex-core skips_local_image_label_text`
  - `just test -p codex-core
  copy_paste_local_image_persists_rollout_request_shape`
  - `git diff --check`

  Won Park · 2026-06-03 19:49:58 +00:00
  57ab4c89e0
• Preserve remote plugin default prompts (#25887)

  ## Summary
  
  - Read `default_prompts` from remote plugin release metadata.
  - Prefer the plural prompt list over legacy `default_prompt`.
  - Fall back to `default_prompt` as a single-item list for backward
  compatibility.
  
  ## Testing
  
  - `just test -p codex-core-plugins`
  - `just test -p codex-app-server`

  Eric Ning · 2026-06-03 12:39:13 -07:00
  aeac226d16