811 Commits

• Add thread recencyAt for sidebar ordering (#27910)

  ## Summary
  
  Add a server-owned `recencyAt` timestamp and `recency_at` thread-list
  sort key for product recency ordering while preserving the existing
  meaning of `updatedAt` as the latest persisted thread mutation.
  
  This is the server-side alternative to #27697. Rather than narrowing
  `updatedAt`, clients can sort the sidebar by `recency_at` and continue
  treating `updatedAt` as mutation time.
  
  Paired Codex Apps PR:
  [openai/openai#1024599](https://github.com/openai/openai/pull/1024599)
  
  ## Contract
  
  - `recencyAt` initializes when a thread is created.
  - A turn start advances `recencyAt` monotonically.
  - Commentary, agent output, tool results, token/accounting updates, turn
  completion, archive, unarchive, resume, and generic metadata writes do
  not advance it.
  - `updatedAt` retains its existing behavior and continues to advance for
  persisted thread mutations.
  - Current servers populate `recencyAt`; the response field is optional
  in generated TypeScript so clients connected to older servers can fall
  back to `updatedAt`.
  - Filesystem-only fallback uses existing updated/mtime ordering when
  SQLite is unavailable.
  
  ## Persistence and compatibility
  
  Migration 0038 adds second- and millisecond-precision recency columns,
  backfills them from the existing updated timestamp, creates list
  indexes, and includes an insert trigger so older binaries writing to a
  migrated database seed recency without causing later mutations to
  advance it.
  
  Generic metadata upserts preserve existing recency values. Turn-start
  updates use a dedicated monotonic touch, and process-local allocation
  keeps millisecond cursor values unique. State DB list, search, read,
  filtered-list repair, rollout fallback propagation, and app-server
  conversions all carry the new field.
  
  ## API
  
  `Thread` responses include:
  
  ```ts
  recencyAt?: number
  ```
  
  `thread/list` and `thread/search` accept:
  
  ```json
  { "sortKey": "recency_at" }
  ```
  
  Generated TypeScript and JSON schemas are included.
  
  ## Validation
  
  - `just test -p codex-state` — 146 passed
  - `just test -p codex-rollout` — 69 passed
  - `just test -p codex-thread-store` — 81 passed
  - `just test -p codex-app-server-protocol` — 231 passed
  - Focused app-server list ordering, response mapping, archive/unarchive,
  and resume lifecycle tests passed
  - Scoped `just fix` for state, rollout, thread-store,
  app-server-protocol, and app-server
  - `just fmt`
  - `git diff --check`
  - Independent correctness, simplicity, elegance, security, and
  test-quality reviews; actionable ordering, lifecycle, query-projection,
  and timestamp-uniqueness findings were addressed

  Jeremy Rose · 2026-06-16 17:06:22 -07:00
  fac3158c2a
• [codex] [3/4] Activate endpoint plugin recommendations (#27704)

  Summary\n- Await endpoint recommendation selection while constructing
  each authenticated turn, removing the first-turn cache race.\n- Snapshot
  and filter endpoint candidates once per turn, then use that same set for
  the bounded contextual user fragment, tool exposure, and exact install
  validation.\n- Keep recommendation selection ephemeral: do not persist
  recommendation state in or gate resumed threads on prior context.\n-
  Hide the legacy list tool in endpoint mode and preserve legacy discovery
  unchanged when the endpoint is disabled or unavailable.\n- Keep remote
  plugin and connector app identities out of model-visible context and
  attach them only to Codex-owned elicitation metadata.\n\nStack\n- 3/4,
  based on #28400.\n- Endpoint client and cache: #28399.\n- Generalized
  suggestion presentation: #28400.\n- Install-schema follow-up:
  #28403.\n\nValidation\n- \n- \n- \n- \n- Full : 2,649 passed and 88
  environment-dependent tests failed because this sandbox cannot write ,
  nest Seatbelt, or locate auxiliary test binaries.

  Alex Daley · 2026-06-16 23:04:07 +00:00
  a34da3b295
• app-server: preserve target-native environment cwd (#28146)

  ## Why
  
  app-server may run on a different OS from the selected exec-server
  environment. Parsing that environment’s cwd with the Codex host’s path
  rules prevents thread startup.
  
  ## What
  
  Carry environment cwd values as `LegacyAppPathString` at the app-server
  boundary and `PathUri` internally. Existing tool-call schemas and
  relative-path behavior stay host-native; remaining local-only consumers
  convert explicitly and leave follow-up TODOs.
  
  The Wine integration test verifies app-server can start a thread and
  complete an ordinary turn with a Windows environment cwd from Linux.
  
  ## Validation
  
  - `bazel test //codex-rs/core/tests/remote_env_windows:smoke-test
  --test_output=errors`
  - focused app-server environment-selection and protocol schema tests
  - scoped Clippy for `codex-core` and `codex-app-server-protocol`

  Adam Perry @ OpenAI · 2026-06-16 21:42:28 +00:00
  f8850cab1d
• [codex] exec-server: stream files in chunks (#28354)

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

  pakrym-oai · 2026-06-16 09:50:55 -07:00
  a4711b88dd
• [codex] expose Bedrock credential source in account/read (#27751)

  ## Why
  
  `account/read` currently reports only `type: "amazonBedrock"`, so
  clients cannot distinguish a Codex-managed Bedrock API key from
  credentials supplied by AWS. The app UI needs that distinction to render
  the appropriate account state without duplicating provider-auth logic.
  
  Credential-source selection belongs to the Bedrock model provider
  because it already owns the precedence between managed Bedrock auth and
  the external AWS credential path. This builds on #27443 and #27689.
  
  ## What changed
  
  - Added `AmazonBedrockCredentialSource` with `codexManaged` and
  `awsManaged` values.
  - Included the selected credential source in
  `ProviderAccount::AmazonBedrock` and the app-server `Account` response.
  - Made `AmazonBedrockModelProvider::account_state()` classify the source
  from its managed-auth state.
  - Regenerated the app-server JSON and TypeScript schemas.
  - Updated app-server account documentation and downstream TUI matches.
  
  `codexManaged` means the provider found a managed Bedrock API key.
  `awsManaged` identifies the provider's external AWS credential path; it
  does not assert that the AWS credential chain has been validated.
  
  ## Testing
  
  - Added model-provider coverage for Codex-managed precedence and
  AWS-managed fallback.
  - Added app-server protocol serialization coverage for both wire values.
  - Added app-server integration coverage for both `account/read`
  responses.
  - `just test -p codex-protocol -p codex-model-provider -p
  codex-app-server-protocol` (497 tests passed).
  
  After rebasing onto #27711, the `codex-app-server` test target compiled
  past the image-generation `PathUri` migration. Local linking was then
  interrupted by disk exhaustion (`No space left on device`).

  Celia Chen · 2026-06-16 07:14:53 +00:00
  12aaeb7bf8
• [codex] Record external agent import results (#28396)

  ## Summary
  - restore `externalAgentConfig/import/progress` notifications while
  keeping `externalAgentConfig/import/completed` as the must-deliver event
  - persist completed external-agent config imports in state DB by
  `importId`, including concrete success/failure details for config,
  AGENTS.md, skills, plugins, MCP servers, subagents, hooks, commands, and
  sessions
  - add `externalAgentConfig/import/readHistories` so clients can recover
  persisted import results after missing the live completion notification
  - include `errorType` on import failures in protocol
  responses/notifications and persisted DB JSON so future code can
  classify failures without another wire/storage shape change
  
  ## Validation
  - `git diff --check`
  - `just test -p codex-state external_agent_config_imports`
  - `just test -p codex-app-server-protocol`
  - `CODEX_SQLITE_HOME=/private/tmp/codex-app-server-sqlite-read-details
  just test -p codex-app-server
  external_agent_config_import_sends_completion_notification_for_sync_only_import`
  
  Also ran earlier broader checks before publishing:
  - `just test -p codex-state`
  -
  `CODEX_SQLITE_HOME=/private/tmp/codex-app-server-external-agent-test-sqlite
  just test -p codex-app-server external_agent_config`
  - `just test -p codex-external-agent-migration`

  charlesgong-openai · 2026-06-15 23:17:24 -07:00
  314fa3d25b
• [codex] Use expect in integration tests (#28441)

  The workspace denies `clippy::expect_used` in production. Although
  `clippy.toml` allows `expect` in tests, Bazel Clippy compiles
  integration-test helper code in a way that does not receive that
  exemption, which encouraged verbose `unwrap_or_else(... panic!(...))`
  and equivalent `match`/`let else` forms.
  
  This allows `clippy::expect_used` once at each integration-test crate
  root (including aggregated suites and test-support libraries), then
  replaces manual panic-based Result and Option unwraps with
  `expect`/`expect_err`. Standalone `tests/*.rs` files remain their own
  crate roots. Intentional assertion and unexpected-variant panics remain
  unchanged, and the production `expect_used = "deny"` lint remains in
  place.
  
  The cleanup is mechanical and net-negative in line count.

  pakrym-oai · 2026-06-15 21:53:47 -07:00
  e752f7b4ae
• [codex] Add interruptible sleep tool (#28429)

  ## Why
  
  Models sometimes need to pause briefly while waiting for external work,
  but using a shell command for that delay ties the wait to a process and
  does not naturally resume when new turn input arrives.
  
  ## What changed
  
  - add a built-in `sleep` tool behind the under-development `sleep_tool`
  feature
  - accept a bounded `duration_ms` argument, matching the millisecond
  convention used by unified exec
  - end the sleep early when either steered user input or mailbox input
  arrives
  - include elapsed wall-clock time in completed and interrupted outputs
  - emit a dedicated core `SleepItem` through `item/started` and
  `item/completed`
  - expose the sleep item as app-server v2 `ThreadItem::Sleep` and retain
  it in reconstructed thread history
  - regenerate the configuration schema for the new feature flag
  - regenerate app-server JSON and TypeScript schema fixtures
  
  ## Test plan
  
  - `just test -p codex-core sleep_tool_follows_feature_gate`
  - `just test -p codex-core any_new_input_interrupts_sleep`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  sleep_emits_started_and_completed_items`

  pakrym-oai · 2026-06-15 21:39:21 -07:00
  08901fc8e1
• [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
• 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
• 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] 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
• [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
• 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
• 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
• 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
• [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
• 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
• skills: hide orchestrator skills with a local executor (#28333)

  ## Why
  
  App-server threads without a local executor need orchestrator-owned
  skills from the hosted `codex_apps` MCP server. Threads with the local
  executor already discover installed skills from the local filesystem.
  
  After the orchestrator skill provider was enabled for every app-server
  thread, local-executor threads also received the hosted skill catalog
  and the `skills.list` and `skills.read` tools. This changed the existing
  local behavior and could expose a second hosted copy of a skill that was
  already installed locally.
  
  ## What changed
  
  - Expose the thread's selected execution environments to extensions at
  thread startup.
  - Enable orchestrator skills only when the reserved local environment is
  not selected.
  - Apply that decision consistently to hosted skill catalog discovery,
  explicit skill injection, and the `skills.list` and `skills.read` tools.
  
  ## Verification
  
  - The existing no-executor app-server test continues to verify hosted
  skill discovery, invocation, and child-resource reads.
  - A new app-server test verifies that local-executor threads do not
  receive hosted skill context or `skills.*` tools.

  jif · 2026-06-15 17:15:45 +02:00
  6d9df687a5
• Represent dynamic tools with explicit namespaces internally (#27365)

  Follow-up to #27356.
  
  ## Stack note
  
  This PR changes Codex's internal dynamic-tool shape while leaving
  `thread/start` unchanged. App-server therefore converts the existing
  per-tool input into explicit functions and namespaces before passing it
  to core.
  
  [#27371](https://github.com/openai/codex/pull/27371) updates
  `thread/start` to use the same explicit shape and removes this temporary
  conversion.
  
  ## Why
  
  Dynamic tools repeat namespace metadata on every function. Core should
  keep one explicit namespace with its member tools so descriptions and
  membership stay consistent across sessions and runtime planning.
  
  ## What changed
  
  - Represent dynamic tools as top-level functions or explicit namespaces
  in protocol and session state.
  - Read old flat rollout metadata and write the canonical hierarchy.
  - Flatten namespace members only when registering callable tools.
  - Keep `thread/start.dynamicTools` flat for now and normalize it at the
  app-server boundary.
  
  New builds can read old rollout metadata. Older builds cannot read newly
  written hierarchical metadata.
  
  ## Test plan
  
  - `just test -p codex-app-server
  thread_start_normalizes_legacy_dynamic_tools_into_model_request`
  - `just test -p codex-protocol
  session_meta_normalizes_legacy_dynamic_tools`
  - `just test -p codex-core
  resume_restores_dynamic_tools_from_rollout_with_sqlite_enabled`
  - `just test -p codex-core
  tool_search_returns_deferred_dynamic_tool_and_routes_follow_up_call`
  - `just test -p codex-core code_mode_can_call_hidden_dynamic_tools`
  - `just test -p codex-tools`

  sayan-oai · 2026-06-15 08:06:14 -07:00
  a292faae5a
• Activate selected executor plugin MCPs in app-server (#27893)

  ## Why
  
  #27870 teaches the MCP extension how to discover stdio MCP servers
  declared by a selected executor plugin, but app-server does not yet
  install that contributor or initialize its per-thread state. As a
  result, `thread/start.selectedCapabilityRoots` can select the plugin
  while its MCP servers remain inactive.
  
  This PR closes that app-server wiring gap:
  
  ```text
  thread/start(selectedCapabilityRoots)
      -> initialize the thread's selected-plugin MCP snapshot
      -> read the selected plugin's .mcp.json through its environment
      -> start declared stdio servers in that environment
      -> expose their tools only on the selected thread
  ```
  
  ## What changed
  
  - Install the selected-executor-plugin MCP contributor in app-server
  using the existing shared `EnvironmentManager`.
  - Initialize its frozen thread snapshot when `thread/start` includes
  selected capability roots.
  - Document that selected plugin stdio MCPs are activated in their owning
  environment.
  - Add an app-server E2E covering the complete selection-to-tool-call
  path.
  
  The E2E verifies that:
  
  - the selected MCP process receives an executor-only environment value,
  proving the tool runs through the selected environment;
  - the MCP tool is advertised to the model and can be called;
  - a normal MCP config reload does not discard the thread's frozen
  selected-plugin registration;
  - another thread without the selected root does not see the MCP server.
  
  ## Scope
  
  - Existing sessions without `selectedCapabilityRoots` are unchanged.
  - Only stdio MCP declarations are activated. HTTP declarations remain
  inactive.
  - This does not change selected-root persistence across resume/fork or
  add hosted-plugin behavior.
  
  ## Verification
  
  - Focused app-server E2E:
  `selected_executor_plugin_exposes_its_stdio_mcp_only_to_that_thread`
  
  ## Stack
  
  Stacked on #27870.

  jif · 2026-06-15 16:23:37 +02:00
  c8c78b63a7
• [codex] Skip plugin MCP OAuth for matching app routes (#27461)

  ## Context
  
  This is PR5 in the plugin auth-routing stack. Earlier PRs make plugin
  surface projection auth-aware, narrow App/MCP conflicts by App
  declaration name, and keep connector listings auth-aware. This PR
  applies the same name-based App/MCP conflict rule into plugin MCP
  loading, so install-time MCP OAuth and plugin detail metadata both
  reflect the MCPs available for the current auth route.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - Make `load_plugin_mcp_servers` auth-aware and let it load App
  declarations before filtering same-name MCP servers for Codex-backend
  auth.
  - Use that filtered MCP list for both install-time MCP OAuth and
  marketplace plugin detail metadata.
  - Preserve API-key/direct auth behavior so plugin MCP servers remain
  visible and can still start OAuth.
  
  ## Validation
  
  ```bash
  cargo fmt --all
  cargo test -p codex-core-plugins read_plugin_for_config_filters_mcp_servers_for_codex_backend_auth
  cargo check -p codex-core-plugins -p codex-app-server
  git diff --check
  git diff --cached --check
  ```

  felixxia-oai · 2026-06-15 14:04:01 +01:00
  e5253b97fb
• [codex] Preserve plugin apps in connector listings (#27602)

  ## Context
  
  This is PR4 in the plugin auth-routing stack. The earlier PRs make
  plugin surface projection auth-aware and narrow App/MCP conflicts by App
  declaration name. This PR keeps connector listing paths aligned with
  that projected plugin App set.
  
  This means ChatGPT/SIWC users will still see plugin-provided Apps in
  connector listing surfaces like the Apps/connector picker, while API-key
  users will not see Apps they cannot use.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - Have app-server compute effective plugin Apps from the existing
  PluginsManager and pass them into connector listing.
  - Keep plugin Apps visible in Apps/connector listing for ChatGPT/SIWC
  users.
  - Keep API-key-style auth from surfacing plugin Apps in connector
  listings.
  
  ## Validation
  
  ```bash
  cargo test -p codex-chatgpt connectors::tests
  cargo test -p codex-app-server list_apps_includes_plugin_apps_for_chatgpt_auth
  git diff --check
  ```

  felixxia-oai · 2026-06-15 13:50:08 +01:00
  cededa26c5
• feat(app-server): filter threads by parent (#26662)

  ## Why
  
  Clients that display or coordinate spawned subagents need an
  authoritative snapshot of a thread's immediate spawned children when
  they connect to app-server or recover after missing live events.
  `thread/list` cannot query by parent, so clients must otherwise scan
  unrelated threads or reconstruct relationships from rollout history and
  transient events.
  
  The direct spawn relationship already exists in persisted
  `thread_spawn_edges` state. Review and Guardian threads do not
  participate in that lifecycle and are intentionally outside this
  filter's scope.
  
  ## What changed
  
  This adds an experimental `parentThreadId` filter to `thread/list`.
  Parent-filtered requests return direct spawned children from persisted
  state while preserving the existing response shape, explicit filters,
  sorting, and timestamp-only cursor behavior. The lookup does not read
  rollout transcripts or recursively return descendants.
  
  Supersedes #25112 with the narrower `thread/list` filter approach.
  
  ## How it works
  
  1. An experimental client passes a valid thread ID as `parentThreadId`.
  2. App-server routes the list through the existing thread-store and
  state-database boundaries.
  3. SQLite selects threads whose IDs have a direct persisted spawn edge
  from that parent.
  4. Omitted provider and source filters include all values; explicit
  filters keep ordinary `thread/list` semantics.
  5. Grandchildren, Review threads, and Guardian threads are excluded.
  
  ## Verification
  
  State (144 tests), rollout (69 tests), and focused app-server
  thread-list (31 tests) suites passed. Scoped Clippy checks and
  repository formatting also passed. Coverage includes direct spawned
  children, omitted grandchildren, pagination, malformed IDs, mixed source
  kinds, explicit filters, and operation without rollout files.

  Brent Traut · 2026-06-14 00:14:26 -07:00
  dfd03ea01b
• build: run buildifier from just fmt (#28125)

  ## Intent
  
  Keep Bazel and Starlark files consistently formatted without requiring
  contributors to install or version buildifier themselves.
  
  ## Implementation
  
  - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier
  v8.5.1.
  - Run buildifier from the shared `just fmt` and `just fmt-check` driver,
  with Windows-safe explicit DotSlash invocation.
  - Provision DotSlash in formatting CI and contributor devcontainers, and
  document the source-build prerequisite.
  - Apply the initial mechanical buildifier formatting baseline.

  Adam Perry @ OpenAI · 2026-06-13 21:43:39 -07:00
  740c4f269d
• feat(app-server): enforce managed remote control disable (#27961)

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

  Anton Panasenko · 2026-06-12 20:10:12 -07:00
  b9dc3b7a8b
• [codex] add roles to realtime append text (#27936)

  ## Summary
  
  Add an explicit `user` or `developer` role to
  `thread/realtime/appendText` and propagate it through the realtime input
  queue into `conversation.item.create`. Older JSON clients that omit the
  field continue to default to `user`.
  
  This lets app-provided context such as memory retain developer authority
  without bypassing app-server through a renderer-owned data channel. The
  app-server schemas, API documentation, and focused protocol and
  websocket coverage are updated with the new contract.
  
  The Codex Apps consumer is tracked in
  [openai/openai#1025261](https://github.com/openai/openai/pull/1025261).

  Alex Gamble · 2026-06-12 15:05:37 -07:00
  216dee1189
• feat: use encrypted local secrets for CLI auth (#27539)

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

  Celia Chen · 2026-06-12 21:23:50 +00:00
  56c97e3b5c
• Handle standalone image generation failures as terminal items (#27920)

  ## Why
  
  Standalone image generation emitted a started item but no terminal item
  when the backend failed. Clients could leave the operation unresolved or
  render it as successful.
  
  ## What changed
  
  - Emit a terminal image-generation item with `status: "failed"` when
  generation or editing fails.
  - Skip image persistence for failed terminal items.
  - Render failed image generation distinctly in TUI history.
  - Preserve the status when handling live and replayed terminal items.
  
  ## Looks for TUI, App-Side change needed 
  
  <img width="867" height="89" alt="image"
  src="https://github.com/user-attachments/assets/9e32342f-a982-411e-8498-456639fc468a"
  />
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - App-server image-generation tests
  - Core stream-event tests
  - TUI image-generation lifecycle and snapshot tests
  - Scoped Clippy and formatting

  Won Park · 2026-06-12 11:57:22 -07:00
  b6baa77eec
• [codex] expose remote plugin share URL (#27890)

  ## Summary
  
  - expose the remote plugin detail endpoint's `share_url` as nullable
  `PluginDetail.shareUrl`
  - preserve existing `PluginSummary.shareContext` behavior for local and
  workspace sharing flows
  - regenerate the app-server TypeScript and JSON schema fixtures
  
  ## Why
  
  The remote plugin detail response already includes a canonical
  `share_url`, but that value was not surfaced by `plugin/read` for global
  plugins. Global plugins intentionally have no `shareContext`, so using
  that model for the URL would change the semantics consumed by the
  existing share modal.
  
  ## User impact
  
  Codex clients can use `PluginDetail.shareUrl` for a remote plugin's
  copy-link action, including when the plugin is disabled by an
  administrator, without changing existing share-modal or ownership
  behavior.
  
  ## Validation
  
  - `cargo test -p codex-app-server
  plugin_read_includes_share_url_for_admin_disabled_remote_plugin`
  - `cargo test -p codex-app-server-protocol
  typescript_schema_fixtures_match_generated`
  - `cargo test -p codex-app-server-protocol
  json_schema_fixtures_match_generated`
  - `cargo fmt --all`

  Eric Ning · 2026-06-12 11:53:55 -07:00
  9600afb1a1
• realtime: add AVAS architecture override (#27720)

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

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

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

  Alex Zamoshchin · 2026-06-12 09:06:58 -07:00
  3cac2e0d3f
• Add request_user_input auto-resolution window contract (#27256)

  ## Why
  
  `request_user_input` is moving beyond its original plan-mode-only
  workflow, and future default/goal-mode usage needs a way for the model
  to ask helpful but non-blocking questions without forcing the turn to
  wait forever. This PR adds an explicit `autoResolutionMs` contract so a
  later client/runtime change can auto-resolve unanswered prompts after a
  bounded window while leaving truly blocking questions unchanged.
  
  This is contract plumbing only; it does not implement the client-side
  timer or auto-selection behavior, and the model-facing description
  treats the field as reserved unless the current runtime explicitly
  supports auto-resolution.
  
  ## What Changed
  
  - Added optional `autoResolutionMs` to the model-facing
  `request_user_input` args and core `RequestUserInputEvent`.
  - Added model-facing schema text for `autoResolutionMs` while marking it
  reserved for runtimes that explicitly support auto-resolution.
  - Bounds `autoResolutionMs` to `60_000..=240_000` ms during argument
  normalization by clamping out-of-range model-provided values.
  - Propagated the field through app-server v2
  `ToolRequestUserInputParams`, app-server request forwarding, generated
  TypeScript, and JSON schema fixtures.
  - Updated app-server, core, protocol, and TUI call sites/tests so
  omitted values preserve existing `None`/`null` behavior and coverage
  verifies a `Some(60_000)` round trip.
  
  ## Verification
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core request_user_input`
  - `just test -p codex-app-server request_user_input_round_trip`
  - `just test -p codex-tui request_user_input`
  - `just test -p codex-protocol`

  Shijie Rao · 2026-06-11 22:30:41 -07:00
  216ce03031
• feat(app-server): persist remote-control desired state (#27445)

  ## Why
  
  Remote-control runtime enablement and persisted enrollment preference
  were represented by separate flags. That made startup rehydration, RPC
  persistence, and new-enrollment seeding race with one another, and it
  did not cleanly distinguish runtime-only CLI or daemon starts from
  durable app-server RPC changes.
  
  ## What Changed
  
  - Replace the parallel enablement, seed, and rehydration flags with one
  transport-owned `RemoteControlDesiredState`.
  - Add nullable enrollment-scoped persistence and preserve existing
  preferences during enrollment upserts.
  - Rehydrate plain startup only after auth and client scope resolve,
  without overwriting a concurrent RPC transition.
  - Make ordinary `remoteControl/enable` and `remoteControl/disable`
  durable while retaining `ephemeral: true` for runtime-only callers.
  - Have the daemon explicitly request ephemeral enablement and regenerate
  the app-server schemas.
  
  ## Verification
  
  - Covered migration and `NULL`/`0`/`1` persistence round trips.
  - Covered plain-start rehydration and runtime-only versus durable
  enrollment seeding.
  - Covered durable enable, durable disable, and ephemeral enable through
  app-server RPC.
  - Covered the daemon's exact `{ "ephemeral": true }` request payload.
  
  Related issue: N/A (internal remote-control persistence architecture
  change).

  Anton Panasenko · 2026-06-11 21:28:52 -07:00
  d61dfeb23a
• Route image extension reads through turn environments v2 (#27498)

  ## Why
  
  Image generation used `std::fs::read` for referenced image paths, which
  did not support environment-backed filesystems or their sandbox context.
  
  ## What changed
  
  - Expose optional turn environments to extension tool calls.
  - Include each environment’s ID, working directory, filesystem, and
  sandbox context.
  - Read referenced images through the selected environment filesystem.
  - Keep sandbox usage at the extension call site so extensions can choose
  the appropriate access mode.
  - Consolidate image request construction into one async function.
  - Add coverage for successful environment reads and read failures.
  
  ## Validation
  
  - `cargo check -p codex-image-generation-extension --tests`
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  `just test -p codex-image-generation-extension` could not complete
  because the build exhausted available disk space.

  Won Park · 2026-06-11 16:32:52 -07:00
  19ce6394af
• core: Consolidate Responses API Codex metadata (#27122)

  ## What
  Introduce a `CodexResponsesMetadata` struct that defines all the core
  metadata we send to Responses API. Example fields are `thread_id`,
  `turn_id`, `window_id`, etc.
  
  Going forward, `client_metadata["x-codex-turn-metadata"]` will be the
  canonical way Codex sends metadata to Responses API across both HTTP and
  websocket transports.
  
  For now, we continue to emit the existing top-level HTTP headers and
  top-level `client_metadata` fields from the same
  `CodexResponsesMetadata` struct for compatibility reasons.
  
  Also, app-server clients who specify additional
  `responsesapi_client_metadata` via `turn/start` and `turn/steer` will
  have those fields merged into
  `client_metadata["x-codex-turn-metadata"]`, but cannot override the
  reserved fields that core uses (i.e. the fields in
  `CodexResponsesMetadata`).
  
  ## Why
  
  Responses API request instrumentation is the source of truth for
  downstream Codex analytics that join requests by Codex IDs such as
  session, thread, turn, and context window. Before this change, those
  values were assembled through several request-specific paths: HTTP
  request bodies, websocket handshake headers, websocket `response.create`
  payloads, compaction requests, and the rich `x-codex-turn-metadata`
  envelope all had their own wiring.
  
  That made metadata propagation easy to drift across API-key/direct
  Responses API requests, ChatGPT-auth/proxied requests, websocket
  requests, and compaction requests. It also made additions like
  `window_id` error-prone because a field could be added to one transport
  projection but missed in another.
  
  ## What changed
  
  - Added `CodexResponsesMetadata` as the core-owned snapshot for Codex
  metadata sent to ResponsesAPI.
  - Render `client_metadata["x-codex-turn-metadata"]`, flat
  `client_metadata` projections, and direct compatibility headers from
  that same snapshot.
  - Include the known Codex-owned fields in the turn metadata blob,
  including installation/session/thread/turn/window IDs, request kind,
  lineage, sandbox/workspace metadata, timing, and compaction details.
  - Treat app-server `responsesapi_client_metadata` as enrichment for the
  Codex turn metadata blob while preventing those extras from overriding
  Codex-owned fields.
  - Use the same metadata path for normal turns, websocket prewarm, local
  compaction, remote v1 compaction, and remote v2 compaction.
  - Keep websocket connection-only preconnect metadata separate so
  handshakes carry compatibility identity headers without inventing a fake
  turn metadata blob.
  
  ## Verification
  
  - `cargo check -p codex-core`
  - `just fix -p codex-core`

  Owen Lin · 2026-06-11 13:42:09 -07:00
  14df0e8833
• [codex] Load user instructions through an injected provider (#27101)

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

  Adam Perry @ OpenAI · 2026-06-11 19:28:47 +00:00
  236b50125d
• feat: disable orchestrator skills for now (#27646)

  Temp disable orchestrator-only skills while waiting for the endpoint to
  be fixed

  jif · 2026-06-11 20:20:26 +02:00
  267232f3af
• [codex] Propagate plugin app categories (#27420)

  ## What
  - Parse optional `.app.json` `category` overrides for plugin apps.
  - Add nullable `category` to `AppSummary` and `AppTemplateSummary` in
  the app-server protocol.
  - Fall back from `branding.category` to the first non-empty
  `app_metadata.categories` value when building app/template summaries.
  - Regenerate schema/type fixtures and update plugin read/install tests.
  
  ## Why
  The plugin details UI needs a normalized per-app category. Some apps
  only provide their default category in metadata, while others need a
  local `.app.json` override.

  charlesgong-openai · 2026-06-11 10:34:41 -07:00
  eb76336f60
• skills: render catalog locators by authority (#27591)

  ## Why
  
  Hosted skills introduced by #27388 use opaque `skill://` resource
  identifiers, but the skills catalog rendered every locator as a `file`
  and told the model that every skill body lived on disk. That can send
  the model toward filesystem tools for a resource that must instead be
  read through its owning authority.
  
  The catalog should describe how each source is accessed without changing
  the underlying discovery or invocation behavior.
  
  ## What changed
  
  - Render host skills as `file`, executor-owned skills as `environment
  resource`, orchestrator-owned skills as `orchestrator resource`, and
  custom-provider skills as `custom resource`.
  - Update the shared no-alias guidance to describe source locators rather
  than assuming every skill is stored on the host filesystem.
  - Direct orchestrator resources through `skills.list` and `skills.read`,
  and explicitly tell the model not to treat `skill://` identifiers as
  filesystem paths.
  - Preserve the existing filesystem and alias behavior for local skills.
  
  ## Scope
  
  This PR changes only model-visible catalog rendering and guidance. It
  does not change skill discovery, selection, prompt injection, provider
  routing, catalog caching or refresh behavior, resource validation, or
  the `skills.*` tool contract.
  
  ## Verification
  
  - Extended skills-extension coverage for host-file and executor-resource
  labels.
  - Extended the no-executor app-server flow to assert
  orchestrator-resource wording and non-filesystem guidance.

  jif · 2026-06-11 13:51:04 +02:00
  4322e01d2b
• test: cover referenced backend skill reads without an executor (#27404)

  ## Why
  
  PR #27388 lets models read child resources referenced by backend plugin
  skills without an executor. The integration fixture should prove that
  real flow: the injected `SKILL.md` advertises a child `skill://`
  resource, and `skills.read` resolves that exact resource through the
  backend provider.
  
  This is stacked on #27388.
  
  ## What changed
  
  - Adds a child-resource link to the backend skill fixture and asserts
  that it reaches model context.
  - Tightens the end-to-end skills test around `skills.list` followed by
  `skills.read` for the referenced resource.
  - Splits the existing app-server `mcpResource/read` coverage into a
  focused test so the generic RPC path remains covered independently.
  
  ## Validation
  
  - Adds app-server integration coverage for both the referenced backend
  skill resource and the generic MCP resource read path.

  jif · 2026-06-11 12:55:58 +02:00
  dd46ef1aac
• skills: expose remote skill resource tools (#27388)

  ## Why
  
  PR #27387 makes backend plugin skills discoverable and invocable without
  an executor, but resources referenced by those skills still sit behind
  the generic MCP resource surface. The model needs a skills-owned API
  that preserves the provider authority and package boundary instead of
  treating remote resources like local files.
  
  This is stacked on #27387.
  
  ## What
  
  - Adds one `skills` namespace with bounded `list` and `read` tools for
  remote skill providers.
  - Revalidates `authority + package` against the live remote catalog on
  every read, then routes the opaque resource ID back through that
  provider.
  - Allows the backend provider to read canonical child `skill://`
  resources while rejecting cross-package, non-canonical, query, fragment,
  and traversal-shaped URIs.
  - Caps each serialized tool result at 8 KB. Lists are paginated; reads
  return an opaque continuation cursor.
  - Marks the JSON output as external context so memory generation can
  apply its normal suppression policy.
  - Deliberately does not add `skills.search`; that waits for a bounded
  plugin-service search contract.
  
  ## Tool contract
  
  Pseudo-Python matching the wire shape:
  
  ```python
  from typing import Literal, NotRequired, TypedDict
  
  
  class RemoteSkillAuthority(TypedDict):
      kind: Literal["remote"]
      id: str  # e.g. "codex_apps"
  
  
  class RemoteSkill(TypedDict):
      authority: RemoteSkillAuthority
      package: str  # opaque provider-owned package ID
      name: str
      description: str
      main_resource: str  # opaque provider-owned SKILL.md ID
  
  
  class SkillsListParams(TypedDict):
      cursor: NotRequired[str]
  
  
  class SkillsListResult(TypedDict):
      skills: list[RemoteSkill]
      next_cursor: str | None
      warnings: list[str]
      truncated: bool
  
  
  class SkillsReadParams(TypedDict):
      authority: RemoteSkillAuthority  # copied from skills.list
      package: str  # copied from skills.list
      resource: str  # provider-owned child resource ID
      cursor: NotRequired[str]  # copy next_cursor to continue
  
  
  class SkillsReadResult(TypedDict):
      resource: str
      contents: str
      next_cursor: str | None
      truncated: bool
  
  
  class Skills:
      def list(self, params: SkillsListParams) -> SkillsListResult: ...
      def read(self, params: SkillsReadParams) -> SkillsReadResult: ...
  ```
  
  There is one namespace for all remote skills, not one tool or MCP server
  per skill. No resource ID is converted into a filesystem path.
  
  ## Backend dependency
  
  `/ps/mcp` must support direct reads of child resources such as
  `skill://plugin_demo/deploy/references/deploy.md`. This PR implements
  and tests the Codex side of that contract; production child reads remain
  dependent on the corresponding plugin-service support. Search remains
  out of scope until that service exposes a bounded search/resource API.
  
  ## Validation
  
  - Added an app-server integration test covering `skills.list` followed
  by `skills.read` with no executor.
  - Ran `just fmt`.
  - Ran `just bazel-lock-update` and `just bazel-lock-check`.
  - Did not run Rust tests or Clippy locally, per request; CI will run
  them.

  jif · 2026-06-11 12:38:04 +02:00
  7b3eb8e4bc
• core: enable remote compaction v2 by default (#27573)

  ## Why
  
  Remote compaction v2 is ready to become the default for providers that
  already support remote compaction. Leaving it behind an
  under-development opt-in keeps eligible sessions on the legacy
  remote-compaction path.
  
  This does not broaden provider eligibility: OpenAI and Azure move to v2,
  while Bedrock and OSS providers retain their existing local-compaction
  behavior.
  
  ## What changed
  
  - Mark `remote_compaction_v2` stable and enable it by default.
  - Make tests that intentionally cover legacy remote compaction
  explicitly disable v2.
  - Update parity coverage so v2 exercises the production default and only
  legacy mode opts out.
  
  ## Verification
  
  - `just test -p codex-core
  auto_compact_runs_after_resume_when_token_usage_is_over_limit
  auto_compact_counts_encrypted_reasoning_before_last_user
  auto_compact_runs_when_reasoning_header_clears_between_turns
  responses_lite_compact_request_uses_lite_transport_contract`

  jif · 2026-06-11 10:07:19 +00:00
  273a4aa4f2
• skills: make backend plugin skills invocable without an executor (#27387)

  ## Why
  
  #27198 made the extension-owned `codex_apps` MCP connection the hosted
  plugin runtime, but its `mcp/skill` resources still bypassed the skills
  extension. App-server could list and read those resources through
  generic MCP APIs, but a thread with no selected environment did not
  expose them in the model's skills catalog or load their `SKILL.md`
  through `$skill`.
  
  Hosted skills should stay remote while using the same typed catalog,
  source authority, deduplication, bounded contextual catalog, and
  selected-skill prompt injection as host and executor skills. They should
  not be downloaded or exposed as ambient filesystem paths.
  
  ## What changed
  
  - Add a session-scoped `McpResourceClient` over the replaceable MCP
  connection manager so resource list/read calls follow startup and
  refresh replacements.
  - Add a `BackendSkillProvider` that pages `codex_apps` resources,
  accepts bounded and validated `mcp/skill` entries, and reads a selected
  skill's `SKILL.md` through the same MCP connection.
  - Register the remote provider in app-server and include it in the
  skills catalog even when a thread has no selected capability roots or
  executor.
  - Contribute hosted skill metadata through the bounded
  `AvailableSkillsInstructions` developer-context path, exclude remote
  entries from per-turn catalog injection, and classify `<skills>`
  messages as contextual developer content so rollback can trim and
  rebuild them correctly.
  
  ## Testing
  
  - Extend the app-server MCP resource integration test with
  `environments: []` to exercise two-page discovery, filter a
  non-`mcp/skill` resource, verify the escaped developer catalog entry and
  user-role `<skill>` fragment containing the fetched `SKILL.md`, and
  preserve generic MCP resource reads.
  - Add core event-mapping coverage that classifies `<skills>` developer
  messages as contextual history.

  jif · 2026-06-11 11:28:16 +02:00
  a287c5dffd
• [codex] Add comp_hash to model metadata (#27532)

  ## Summary
  - add optional `comp_hash` metadata to `ModelInfo`
  - update `ModelInfo` fixtures for the shared schema change
  - keep older model responses compatible by defaulting the field to
  `None`
  
  ## Why
  The models endpoint needs an opaque identifier for compaction-compatible
  model configurations. This PR only exposes that value in model metadata;
  it does not add it to turn context or change runtime behavior.
  
  Follow-up #27520 carries the value through turn context and rollouts,
  then uses it to trigger compaction.
  
  ## Stack
  - based directly on `main`
  - replaces #27519, which was accidentally merged into the wrong base
  branch
  - functionality follow-up: #27520
  
  ## Testing
  - `just test -p codex-protocol
  model_info_defaults_availability_nux_to_none_when_omitted`
  - `just fix -p codex-core -p codex-protocol -p codex-analytics -p
  codex-models-manager`

  Ahmed Ibrahim · 2026-06-10 20:42:55 -07:00
  e614fad02e
• feat: add Bedrock API key as a managed auth mode (#27443)

  ## Why
  
  Codex needs to manage Amazon Bedrock API key credentials through the
  existing auth lifecycle instead of introducing a separate auth manager
  or provider-specific credential file. Treating Bedrock API key login as
  a primary auth mode gives it the same persistence, keyring, reload, and
  logout behavior as the existing OpenAI API key and ChatGPT modes.
  
  The credential is valid only for the `amazon-bedrock` model provider.
  OpenAI-compatible providers must reject this auth mode rather than
  treating the Bedrock key as an OpenAI bearer token.
  
  ## What changed
  
  - Added `bedrockApiKey` as an app-server `AuthMode` and
  `CodexAuth::BedrockApiKey` as a primary `AuthManager` mode.
  - Added `BedrockApiKeyAuth`, containing the API key and AWS region, to
  the existing `AuthDotJson` payload stored in `$CODEX_HOME/auth.json` or
  the configured keyring backend.
  - Added `login_with_bedrock_api_key(...)`, parallel to
  `login_with_api_key(...)`, which replaces the current stored login with
  Bedrock credentials.
  - Reused generic auth reload and logout behavior instead of adding a
  Bedrock-specific auth manager or logout path.
  - Updated login restrictions, status reporting, diagnostics, telemetry
  classification, generated app-server schemas, and auth fixtures for the
  new mode.
  - Added explicit errors when Bedrock API key auth is selected with an
  OpenAI-compatible model provider.
  
  This PR establishes managed storage and auth-mode behavior. Routing the
  managed key and region into Amazon Bedrock requests will be in follow-up
  PRs.

  Celia Chen · 2026-06-10 20:42:38 -07:00
  06afd63f4a
• [codex] Remove redundant plugin app auth state (#27465)

  ## Summary
  
  - remove the redundant `needsAuth` field from `AppSummary` and generated
  app-server schemas
  - stop `plugin/read` from querying Apps MCP solely to hydrate unused
  connector auth state
  - preserve `plugin/install.appsNeedingAuth` membership and
  `app/list.isAccessible` as the authentication signals
  
  ## Why
  
  Codex App and TUI do not consume `plugin/read.plugin.apps[].needsAuth`.
  Hydrating it could establish an Apps MCP connection and discover tools
  on a cold `plugin/read` request, adding avoidable latency. The plugin
  APIs are still marked under development, so removing this wire field is
  preferable to retaining a misleading default.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `just fmt`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  plugin_install_uses_remote_apps_needing_auth_response`
  - `just test -p codex-app-server
  plugin_install_returns_apps_needing_auth`
  - `just test -p codex-app-server
  plugin_read_returns_plugin_details_with_bundle_contents`
  - `just test -p codex-tui
  plugin_detail_popup_snapshot_shows_install_actions_and_capability_summaries`
  - `$xin-build` simplify and debug reviews

  xl-openai · 2026-06-10 17:33:56 -07:00
  1a9efd473b