7508 Commits

This Branch

This Branch

All Branches

• Use ApiPathString in app-server filesystem permission paths (#28367)

  ## Why
  
  Clients running an app-server on one OS and an exec-server on another OS
  need to be able to pass sandbox config to app-server that refers to
  resources on the executor's foreign OS.
  
  ## What
  
  `AbsolutePathBuf` can't represent these paths and we don't want users to
  be exposed to `PathUri` yet, so this moves the public app-server API to
  be expressed in terms of `ApiPathString`.
  
  Stacked on #28165.
  
  - change app-server v2 filesystem permission paths, including legacy
  read/write roots, to `ApiPathString`
  - localize API paths through `PathUri` when converting into the current
  native core permission types
  - make path-bearing permission conversions fallible and surface
  localization failures instead of silently treating malformed grants as
  ordinary denials
  - propagate conversion failures through app-server and TUI approval
  handling
  - regenerate the app-server JSON and TypeScript schemas
  - leave migration TODOs on native-path conversions so they can be
  removed once core permission paths use `PathUri`

  Adam Perry @ OpenAI · 2026-06-15 19:25:54 -07:00
  ecfe174d5f
• [codex] Make plugin details capability aware (#27958)

  ## Summary
  
  Makes plugin details/read flows capability-aware so auth-filtered plugin
  surfaces report the same usable app/MCP/skill shape as the marketplace
  and install flows.
  
  ## Validation
  
  Not run; this change was rebased onto the current plugin auth stack and
  pushed as a draft PR.
  
  **Manual test**
  1. set up a local marketplace with a plugin that has both app and mcp
  declarations
  
  ```
  // .app.json
  {
    "apps": {
      "linear": {
        "id": "some_id"
      }
    }
  }
  
  ```
  
  ```
  // .mcp.json
  {
    "mcpServers": {
      "linear": {
        "type": "http",
        "url": "https://mcp.linear.app/mcp",
        "oauth_resource": "https://mcp.linear.app/mcp"
      },
      "linear2": {
        "type": "http",
        "url": "https://mcp.linear2.app/mcp",
        "oauth_resource": "https://mcp.linear2.app/mcp"
      }
    }
  }
  ```
  
  2a. **login in with api key** and observe plugin details page which
  shows no apps (note we don't show "app not available due to api key log
  in as there's no way to differentiate between no apps and app without
  substitute mcp exists" without significantly more code changes, i've
  separated this to a follow up if we want that behaviour.
  <img width="1170" height="279" alt="Screenshot 2026-06-15 at 23 45 40"
  src="https://github.com/user-attachments/assets/d36cb160-fbec-461e-9643-9c761dbae7bb"
  />
  <img width="975" height="640" alt="Screenshot 2026-06-15 at 18 40 30"
  src="https://github.com/user-attachments/assets/90ec0bc8-7506-4b90-bbd3-070720de799e"
  />
  
  
  2b. **log in with chat** and observe intended conflict resolution logic
  <img width="1165" height="224" alt="Screenshot 2026-06-15 at 17 17 30"
  src="https://github.com/user-attachments/assets/80adfbf2-7dac-4f08-8b76-8eeeab6c95e7"
  />
  <img width="968" height="567" alt="Screenshot 2026-06-15 at 18 38 59"
  src="https://github.com/user-attachments/assets/9ea92c5e-535b-4aa4-8ad0-ee513b57bc3c"
  />

  felixxia-oai · 2026-06-16 01:25:22 +00:00
  d959664420
• [codex] Load API curated marketplace by auth (#28383)

  ## Summary
  - choose the local OpenAI curated marketplace manifest based on auth:
  Codex backend auth gets the existing marketplace, direct provider auth
  gets `api_marketplace.json`
  - include Bedrock API key auth in the direct-provider API marketplace
  path
  - safely skip the API marketplace when `api_marketplace.json` is absent
  
  ## Validation
  - `just fmt`
  - `git diff --check origin/main...HEAD`
  - CI should run the full validation
  
  ## Manual Testing
  
  ### - New api marketplace not available for API key sign
  1. Safely not display anything from api marketplace
  <img width="1161" height="289" alt="Screenshot 2026-06-15 at 21 37 43"
  src="https://github.com/user-attachments/assets/a5f16642-8a20-4ac1-a0de-1274a4c7b5b2"
  />
  
  ### - New api marketplace for API key sign in
  1. Setup api_marketplace.json
  ```
  {
    "name": "openai-curated",
    "interface": {
      "displayName": "Codex official"
    },
    "plugins": [
      {
        "name": "linear",
        "source": {
          "source": "local",
          "path": "./plugins/linear"
        },
        "policy": {
          "installation": "AVAILABLE",
          "authentication": "ON_INSTALL"
        },
        "category": "Productivity"
      }
    ]
  }
  ```
  
  2. Log in with API key, observe that only the defined plugin from
  api_marketplace.json is available from "Codex Official" (outside of
  local testing marketplaces)
  <img width="1167" height="446" alt="Screenshot 2026-06-15 at 21 16 53"
  src="https://github.com/user-attachments/assets/7cf61477-d826-4ef6-bc05-0a23ac1c0259"
  />
  
  also checked functionality on codex app
  
  ### - SiWC users 
  Still uses 'default' marketplace.json and renders all plugins
  <img width="1171" height="502" alt="Screenshot 2026-06-15 at 21 40 25"
  src="https://github.com/user-attachments/assets/d212ea9b-0aa5-470b-8ea4-450efe65bb2b"
  />
  
  also checked functionality on codex app
  
  
  ## Notes
  - `just test -p codex-core-plugins` was started locally before splitting
  branches, but I stopped relying on local tests per follow-up and left
  final validation to PR CI.

  felixxia-oai · 2026-06-16 01:16:11 +00:00
  02dce8eb8d
• exec-server: default remote transport to Noise (#26245)

  ## Why
  
  The transport in
  [openai/codex#26242](https://github.com/openai/codex/pull/26242) needs
  to be used by every remote orchestrator-to-executor connection before
  JSON-RPC traffic starts.
  
  ## Changes
  
  - Generates one executor Noise identity when remote exec-server starts
  and registers its public key.
  - Creates a harness identity for each physical remote environment
  connection.
  - Fetches a fresh registry bundle before connecting and validates the
  authenticated harness key before completing the executor handshake.
  - Multiplexes encrypted logical streams over the existing executor
  WebSocket.
  - Adds bounded stream, handshake-failure, and reassembly state.
  - Adds safe lifecycle diagnostics without logging keys, authorizations,
  plaintext, or ciphertext.
  - Covers reconnects, replay rejection, validation failure, framing
  limits, and encrypted JSON-RPC tool traffic.
  
  ## Stack
  
  1. [openai/codex#26242](https://github.com/openai/codex/pull/26242):
  Noise channel and relay transport
  2. **[openai/codex#26245](https://github.com/openai/codex/pull/26245)**:
  remote registration and runtime activation
  
  ## Verification
  
  - `just test -p codex-exec-server`
  - `just fix -p codex-exec-server`
  - `just bazel-lock-check`
  - `cargo shear`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-15 17:39:00 -07:00
  6e50b22e55
• Run core integration tests against a Wine-backed Windows executor (#28401)

  ## Why
  
  We want to exercise a linux app-server against a windows exec-server
  without having to repeat every test case. This approach has slight
  precedent in the remote docker test setup.
  
  ## What
  
  Run the shared `codex-core` integration suite against Windows
  exec-server behavior from Linux. This makes cross-OS path and shell
  regressions visible while keeping unsupported cases owned by individual
  tests.
  
  - Add `local`, `docker`, and `wine-exec` test environment selection with
  legacy Docker compatibility.
  - Extend `codex_rust_crate` to generate a sharded Wine-exec variant
  using a cross-built Windows server and pinned Bazel Wine/PowerShell
  runtimes.
  - Teach remote-aware helpers about Windows paths and track temporary
  incompatibilities with source-local `skip_if_wine_exec!` calls and
  follow-up reasons.

  Adam Perry @ OpenAI · 2026-06-16 00:38:41 +00:00
  1fe89de576
• Preserve hook trust bypass in codex exec threads (#26434)

  Addresses #26383 and #26452
  
  ## Summary
  
  `codex exec --dangerously-bypass-hook-trust` printed the bypass warning,
  but valid untrusted hooks still did not run.
  
  Exec applied the flag to its initial config, then lost it when
  app-server reloaded config for the new or resumed thread.
  
  ## Fix
  
  Forward `bypass_hook_trust: true` through the existing thread request
  config override for both start and resume.
  
  The override is omitted when the flag is not enabled, preserving normal
  trust behavior.
  
  ## Testing
  
  Added:
  
  - A test confirming start and resume preserve the override.
  - An end-to-end exec test confirming a `SessionStart` hook runs and
  creates a marker file.

  Abhinav · 2026-06-15 17:36:21 -07:00
  d007b0852a
• Add a toggle for realtime startup context (#28405)

  ## Summary
  - Add `includeStartupContext` to realtime start requests so callers can
  explicitly skip Codex startup context while keeping the backend prompt
  - Thread the new flag through protocol types, request processing, and
  realtime session config
  - Update app-server docs and coverage for the new default and opt-out
  behavior
  
  ## Testing
  - Added protocol serialization coverage for `includeStartupContext`
  - Added realtime integration coverage for starting a session with
  startup context disabled

  guinness-oai · 2026-06-15 17:14:22 -07:00
  d5b4b98370
• [codex] Centralize plugin auth capability filtering (#27902)

  ## Summary
  
  This is the first step in making plugin auth routing consistent. The
  rule should not live as one-off checks in every place that loads or
  displays plugin capabilities.
  
  This PR introduces a small resolver for the auth-level policy: given a
  plugin's declared apps, MCP servers, current auth mode, and active
  state, return the capabilities that are actually usable in that context.
  
  ## Why
  
  Product rule:
  - SiWC auth can use app connectors, so app declarations stay available.
  - API-key/direct auth cannot use app connectors, so app declarations are
  removed.
  - When an active plugin has both an app and an MCP server with the same
  name, the app route wins for Codex-backed auth and the conflicting MCP
  server is hidden.
  
  Putting that rule in `capabilities.rs` gives the rest of the stack one
  place to ask instead of duplicating auth checks in loader, manager,
  marketplace, and details code.
  
  ## Validation
  
  - `cargo fmt`
  - `cargo test -p codex-core-plugins`

  felixxia-oai · 2026-06-16 00:13:27 +00:00
  7e0dce91df
• [codex] Add second-based OTEL duration histograms (#27058)

  ## Why
  
  Exec-server request and connection latencies need fractional-second
  histograms. The existing duration API records integer milliseconds and
  uses millisecond-scale buckets.
  
  ## What changed
  
  - Adds a described duration API that records `Duration` values as
  fractional seconds.
  - Uses second-scale explicit histogram boundaries.
  - Caches duration histograms by name, unit, and description, matching
  the existing instrument caching model.
  - Covers exact boundaries, representative bucket placement, fractional
  sums, and exported metadata.
  
  This PR only adds the duration primitive. It does not add exec-server
  adoption.
  
  ## Stack
  
  1. #26091: counter descriptions
  2. #27057: gauge instruments
  3. **#27058: second-based duration histograms**
  4. #25019: initialize exec-server OpenTelemetry at startup
  
  Related independent coverage: #27059 tests OTLP HTTP log and trace event
  export.
  
  ## Validation
  
  - `just test -p codex-otel`

  richardopenai · 2026-06-15 17:10:52 -07:00
  8aac63f477
• [codex] Fix missing response item metadata in tests (#28415)

  Summary
  - Add the two missing `metadata: None` initializers after #28355 made
  response-item metadata required.
  - Restore test compilation for `codex-core` and `codex-api` on main.
  
  Validation
  - `git diff --check`
  - `just fmt` (Rust formatting passed; unrelated Python formatter steps
  could not use the sandboxed shared `uv` cache)
  - Focused crate tests are running after PR creation.

  Alex Daley · 2026-06-16 00:08:39 +00:00
  515f705426
• Use PathUri in filesystem permission paths for exec-server (#28165)

  ## Why
  
  Progress towards letting app-server and exec-server run on different
  platforms, specifically for sandbox configuration.
  
  ## What
  
  - Make the filesystem path containment hierarchy generic, defaulting to
  `AbsolutePathBuf` for now.
  - Have clients specify `AbsolutePathBuf` or `PathUri` directly where
  needed.
  - Use `PathUri` throughout exec-server filesystem protocol and trait
  boundaries.
  - Implement `From` for conversion to path URIs and `TryFrom` for
  fallible conversion to absolute paths through the generic type
  hierarchy.

  Adam Perry @ OpenAI · 2026-06-15 23:55:23 +00:00
  46f17930b6
• exec-server: add Noise relay transport (#26242)

  ## Why
  
  Rendezvous forwards traffic between the orchestrator and exec-server.
  The endpoints need to authenticate each other and encrypt that traffic
  without trusting Rendezvous with plaintext or endpoint keys.
  
  ## Changes
  
  - Adds a hybrid Noise IK channel through Clatter using X25519,
  ML-KEM-768, AES-256-GCM, and SHA-256.
  - Binds each handshake to `environment_id`, `executor_registration_id`,
  and `stream_id`.
  - Pins the registry-provided executor key and carries the harness
  authorization inside the encrypted handshake.
  - Orders relay frames before consuming Noise nonces and fragments large
  JSON-RPC messages into bounded records.
  - Bounds handshake payloads, frames, streams, and message reassembly.
  
  Runtime activation is in
  [openai/codex#26245](https://github.com/openai/codex/pull/26245).
  
  ## Stack
  
  1. **[openai/codex#26242](https://github.com/openai/codex/pull/26242)**:
  Noise channel and relay transport
  2. [openai/codex#26245](https://github.com/openai/codex/pull/26245):
  remote registration and runtime activation
  
  ## Verification
  
  - `just test -p codex-exec-server`
  - Oversized initiator payload regression coverage
  - `just fix -p codex-exec-server`
  - `just bazel-lock-check`
  - `cargo shear`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-06-15 16:39:41 -07:00
  428cd44154
• [codex-analytics] Analytics Capture to File in Debug Builds (#27093)

  ## This PR
  
  The original [combined remote plugin analytics PR
  #26281](https://github.com/openai/codex/pull/26281) mixed reusable
  analytics test infrastructure, two manual smoke workflows, a metadata
  refactor, and the final identity behavior. This PR isolates the generic
  capture mechanism so it can be reviewed and landed before any
  plugin-specific behavior.
  
  - Add a debug-only analytics destination that writes final request
  payloads as JSONL.
  - Suppress HTTP delivery whenever capture mode is selected, including
  after capture write failures.
  - Keep release behavior unchanged even when the capture environment
  variable is present.
  - Keep the mechanism generic; this PR contains no plugin-specific
  behavior.
  
  Set `CODEX_ANALYTICS_EVENTS_CAPTURE_FILE=/path/events.jsonl` when
  running a debug Codex binary to inspect the exact batched payload that
  would otherwise be sent to the analytics endpoint.
  
  ## Testing
  
  - `just test -p codex-analytics` (76 passed)
  - `just test --release -p codex-analytics` (73 passed)
  - CI is green across the required platform matrix.
  
  ## Split Overview
  
  ```text
  main
  ├── #27093  Debug analytics capture                 ← you are here
  │   └── #27099  Non-mutating plugin smoke
  │       └── #27100  Remote install/uninstall smoke
  └── #27102  Plugin telemetry metadata refactor
  
  After #27093, #27099, #27100, and #27102 merge:
  └── Final PR: add remote_plugin_id to plugin analytics
  ```
  
  Review order and dependencies:
  
  1. [#27093 Add debug-only analytics event
  capture](https://github.com/openai/codex/pull/27093) **(this PR, based
  on `main`)**
  2. [#27099 Add a plugin analytics smoke
  workflow](https://github.com/openai/codex/pull/27099) (stacked on
  #27093)
  3. [#27100 Add a remote plugin analytics mutation smoke
  workflow](https://github.com/openai/codex/pull/27100) (stacked on
  #27099)
  4. [#27102 Centralize plugin telemetry metadata
  construction](https://github.com/openai/codex/pull/27102) (independent,
  based on `main`)
  5. Final remote-ID behavior PR (created after PRs 1-4 merge)
  
  The original [#26281](https://github.com/openai/codex/pull/26281)
  remains open as the green aggregate reference until the final PR is
  published.

  jameswt-oai · 2026-06-15 16:32:38 -07:00
  e512e884ed
• Add realtime speech append control (#27917)

  ## Why
  
  Realtime voice harness tuning needs app-side control over what backend
  Codex text is spoken. Backend orchestrator text is written for a reading
  UI, so automatically speaking every preamble, progress update, or final
  assistant message can make the realtime voice model too chatty.
  
  For experimentation, clients need two simple controls: keep app/client
  text-item injection on the existing item-create path, and add an
  explicit speakable path that app code can call only when it wants
  realtime to speak. Automatic Codex output also needs an opt-in way to
  switch from the protocol's default speakable path to regular realtime
  items, with a caller-provided prefix so prompt wording can be tuned
  outside core.
  
  The default remains unchanged: if a client omits the new start fields
  and never calls `appendSpeech`, automatic backend output continues down
  the existing speakable path for the selected realtime protocol.
  
  ## What Changed
  
  - Adds experimental `thread/realtime/appendSpeech` for app-provided
  speakable text.
  - Keeps existing `thread/realtime/appendText` as the item-create API for
  app-provided realtime text items.
  - Adds `codexResponsesAsItems` / `codex_responses_as_items` on
  `thread/realtime/start` to send automatic Codex responses with
  `conversation.item.create` instead of the protocol's default speakable
  output path.
  - Adds `codexResponseItemPrefix` / `codex_response_item_prefix` so
  clients can prepend experiment instructions to those automatic Codex
  response items.
  - Keeps literal `conversation.handoff.append` routing scoped to the v1
  speakable path; v2 default speech uses its item/function-output plus
  `response.create` behavior.
  - Removes the earlier public silent-context API and hardcoded
  silent-context prefix.
  - Updates realtime tests to cover default automatic speakable behavior,
  opt-in automatic item-create behavior, and explicit `appendSpeech`
  behavior.
  
  ## Validation
  
  - `cargo check -p codex-core -p codex-app-server -p codex-api`
  - `just test -p codex-app-server realtime_conversation`
  - `just test -p codex-core realtime_conversation` (50/51 passed in the
  filtered parallel run; the lone failure passed when rerun in isolation)
  - `just test -p codex-core
  conversation_mirrors_assistant_message_text_to_realtime_handoff`
  - `just test -p codex-api
  e2e_connect_and_exchange_events_against_mock_ws_server`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`
  - `cargo build -p codex-cli`

  guinness-oai · 2026-06-15 16:15:58 -07:00
  1d8ff89aa3
• [codex] retain resolved environments across turns (#27955)

  ## Why
  
  Selected execution environments are thread-scoped resources, but startup
  and turn construction repeatedly resolved their IDs and working
  directories. That discarded existing environment handles and shell
  metadata even when a selection had not changed.
  
  Session configuration updates also need to affect future turns without
  changing the resolved environment set already captured by a running
  turn.
  
  ## What changed
  
  - Create a `ThreadEnvironments` service inside `Codex` from the spawned
  `EnvironmentManager` and raw environment selections, then store it on
  `SessionServices`.
  - Split service construction from `update_selections`, allowing session
  configuration updates to mutate the resolved set in place.
  - Retain an existing `TurnEnvironment` when its environment ID and
  working directory match; resolve only added or changed selections and
  remove selections that are no longer present.
  - Normalize duplicate IDs by keeping the first selection and skip
  individual selections that fail to resolve instead of rejecting the
  entire update.
  - Give each `TurnContext` a cloned `TurnEnvironmentSnapshot`, so later
  session configuration updates affect future turns without rewriting an
  active turn.
  - Reuse the service-owned environment manager and resolved snapshot for
  startup work, MCP initialization, and child-thread spawning instead of
  flowing resolved environments through spawn arguments.
  
  ## Test plan
  
  - `cargo check -p codex-core --tests`
  - `just test -p codex-core environment_selection`
  - `just test -p codex-core turn_environments`
  - `just test -p codex-core
  session_update_settings_does_not_rewrite_sticky_environment_cwds`
  - `just test -p codex-core
  default_turn_does_not_overlay_legacy_fallback_cwd_onto_stored_thread_environments`

  pakrym-oai · 2026-06-15 16:15:07 -07:00
  9728992fab
• [codex] Preserve remote plugin directory order (#28395)

  ## Summary
  
  - preserve the plugin directory endpoint's response order while merging
  installed state
  - append unmatched installed-only plugins afterward when requested
  - add focused coverage for directory order and installed-only placement
  
  ## Why
  
  The remote marketplace merge currently reconstructs plugins through
  ordered maps and sets, then sorts the result alphabetically by display
  name. That discards any ordering supplied by the plugin directory
  endpoint before the list reaches Desktop.
  
  ## Implementation
  
  Directory plugin IDs are unique, so the merge now iterates the directory
  vector directly in response order. For each directory plugin, it removes
  matching installed state from an ID-indexed map and builds the summary.
  Any entries left in the installed map are installed-only plugins and are
  appended when `include_installed_only` is enabled.
  
  There is no separate rank field, rank map, or final sort. Desktop
  therefore receives directory order—including any backend ranking—and can
  preserve it within its existing stable UI state tiers.
  
  ## Testing
  
  - `just test -p codex-core-plugins` (225 passed)

  jameswt-oai · 2026-06-15 16:09:43 -07:00
  4c1c9bf327
• Deflake realtime handoff steering test (#28300)

  ## Summary
  - keep the realtime mock websocket open for the handoff steering test
  after scripted responses
  - avoid racing the mock server close before the standalone handoff
  append is observed, which was showing up as a Windows timeout in CI
  
  __Details__:
  Failures in samples seem to be caused by:
  1. The mock websocket sends conversation.handoff.requested.
  2. The mock immediately closes the websocket because
  start_websocket_server(...) defaults to close_after_requests: true.
  3. On Windows, that close often surfaces as os error 10053 / 10054.
  4. The realtime stream shuts down before the routed handoff finishes
  creating/steering the follow-up request.
  5. The test waits for the expected follow-up event and times out.
  
  The PR changes only step 2: for this test, the mock websocket stays open
  after sending the scripted handoff event. The same handoff event is
  still sent, and the test still asserts the important steering behavior:
  1. first Responses request has the original prompt
  2. first request does not contain realtime delegation
  3. second Responses request does contain the realtime delegation
  
  ## Validation
  - `just fmt`
  - `just test -p codex-core --test all
  suite::realtime_conversation::inbound_handoff_request_steers_active_turn`
  
  ## Recent CI failures with the same signature
  
  -
  https://github.com/openai/codex/actions/runs/27538033492/job/81392362858
    - 2026-06-15, `[codex] update multi-agent v2 prompts`
  - same test failed after `conversation.handoff.requested`; websocket
  read failed with `os error 10053`
  
  -
  https://github.com/openai/codex/actions/runs/27543877820/job/81412200651
  - 2026-06-15, `feat: dispatch queued user messages through core idle
  extensions`
    - same test failed; websocket read failed with `os error 10054`
  
  -
  https://github.com/openai/codex/actions/runs/27544342375/job/81413801641
    - 2026-06-15, `[codex] Make marketplace loading capability aware`
    - same test failed; websocket read failed with `os error 10053`

  felixxia-oai · 2026-06-15 23:50:11 +01:00
  db8927a8e2
• [codex] Reuse Apps policy evaluation across MCP tool exposure (#27813)

  ## Summary
  
  - move `AppToolPolicyEvaluator` and the Apps config/requirements policy
  logic from `codex-core` into `codex-connectors`
  - resolve one immutable policy snapshot per exposure build and reuse it
  across every Codex Apps MCP tool
  - keep core as a thin adapter from MCP metadata to connector-owned
  policy input while preserving the call-time defense-in-depth check
  
  ## Why
  
  `build_mcp_tool_exposure` evaluates every Codex Apps tool on each
  sampling request. The old path rebuilt effective Apps configuration for
  every tool, and the policy implementation lived in the already-large
  core crate even though it is connector-specific.
  
  The connector-owned evaluator keeps the expensive config merge/decode
  out of the loop and gives core only the effective policy result it
  needs.
  
  ## Performance
  
  With the real 557-tool Apps corpus, `build_mcp_tool_exposure` measured
  3.74 ms and 3.33 ms after the extraction (3.54 ms mean). The original
  path measured 807 ms mean, so the final result retains the 99.6%
  reduction.
  
  ## Validation
  
  - `cargo check -p codex-connectors -p codex-core`
  - `just test -p codex-connectors` — 15 passed
  - `just test -p codex-core --lib connectors` — 35 passed
  - `just test -p codex-core --lib mcp_tool_exposure` — 5 passed
  - `just test -p codex-core --lib mcp_tool_call` — 72 passed
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-connectors`
  - `just fix -p codex-core`
  - `just fmt`

  Matthew Zeng · 2026-06-15 15:24:33 -07:00
  1fbaac1e50
• Respect blocking PostToolUse hooks in code mode (#28365)

  ## Summary
  
  Make blocking hook behavior reliable for tools invoked from code mode.
  
  Previously, a `PostToolUse` hook could block a completed tool result,
  but code mode would still return the original typed result to
  JavaScript. The hook appeared blocked in hook telemetry while the
  running script continued with the result.
  
  This change:
  
  - rejects the nested JavaScript tool promise when `PostToolUse` blocks
  - normalizes `decision: "block"` and exit code 2 to the same blocking
  behavior
  - surfaces the hook feedback as the rejected promise's error
  - adds end-to-end coverage for the relevant PreToolUse and PostToolUse
  interactions
  
  ## Hook semantics in code mode
  
  | Hook behavior | Code-mode result |
  |---|---|
  | PreToolUse block | Reject the promise before the tool executes |
  | PreToolUse `updatedInput` | Execute the rewritten invocation and
  return its result |
  | PostToolUse `decision: "block"` | Execute the tool, then reject the
  promise with the hook reason |
  | PostToolUse exit code 2 | Same behavior as `decision: "block"` |
  | PostToolUse `continue: false` | Preserve the existing feedback-only
  behavior; do not reject the promise |
  
  ## Test coverage
  
  Added or strengthened end-to-end coverage proving that:
  
  - a PreToolUse block rejects the JavaScript promise before execution
  - a PreToolUse input rewrite executes only the rewritten command
  - JavaScript receives the rewritten command's result
  - PostToolUse `decision: "block"` rejects after the command executes
  - PostToolUse exit code 2 has the same behavior
  - the hook observes the original completed tool response
  - the blocked original result does not reach JavaScript
  - existing direct-mode replacement behavior remains intact
  - `continue: false` without a reason produces deterministic fallback
  feedback

  Abhinav · 2026-06-15 15:12:26 -07:00
  d7f298fe20
• [codex] Add created-by-me remote plugin marketplace (#28203)

  ## Summary
  - add the `created-by-me-remote` marketplace backed by paginated
  `scope=USER` plugin directory and installed-plugin requests
  - include USER plugins in installed-plugin caching, bundle sync, and
  stale-cache cleanup without client-side discoverability filtering
  - expose the marketplace through app-server v2 and regenerate the
  protocol schemas
  
  ## Testing
  - `cargo build -p codex-app-server --bin codex-app-server`
  - production-auth `plugin/list` smoke test for `created-by-me-remote`
  (returned the expected USER plugin as installed and enabled)
  - `just test -p codex-core-plugins` (221 passed)
  - `just test -p codex-app-server-protocol` (231 passed)
  - `just test -p codex-app-server suite::v2::plugin_list::` (37 passed)
  - `just fix -p codex-core-plugins -p codex-app-server-protocol -p
  codex-app-server`
  - `just fmt`

  Eric Ning · 2026-06-15 22:07:07 +00:00
  709f19e111
• feat(core): add metadata field to ResponseItem (#28355)

  ## Description
  
  This PR adds an optional `metadata` field to `ResponseItem` for
  Responses API calls. Only mechanical plumbing, no actual values
  populated and sent yet. Turns out just adding a new field to
  `ResponseItem` has quite a large blast radius already.
  
  This change is backwards compatible because `metadata` is optional and
  omitted when absent, so existing response items and rollout history
  without it still deserialize and requests that do not set it keep the
  same wire shape. For provider compatibility, we strip out `metadata`
  before non-OpenAI Responses requests so Azure and AWS Bedrock never see
  this field.
  
  My followup PR here will actually make use of it to start storing and
  passing along `turn_id`: https://github.com/openai/codex/pull/28360
  
  ## What changed
  
  - Added `ResponseItemMetadata` with optional `turn_id`, plus optional
  `metadata` on Responses API item variants and inter-agent communication.
  - Preserved item metadata through response-item rewrites such as
  truncation, missing tool-output synthesis, compaction history
  rebuilding, visible-history conversion, rollout/resume, and generated
  app-server schemas/types.
  - Strip item metadata from non-OpenAI Responses requests while
  preserving it for OpenAI-shaped requests.
  - Updated the mechanical fixture/test construction churn required by the
  new optional field.

  Owen Lin · 2026-06-15 15:05:28 -07:00
  040dafa32d
• feat(app-server): expose rate-limit reset credits (#28143)

  ## Why
  
  Codex users can earn personal rate-limit reset credits, but app-server
  clients do not currently have an API for reading or redeeming them. This
  adds the backend and protocol foundation used by the `/usage` TUI flow
  in #28154.
  
  ## What changed
  
  - Extend `account/rateLimits/read` with a nullable
  `rateLimitResetCredits` summary sourced from the existing usage
  response.
  - Add backend-client and app-server support for consuming a reset with a
  caller-generated idempotency key. A UUID is recommended, and clients
  reuse the same key when retrying the same logical reset.
  - Return only the consume `outcome`; clients refetch
  `account/rateLimits/read` for updated window state.
  - Document the response field and each consume outcome, and regenerate
  the JSON and TypeScript schema fixtures.
  - Clarify in `AGENTS.md` that new app-server string enum values use
  camelCase on the wire.
  - Update the existing TUI response fixture for the expanded protocol
  shape.
  - Add coverage for authentication, response mapping, backend failures,
  consume outcomes, and request timeout behavior.
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` — 231 passed.
  - `just test -p codex-backend-client` — 14 passed.
  - Focused `codex-app-server` reset-credit tests — 5 passed.
  - Focused `codex-tui` protocol response fixture test — passed.
  - `just fix -p codex-backend-client -p codex-app-server-protocol -p
  codex-app-server` — passed.
  - `just fmt` — passed.

  jay · 2026-06-15 21:54:01 +00:00
  bef99f861b
• core: cache the tool search handler per session (#27258)

  ## Why
  
  Tool router construction rebuilds the deferred-tool BM25 index during
  session initialization and before each sampling continuation, even when
  the searchable tool metadata is unchanged. Local profiling measured
  `append_tool_search_executor` at roughly 113 ms per continuation, making
  repeated index construction the largest measured router-building cost.
  
  ## What changed
  
  - Add a session-scoped `ToolSearchHandlerCache` so continuations and
  user turns can reuse the existing handler.
  - Key reuse on the complete ordered `Vec<ToolSearchInfo>`, rebuilding
  when searchable text, loadable tool specs, source metadata, or ordering
  changes.
  - Build handlers outside the cache lock and recheck before publishing
  them, avoiding holding the mutex during index construction.
  
  ## Verification
  
  - `cache_reuses_identical_search_infos_and_rebuilds_changed_inputs`
  covers exact cache reuse and invalidation when the ordered search
  metadata changes.
  - Local rollout profiling showed the initial router build populating the
  cache and unchanged later continuations reusing it:
    - uncached: 118 ms median across 14 spans from 3 rollouts
    - cached: 4 ms median across 12 spans from 3 rollouts

  mchen-oai · 2026-06-15 14:48:30 -07:00
  af99f6a72f
• Add hidden Windows sandbox wrapper entrypoint (#28358)

  ## Why
  
  This is the second PR in the Windows fs-helper sandbox stack. The
  fs-helper path needs a Windows sandbox launcher that has the same
  argv-shaped contract as macOS `sandbox-exec` and `codex-linux-sandbox`,
  but this PR only introduces that hidden launcher. It does not route
  fs-helper through it yet.
  
  The hidden launcher still needs to be policy-complete before later
  direct-spawn callers use it. In particular, it has to carry the same
  Windows sandbox policy details that the existing spawn paths already
  understand: proxy enforcement, read/write root overrides, and
  deny-read/deny-write overrides.
  
  ## What Changed
  
  - Added the hidden `codex.exe --run-as-windows-sandbox` arg1 dispatch
  path.
  - Added `windows-sandbox-rs/src/wrapper.rs`, which parses the wrapper
  argv, launches the requested command through the shared Windows sandbox
  session runner from PR1, and forwards stdio.
  - Added `create_windows_sandbox_command_args_for_permission_profile()`
  so later direct-spawn callers can build the wrapper argv consistently.
  - Made the wrapper argv round-trip the full Windows sandbox policy
  surface it needs later: workspace roots, environment, permission
  profile, sandbox level, private desktop, proxy enforcement, read/write
  root overrides, and deny-read/deny-write overrides.
  - Carried `proxy_enforced` through the shared Windows session request so
  proxy-managed executions continue to use the offline/elevated sandbox
  identity.
  - Added wrapper argument round-trip coverage for the full policy fields.
  
  ## Verification
  
  - `just test -p codex-windows-sandbox windows_wrapper_args_round_trip`
  - `just test -p codex-arg0`
  - `just test -p codex-core exec::tests::windows_`
  - `just fix -p codex-windows-sandbox -p codex-core -p codex-cli`
  
  Local note: the full `just fmt` command still fails on this workstation
  in non-Rust formatter setup (`uv` cache access denied and missing
  `dotslash`/buildifier), but the Rust formatter phase completed.

  iceweasel-oai · 2026-06-15 21:30:32 +00:00
  fbbe7706d6
• Add Windows unified exec yield floor (#27086)

  ## Why
  
  The Windows `unified_exec` experiment regressed at the turn level in a
  way that points to premature backgrounding / extra command cycles rather
  than individual responses getting heavier:
  
  - `codex_local_tool_calls_per_turn` was up about 20.7%.
  - `codex_local_blended_tokens_per_turn` was up about 4.1%, and
  `codex_local_output_tokens_per_turn` was up about 4.0%.
  - `codex_local_response_latency_per_turn` was up about 8.3%.
  - The primary activity metrics also moved down: `codex_turns` about
  -6.6%, `codex_dau` about -1.0%, and `codex_local_hourly_active_users`
  about -3.0%.
  
  At the same time, the per-response metrics moved in the other direction:
  blended tokens per response, output tokens per response, and latency per
  response were all lower in test. That suggests the bad turn-level shape
  is largely about extra tool/model cycles, not each response being slower
  or more expensive on its own.
  
  Local Windows benchmarking showed the likely mechanism: shell-wrapped
  commands pay a large PowerShell startup/teardown tax before the actual
  command has much time to run. In the benchmark, the PowerShell wrapper
  added roughly 0.7-1.0s versus direct exec:
  
  - Windows PowerShell: about 740ms p50 / 800ms p90 overhead versus direct
  exec.
  - PowerShell 7 (`pwsh`): about 930ms p50 / 980ms p90 overhead versus
  direct exec.
  
  The model commonly asks for a 1s initial yield. On Windows, that can
  spend nearly the whole window waiting on PowerShell machinery, so
  otherwise-short commands are more likely to return as background
  sessions and require follow-up polling/tool calls.
  
  This is intentionally a temporary unlock. It gives Windows closer to the
  same useful post-shell command window as other platforms while we work
  on reducing the PowerShell tax directly, for example with persistent
  PowerShell workers or conservative direct-exec paths for commands that
  do not need shell semantics.
  
  ## What changed
  
  - Adds a Windows-only 2s floor to `unified_exec`'s initial
  `yield_time_ms` clamp.
  - Keeps larger model-requested waits unchanged, including the existing
  10s default.
  - Keeps the existing 30s max clamp.
  - Leaves non-Windows behavior unchanged.
  - Adds platform-gated tests for both the Windows floor and the
  non-Windows clamp behavior.
  
  ## Verification
  
  - `just test -p codex-core unified_exec`

  iceweasel-oai · 2026-06-15 13:56:18 -07:00
  e7a9988d1a
• recover stale Windows sandbox credentials (#27944)

  ## Why
  
  The elevated Windows sandbox persists dedicated sandbox account
  credentials so later commands can launch without reprovisioning. If
  those persisted credentials drift from the actual Windows account
  password, `CreateProcessWithLogonW` fails with `ERROR_LOGON_FAILURE` and
  Codex currently surfaces that as a hard runner launch failure.
  
  This change makes that failure self-healing. When Windows specifically
  rejects the sandbox login, Codex now treats the persisted sandbox
  credentials as stale, regenerates them through the existing setup path,
  and retries the runner launch once.
  
  ## What Changed
  
  - Preserve `CreateProcessWithLogonW` failures as a typed runner logon
  error so callers can distinguish `ERROR_LOGON_FAILURE` from unrelated
  launch failures.
  - Add a sandbox credential refresh helper that deletes the persisted
  `sandbox_users.json` record and reuses `require_logon_sandbox_creds()`
  to reprovision credentials through the established setup flow.
  - Retry elevated runner startup after stale-credential failures in both
  the legacy elevated capture path and unified exec elevated backend.
  - Add focused tests for stale logon failure detection and persisted
  sandbox user file removal.
  
  ## Validation
  
  - `git diff --check`
  - `cargo test -p codex-windows-sandbox`

  iceweasel-oai · 2026-06-15 13:54:24 -07:00
  c0b36d234a
• [codex] Add external agent import result accounting (#28008)

  ## Why
  
  External-agent imports can complete synchronously or continue in the
  background for plugins/sessions. Clients need a stable import id to
  correlate the immediate response with the eventual completion
  notification, and the completion payload needs enough accounting to show
  which artifact types succeeded or failed without hiding partial
  failures.
  
  ## What Changed
  
  - `externalAgentConfig/import` now returns an `importId`;
  `externalAgentConfig/import/completed` includes the same `importId` plus
  type-level `itemResults`.
  - Completed `itemResults` report `successCount`, `errorCount`,
  `successes`, and `rawErrors` for each migrated item type.
  - Added protocol/schema/TypeScript types for import successes, raw
  errors, and type-level results. No progress notification is included in
  the final PR.
  - `ExternalAgentConfigService::import` now returns an outcome object
  with synchronous item results and pending plugin imports.
  - Plugin import outcomes track succeeded/failed marketplaces, plugin
  ids, and raw errors. Plugin failures can be reported in completed
  accounting while later migration items continue.
  - Non-plugin synchronous import failures still fail the request, so
  invalid config/skills-style failures are not reported as a successful
  import response.
  - Session imports now return item results. Successful imports include
  the source session path and imported thread id; prepare, persist,
  ledger, and source-validation failures become raw errors in completion
  accounting where the import can continue.
  - The request processor generates the `importId`, aggregates synchronous
  results with background plugin/session results, and sends a single
  completed notification when all selected work is done.
  - App-server docs and generated schema fixtures were updated for the new
  response/completed payload shapes.
  
  ## Validation
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server-client event_requires_delivery`
  - `CODEX_SQLITE_HOME=/private/tmp/codex-app-server-review-sync-error
  just test -p codex-app-server
  external_agent_config_import_returns_error_for_failed_sync_import`
  - `CODEX_SQLITE_HOME=/private/tmp/codex-app-server-review-external-agent
  just test -p codex-app-server external_agent_config`
  
  Note: local sandbox validation used `CODEX_SQLITE_HOME` because the
  default sqlite state path is read-only in this environment.

  charlesgong-openai · 2026-06-15 13:25:42 -07:00
  fc1fb682a7
• [mcp] Increase default tool timeout to 300 seconds (#28234)

  Summary
  - Increase the default MCP tool-call timeout from 120 to 300 seconds.
  
  Validation
  - `just test -p codex-mcp`
  - `just fmt`

  Alex Daley · 2026-06-15 16:07:01 -04:00
  41db093aa0
• Add request user input auto-resolution timer (#28235)

  ## Summary
  - Add TUI auto-resolution handling for `request_user_input` prompts when
  `autoResolutionMs` is present.
  - Use a 60s hidden grace period followed by a 60s visible countdown,
  then submit an empty answer response if the user does not interact.
  - Snooze auto-resolution on key or paste interaction and add
  snapshot/test coverage for the countdown UI.
  
  ## Notes
  - The TUI currently treats `autoResolutionMs` as an enable signal and
  intentionally does not use the provided duration value for the countdown
  policy.
  
  ### Auto resolution
  
  
  https://github.com/user-attachments/assets/5323152f-2ece-4aba-b75d-c32aa776f544
  
  
  ### Snooze after interaction
  
  
  https://github.com/user-attachments/assets/100d54c4-3a41-4c6c-9c07-cd28075a0d62

  Shijie Rao · 2026-06-15 11:49:19 -07:00
  1b81365926
• [codex] add path-types skill (#28347)

  ## Why
  
  Codex contributors and agents need repository-scoped guidance for
  choosing compatible Rust types
  for operating system paths during the ongoing URI migration. Keeping the
  guidance in the repository
  makes the app-server and exec-server rules available consistently
  without relying on a personal
  skill installation.
  
  ## What
  
  - Add the `path-types` skill at `.codex/skills/path-types/SKILL.md`.
  - Document the intended uses of `ApiPathString`, `PathUri`,
  `AbsolutePathBuf`, and `PathBuf` across
    protocol, internal, and shared dependency boundaries.
  - Keep migrations of existing types limited to explicit requests and
  proportional edits.
  
  ## Validation
  
  - Validated the skill structure with skill-creator's
  `quick_validate.py`.

  Adam Perry @ OpenAI · 2026-06-15 11:48:31 -07:00
  71633f8b8f
• Use aws-lc-rs for rustls crypto provider (#27706)

  ## Why
  
  Some enterprise TLS proxies issue certificate chains signed with
  `ecdsa_secp521r1_sha512` / `ECDSA_NISTP521_SHA512`. Custom CA
  configuration such as `SSL_CERT_FILE` can add the right trust root, but
  it cannot make `rustls`'s `ring` verifier support a certificate
  signature algorithm it does not advertise.
  
  That can still break TLS after the CA bundle is configured, including on
  Rust websocket paths that call the shared
  `ensure_rustls_crypto_provider()` helper, such as the Responses
  websocket connector and remote app-server client:
  
  -
  [`codex-api/src/endpoint/responses_websocket.rs`](https://github.com/openai/codex/blob/eddc5c75ed527a8348bfcaa85692e53189600833/codex-rs/codex-api/src/endpoint/responses_websocket.rs#L441)
  -
  [`app-server-client/src/remote.rs`](https://github.com/openai/codex/blob/eddc5c75ed527a8348bfcaa85692e53189600833/codex-rs/app-server-client/src/remote.rs#L718)
  
  The `aws-lc-rs` `rustls` provider supports this P-521/SHA-512
  certificate signature scheme, so use it as Codex's process-wide `rustls`
  provider.
  
  ## What Changed
  
  - Switch the workspace `rustls` feature from `ring` to `aws_lc_rs`.
  - Update `codex-utils-rustls-provider` to install
  `rustls::crypto::aws_lc_rs::default_provider()`.
  - Add an assertion and integration test that the installed provider
  supports `ECDSA_NISTP521_SHA512`.
  
  ## Verification
  
  ```shell
  just fmt
  just test -p codex-utils-rustls-provider
  just bazel-lock-update
  just bazel-lock-check
  ```

  malsamiri-oai · 2026-06-15 11:32:13 -07:00
  d5a8117e08
• Extract shared Windows sandbox session runner (#28357)

  ## Why
  
  This is the first PR in a stack for the Windows fs-helper sandbox fix.
  Before changing fs-helper behavior, this pulls the reusable Windows
  sandbox session launch pieces out of the debug CLI path so later PRs can
  call the same backend selection and stdio forwarding logic.
  
  Keeping this as a pure refactor makes the later security fix easier to
  review: `codex sandbox windows` should continue to launch the same
  elevated or restricted-token backend, just through shared APIs in
  `windows-sandbox-rs` instead of code local to
  `cli/src/debug_sandbox.rs`.
  
  ## What Changed
  
  - Added `WindowsSandboxSessionRequest` and
  `spawn_windows_sandbox_session_for_level()` in `windows-sandbox-rs` to
  share the elevated-vs-legacy session launch decision.
  - Moved the Windows sandbox stdio forwarding helpers from
  `cli/src/debug_sandbox.rs` into
  `windows-sandbox-rs/src/stdio_bridge.rs`.
  - Updated `codex sandbox windows` to call the shared session launcher
  and stdio bridge.
  - Added unit coverage for the moved stdio forwarding helpers.
  
  ## Verification
  
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just test -p codex-windows-sandbox stdio_bridge::tests`
  - `just fix -p codex-windows-sandbox -p codex-sandboxing -p
  codex-exec-server -p codex-arg0 -p codex-core -p codex-file-system`
  - The new `stdio_bridge` tests also passed as part of `just test -p
  codex-windows-sandbox` on the stack tip. That full local run still fails
  in pre-existing legacy session integration tests with
  `CreateRestrictedToken failed: 87` on this workstation.

  iceweasel-oai · 2026-06-15 18:30:48 +00:00
  c3415f76c9
• skills: cache orchestrator resources per thread (#28336)

  ## Why
  
  Hosted orchestrator skills are read through the remote MCP resource
  server. Within one thread, the same catalog or skill resource can be
  requested multiple times by prompt injection and the `skills.list` /
  `skills.read` tools. Re-fetching adds latency and can make those
  surfaces observe different remote contents during the same thread.
  
  This is a follow-up to #28333: orchestrator skills remain limited to
  threads without a local executor, and those threads now get a stable
  per-thread view of the remote skill data they use.
  
  ## What changed
  
  - Reuse the existing per-thread orchestrator catalog snapshot for
  `skills.list` and `skills.read` availability checks.
  - Cache successful orchestrator resource reads by authority, package,
  and resource so prompt injection and tool calls share the same contents.
  - Keep the cache memory-only and bounded to 100 resources and 8 MiB per
  thread.
  - Leave host and executor skill reads unchanged, and do not cache failed
  remote reads.
  
  ## Verification
  
  - Extended the app-server MCP resource integration test to read the same
  hosted skill resource twice and verify that the remote server receives
  one read.
  - The same test verifies that catalog discovery and the selected skill's
  main prompt are each fetched only once per thread.

  jif · 2026-06-15 20:20:19 +02:00
  0afe559318
• core: let steer interrupt wait_agent (#28341)

  ## Why
  
  `wait_agent` can block for a long timeout while waiting for sub-agent
  mailbox activity. Although same-turn user steer is accepted during that
  tool call, the input remains pending until the wait returns, so an
  explicit request to change direction can appear unresponsive.
  
  ## What changed
  
  - Notify active `wait_agent` calls when user input is steered into the
  current turn.
  - Check for already-pending steer input when subscribing so input that
  races with tool startup is not missed.
  - Distinguish mailbox activity, steered input, and timeout outcomes,
  returning `Wait interrupted by new input.` for the steer path.
  - Update the `wait_agent` tool description to document the early-return
  behavior.
  
  ## Testing
  
  - `just test -p codex-core input_queue_`
  - `just test -p codex-core wait_agent`
  
  The coverage includes steer notification before and after subscription,
  plus an end-to-end test that verifies the interrupted wait result and
  steered user input are both included exactly once in the follow-up model
  request.

  jif · 2026-06-15 20:08:15 +02:00
  ee40dddbf6
• Support staging OAuth client ID overrides (#28257)

  ## Summary
  
  - allow app-server ChatGPT login to use a configured OAuth client ID
  - reuse the same client ID for refresh and revoke requests
  - cover staging login, refresh, and revoke request payloads
  
  ## Tests
  
  - `just test -p codex-login`
  - `just test -p codex-app-server
  login_account_chatgpt_uses_debug_oauth_overrides`
  - `just test -p codex-login
  logout_with_revoke_revokes_refresh_token_then_removes_auth`
  - `just fix -p codex-login`
  - `just fix -p codex-app-server`
  - `just fmt`

  Anton Panasenko · 2026-06-15 10:56:53 -07:00
  336f907ec1
• bound prompt image cache retention (#28294)

  ## Why
  
  The prompt image cache was bounded to 32 entries, but not by the size of
  those entries. A set of large encoded images could therefore retain
  substantially more memory than intended. Cache hits also cloned the full
  encoded payload.
  
  ## What changed
  
  - cap the cache at 64 MiB of encoded image data while preserving its
  existing 32-entry limit
  - skip caching an image that exceeds the entire byte budget
  - evict least-recently-used entries until the cache is back within its
  byte budget
  - share cached encoded bytes with `Arc<[u8]>` so cache hits do not
  deep-clone image payloads
  
  ## Validation
  
  - `just test -p codex-utils-image`

  jif · 2026-06-15 19:52:30 +02:00
  aae4c0b02b
• TUI Plugin Sharing 2 - add remote plugin section plumbing (#26702)

  This adds the background plumbing for remote-backed plugin catalog
  sections while leaving the fuller directory presentation to the next PR.
  The TUI can fetch section-specific remote marketplace results, keep
  local plugin data available, and carry section errors forward for later
  rendering.
  
  - Fetches explicit remote marketplace kinds for curated, workspace, and
  shared-with-me sections.
  - Gates shared-with-me loading on the plugin sharing feature flag.
  - Adds section-level error state and user-actionable error copy.
  - Merges remote marketplace results into the cached plugin list without
  discarding local results.

  canvrno-oai · 2026-06-15 10:25:37 -07:00
  29224d945b
• guardian: isolate review context from skills and memories (#28285)

  ## Why
  
  Guardian reviews embed the parent session transcript as untrusted
  evidence. Skill or plugin mentions in that transcript must not be
  interpreted as requests to inject more instructions into the Guardian
  request, and memory context adds unrelated model-visible context to an
  approval decision.
  
  Keeping those sources out of the nested review session makes the request
  smaller and preserves the trust boundary around the transcript being
  assessed.
  
  ## What changed
  
  - Skip skill and plugin discovery when building turns for Guardian
  reviewer sessions.
  - Disable memory context and dedicated memory tools in the derived
  Guardian configuration.
  - Extend the Guardian request-layout coverage to verify that a `$skill`
  mention remains visible only as transcript evidence while neither the
  skill body nor memory context is injected.
  - Expand the Guardian configuration test to cover the disabled memory
  settings.
  
  ## Testing
  
  - Updated the Guardian review request snapshot and assertions for skill
  and memory isolation.
  - Extended the Guardian session configuration test to cover memories.

  jif · 2026-06-15 19:24:50 +02:00
  a18de1f3b6
• [codex] preserve explicit environment cwd (#27995)

  ## Why
  
  `TurnEnvironmentSelections::new` rewrote the primary environment's
  explicit `cwd` to the legacy fallback cwd. For a remote-first selection,
  this could replace the remote working directory with a local fallback
  path and made the legacy cwd overlay authoritative over
  environment-owned state.
  
  ## What changed
  
  - Preserve every explicit environment cwd when constructing turn
  environment selections.
  - Keep `cwd`-only app-server updates compatible by rebuilding the
  default environment selections at the requested cwd.
  - Cover both explicit primary cwd preservation and cwd-only updates
  reaching the model-visible execution environment.
  
  ## Testing
  
  - `just test -p codex-core
  session_update_settings_does_not_rewrite_sticky_environment_cwds`
  - `just test -p codex-core
  environment_settings_preserve_explicit_primary_cwd`
  - `just test -p codex-app-server
  thread_settings_update_cwd_retargets_default_environment`

  pakrym-oai · 2026-06-15 17:17:34 +00:00
  bd4fe31c5a
• reuse encoded Responses request bodies (#28327)

  ## Why
  
  Responses HTTP requests were converted from `ResponsesApiRequest` into a
  full `serde_json::Value`. `EndpointSession` then deep-cloned that value
  for each retry, and the transport serialized and compressed it again
  before every send.
  
  Large histories make those copies expensive. Retry attempts should reuse
  the same immutable request bytes.
  
  ## What
  
  - Serialize standard Responses requests directly into a ref-counted
  `EncodedJsonBody`.
  - Preserve the Azure path that attaches item IDs before encoding.
  - Prepare JSON, compression, and derived content headers once before the
  retry loop.
  - Clone the prepared request per attempt so body clones only bump the
  `Bytes` reference count.
  - Keep auth inside the retry loop. Signing auth sees the exact final
  headers and body bytes that the transport sends.
  - Preserve request-body TRACE output. With TRACE plus compression,
  retain the original JSON bytes for logging; normal requests keep only
  the final wire bytes.
  - Leave non-Responses endpoint bodies on the existing `Value` path.
  
  ## Performance
  
  A temporary release-mode measurement used a 10 MiB JSON body and 10
  retry preparations:
  
  - old `Value` clone + serialize path: 30 ms total
  - prepared shared-byte path: less than 1 ms total
  
  That is about 3 ms avoided per retry for this payload on the test
  machine. Each retry also stops allocating another request-sized JSON
  tree and serialized buffer. Without TRACE, compressed requests retain
  only the final compressed wire bytes.
  
  ## Validation
  
  - `just test -p codex-client` — 28 passed
  - `just test -p codex-api` — 125 passed
  - `just fix -p codex-client`
  - `just fix -p codex-api`

  jif · 2026-06-15 19:11:26 +02:00
  495da45643
• [codex] Cover OTLP HTTP log and trace event export (#27059)

  ## Why
  
  The generic OTLP HTTP paths for log events and trace events need
  end-to-end coverage before exec-server relies on them.
  
  ## What changed
  
  - Adds loopback coverage for exporting `codex_otel.log_only` events to
  `/v1/logs`.
  - Verifies `codex_otel.trace_safe` events are present in the exported
  trace payload.
  
  This is a test-only PR. It does not change OTEL runtime behavior or
  metric APIs.
  
  ## Related work
  
  - #26091: counter descriptions
  - #27057: gauge instruments
  - #27058: second-based duration histograms
  
  This PR is independent and can land directly on `main`.
  
  ## Validation
  
  - `just test -p codex-otel`
  - `just fix -p codex-otel`
  - `just fmt`

  richardopenai · 2026-06-15 09:59:26 -07:00
  bed60e3746
• [codex] remove stale PathExt import (#28344)

  ## Why
  
  `main` fails dev-profile Cargo and Bazel Clippy builds because
  `core/src/tools/runtimes/mod_tests.rs` imports `PathExt` after its last
  use was removed. With warnings denied, that stale import prevents
  `codex-core` test targets from compiling across platforms.
  
  ## What changed
  
  Remove the unused `PathExt` import. Remaining `.abs()` calls in the
  module operate on `PathBuf` and continue to use `PathBufExt`.
  
  ## Validation
  
  - `just fmt`
  - Focused `codex-core` test compile attempted; blocked locally by disk
  exhaustion before compilation completed. The CI failure itself is the
  unused-import diagnostic this change removes.

  pakrym-oai · 2026-06-15 09:56:21 -07:00
  5e58b6d77f
• avoid cloning websocket request history (#28313)

  ## Why
  
  WebSocket continuations only send the new part of a request. Checking
  whether a request could be continued was cloning the full previous
  request, the current request, and their input history.
  
  For long conversations or large tool lists, that meant copying several
  request-sized values on every continuation.
  
  ## What changed
  
  - compare the request settings by reference
  - check the previous input and server response as borrowed prefixes
  - allocate only the new input items that will be sent
  
  The reuse rules stay the same, including ignoring `client_metadata` for
  this check.
  
  The comparison is still `O(n)`, but it removes several `O(n)`
  allocations and copies. Temporary memory no longer grows by multiple
  full request sizes for each continuation.
  
  ## Performance
  
  Local rollout traces show continuation checks on turns around 260k input
  tokens. Before this change the reuse gate cloned the previous request,
  the current request, and the previous input history before deciding
  whether it could continue incrementally. After this change it borrows
  those structures and allocates only the incremental tail. For large
  continuations with a small delta, that removes roughly three
  request-sized copies from the hot path and reduces temporary memory from
  multiple full request sizes to just the new tail.
  
  ## Validation
  
  - `just test -p codex-core
  responses_websocket_v2_creates_with_previous_response_id_on_prefix`
  - `just test -p codex-core
  responses_websocket_v2_creates_without_previous_response_id_when_non_input_fields_change`

  jif · 2026-06-15 18:48:47 +02:00
  95765542c9
• serialize websocket requests directly (#28323)

  ## Why
  
  Responses WebSocket requests were encoded in two steps: first into a
  full `serde_json::Value`, then again into the JSON string sent over the
  socket.
  
  That walks the full request twice and keeps an extra JSON tree alive.
  These requests can contain the complete conversation history and tool
  schemas, so the extra work grows with the request size.
  
  ## What changed
  
  - serialize `ResponsesWsRequest` directly to the wire string
  - pass that string through the existing WebSocket stream and send path
  - keep the existing error mapping, tracing, send timeout, and telemetry
  behavior
  - compare the new wire JSON with the previous `to_value` payload in a
  focused test
  
  ## Performance
  
  I measured both paths in an optimized temporary test using a
  6,324,180-byte request: 4 MiB of history plus 256 tools with 8 KiB
  descriptions. Each path ran 100 times.
  
  - previous `to_value` + `to_string`: 209 ms total, 2.09 ms per request
  - direct `to_string`: 174 ms total, 1.74 ms per request
  - difference: about 17% faster, or 0.35 ms per request
  
  The direct path also removes one full temporary `serde_json::Value`
  tree. For this mostly string-backed payload, that avoids roughly one
  payload-sized copy plus the JSON node overhead. The exact memory saving
  depends on the request shape.
  
  The temporary benchmark was removed before committing.
  
  ## Validation
  
  - `just test -p codex-api` — 125 passed
  - `just fix -p codex-api`

  jif · 2026-06-15 18:33:35 +02:00
  baddb5e686
• avoid cloning sampling request input (#28306)

  ## Why
  
  Every model request cloned the full prepared input just to keep it for
  the legacy after-agent hook. That copy gets more expensive as the
  conversation grows.
  
  ## What
  
  Move the prepared input into the sampling loop and return it with the
  result. If the request retries, keep the first input so the hook still
  sees the same data as before.
  
  This removes one `O(n)` clone per sampling request, where `n` is the
  size of the prepared input. It saves `O(n)` copy work and `O(n)`
  temporary memory.
  
  No behavior change is intended.
  
  ## Performance
  
  Local rollout traces show turns reaching roughly 260k input tokens. On
  turns of that size, this removes the only unconditional full
  prepared-input clone on the happy path. That avoids one request-sized
  allocation/copy per sampling attempt for large conversations, and the
  savings scale linearly with request size.
  
  ## Testing
  
  - `just test -p codex-core continue_after_stream_error`
  - `just fix -p codex-core`

  jif · 2026-06-15 18:26:44 +02:00
  e67bc683f3
• linearize history output normalization (#28309)

  ## Why
  
  When we prepare the conversation history, every tool call needs a
  matching output.
  
  Before this change, we scanned the full history again for every call. In
  a tool-heavy conversation, that makes the work `O(items x calls)`, or
  `O(n^2)` in the worst case.
  
  ## What
  
  Scan the history once and collect the IDs of existing outputs. Then each
  call can check its ID with an expected `O(1)` lookup.
  
  The full normalization step is now expected `O(n)`. The output order and
  missing-output behavior stay the same.
  
  ## Performance
  
  Based on local rollout traces, one tool-heavy session reached roughly
  17,050 transcript items with about 4,292 tool-call items. On a history
  of that shape, the old `calls x items` scan does about 73.2 million
  membership checks, while the new pass does about 21.3 thousand set
  inserts/lookups. That is roughly 3.4k times less membership work in this
  normalization step.
  
  ## Validation
  
  - `just test -p codex-core normalize_` (19 passed)

  jif · 2026-06-15 18:26:34 +02:00
  828d7476a0
• Expose explicit dynamic tool namespaces in thread start (#27371)

  Stacked on #27365.
  
  ## Stack note
  
  [#27365](https://github.com/openai/codex/pull/27365) kept `thread/start`
  unchanged and converted its input in `thread_processor`. This PR updates
  `thread/start` to accept explicit functions and namespaces directly.
  
  Legacy per-tool arrays are still accepted and converted while reading
  the request. As a result, `thread_processor` can validate and pass the
  tools through directly, which is why some code added in #27365 is
  removed here.
  
  ## Why
  
  `thread/start.dynamicTools` still repeats namespace data on each
  function even though core now stores explicit namespace groups. The
  request API should use the same shape so each namespace has one
  description and one member list.
  
  ## What changed
  
  - Accept top-level functions and explicit namespace objects in
  `dynamicTools`.
  - Continue accepting fully legacy flat arrays, including
  `exposeToContext`.
  - Reject arrays that mix legacy and canonical entries.
  - Reuse the protocol types directly and remove the temporary app-server
  adapter.
  - Update validation, docs, the test client, and generated schemas.
  
  ## Test plan
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  dynamic_tool_call_round_trip_sends_text_content_items_to_model`
  - `just test -p codex-app-server
  thread_start_normalizes_legacy_dynamic_tools_into_model_request`
  - `just test -p codex-app-server
  thread_start_rejects_mixed_dynamic_tool_formats`
  - `just test -p codex-app-server
  thread_start_rejects_hidden_dynamic_tools_without_namespace`

  sayan-oai · 2026-06-15 15:35:57 +00:00
  11faf9af94
• [codex] simplify memory read metrics (#28164)

  ## Why
  
  Memory read telemetry currently reconstructs the executable shell
  command after a tool call finishes. That duplicates shell, login-policy,
  and cwd resolution owned by the tool handlers, and can diverge from the
  environment-specific command that unified exec actually ran.
  
  ## What changed
  
  - Expose the existing restricted shell-script parser directly for raw
  script text.
  - Parse `shell_command` and `exec_command` input into plain command argv
  before classifying memory reads.
  - Preserve all-or-nothing safe-command validation for multi-command
  scripts.
  - Remove cwd resolution, shell selection, and the unnecessary async
  boundary from memory read metric emission.
  
  ## Testing
  
  - `just test -p codex-shell-command`
  - `cargo check -p codex-core`

  pakrym-oai · 2026-06-15 08:28:02 -07:00
  42ad752f36
• chore: restore exec-server relay keepalives (#28286)

  ## Why
  
  The ws pump refactor removed the relay keepalive timers that had been
  added to keep idle rendezvous connections alive. An idle relay could
  therefore be closed by the rendezvous service or a load balancer,
  disconnecting executor-backed MCP processes.
  
  ## What
  
  - restore periodic WebSocket ping frames on both rendezvous relay
  endpoints
  - keep missed-tick behavior bounded with `MissedTickBehavior::Skip`
  - cover the harness and remote-environment pumps with focused
  traffic-after-keepalive tests

  jif · 2026-06-15 17:24:36 +02:00
  bbcfed8ac2
• Remove terminal resize reflow flag gates (#27794)

  ## Why
  
  `terminal_resize_reflow` is now stable and should behave as always on.
  Keeping the disabled runtime paths around made the feature look
  configurable even though the rollout is complete, and old config could
  still suggest there was a supported off mode.
  
  ## What Changed
  
  - Marked `terminal_resize_reflow` as `Stage::Removed` while keeping it
  default-enabled for compatibility.
  - Ignored `[features].terminal_resize_reflow` config entries so stale
  `false` settings no longer affect the effective feature set.
  - Removed TUI branches that depended on the flag being disabled, so
  draw, replay buffering, stream finalization, and resize scheduling all
  assume resize reflow is active.
  - Simplified resize smoke coverage to exercise the always-on behavior
  only.
  
  ## Verification
  
  - `just test -p codex-features`
  - `just test -p codex-tui resize_reflow`
  - `just test -p codex-tui initial_replay_buffer
  thread_switch_replay_buffer`

  Eric Traut · 2026-06-15 08:23:02 -07:00
  8a6a039f26