809 Commits

• feat: guardian as an extension (contributors part) (#22216)

  Part 1 of guardian as extension. This bind all the logic to spawn
  another agent from an extension and it adds `ThreadId` in the start
  thread collaborator

  jif-oai · 2026-05-12 14:41:45 +02:00
  d996f5366f
• feat: Normalize remote plugin summary identities. (#22265)

  Makes plugin summaries use config-style plugin@marketplace IDs while
  exposing backend remote IDs separately as remotePluginId.
  
  Also fix the consistency issue of REMOTE_SHARED_WITH_ME_MARKETPLACE_NAME

  xl-openai · 2026-05-12 00:58:37 -07:00
  5b1a4c2fa7
• Add production startup and TTFT telemetry (#22198)

  ## Why
  
  While investigating `codex exec hi` startup latency, the useful
  questions were not "is startup slow?" but "which durable bucket is slow
  in production?"
  
  The path we observed has a few distinct stages:
  
  1. `thread/start` creates the session
  2. startup prewarm builds the turn context, tools, and prompt
  3. startup prewarm warms the websocket
  4. the first real turn resolves the prewarm
  5. the model produces the first token
  
  Before this PR, production telemetry had some of the raw measurements
  already:
  
  - aggregate startup-prewarm duration / age-at-first-turn metrics
  - TTFT as a metric
  - websocket request telemetry
  
  But there was no coherent production event stream for the startup
  breakdown itself, and TTFT was metric-only. That made it hard to answer
  the same latency questions from OpenTelemetry-backed logs without adding
  one-off local instrumentation.
  
  ## What changed
  
  Add durable production telemetry on the existing `SessionTelemetry`
  path:
  
  - new `codex.startup_phase` OTel log/trace events plus
  `codex.startup.phase.duration_ms`
  - new `codex.turn_ttft` OTel log/trace events while preserving the
  existing TTFT metric
  
  The startup phase event is emitted for the coarse buckets we actually
  observed while running `exec hi`:
  
  - `thread_start_create_thread`
  - `startup_prewarm_total`
  - `startup_prewarm_create_turn_context`
  - `startup_prewarm_build_tools`
  - `startup_prewarm_build_prompt`
  - `startup_prewarm_websocket_warmup`
  - `startup_prewarm_resolve`
  
  These phases are intentionally low-cardinality so they remain safe as
  production telemetry tags.
  
  ## Why this shape
  
  This keeps the instrumentation on the same production path as the rest
  of the session telemetry instead of adding a local debug-only trace
  mode. It also avoids changing startup behavior:
  
  - prewarm still runs
  - no control flow changes
  - no extra remote calls
  - no user-visible behavior changes
  
  One boundary is intentional: very early process bootstrap that happens
  before a session exists is not included here, because this PR uses
  session-scoped production telemetry. The expensive buckets we were
  trying to understand after `thread/start` are now covered durably.
  
  ## Verification
  
  - `cargo test -p codex-otel`
  - `cargo test -p codex-core turn_timing`
  - `cargo test -p codex-core
  regular_turn_emits_turn_started_without_waiting_for_startup_prewarm`
  - `cargo test -p codex-core
  interrupting_regular_turn_waiting_on_startup_prewarm_emits_turn_aborted`
  - `cargo test -p codex-app-server thread_start`
  - `just fix -p codex-otel -p codex-core -p codex-app-server`
  
  I also ran `cargo test -p codex-core`; it built successfully and then
  hit an existing unrelated stack overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.

  Matthew Zeng · 2026-05-11 23:58:36 +00:00
  e15ecc9c35
• Add Windows hook command overrides (#22159)

  # Why
  
  Managed hook configs need a shared cross-platform shape without making
  the existing `command` field polymorphic. The common case is still one
  command string, with Windows needing a different entrypoint only when
  the runtime is actually Windows.
  
  Keeping `command` as the portable/default path and adding an optional
  Windows override keeps the config easier to read, preserves the existing
  scalar shape for non-Windows users, and avoids forcing every caller into
  a `{ unix, windows }` object when only one platform needs special
  handling.
  
  # What
  
  - Add optional `command_windows` / `commandWindows` alongside the
  existing hook `command` field.
  - Resolve `command_windows` only on Windows during hook discovery; other
  platforms continue to use `command` unchanged.
  - Keep trust hashing aligned to the effective command selected for the
  current runtime.
  
  # Docs
  
  The Codex hooks/config reference should document `command_windows` as
  the Windows-only override for command hooks.

  Abhinav · 2026-05-11 22:22:29 +00:00
  9ab7f4e6ac
• [codex-analytics] emit terminal review events (#18748)

  ## Why
  
  Review telemetry should describe reviews as first-class events, not only
  as counters denormalized onto terminal tool-item events. That lets us
  analyze guardian and user reviews consistently across command execution,
  file changes, permissions, and network access, while still preserving
  the terminal item summaries that existing tool analytics need.
  
  To make those review events accurate, analytics also needs the observed
  completion time for each review and enough command metadata to
  distinguish `shell` from `unified_exec` reviews.
  
  ## What changed
  
  - emit generic `codex_review_event` rows for completed user and guardian
  reviews, with review subjects, reviewer, trigger, terminal status,
  resolution, and observed duration
  - reduce approval request / response / abort facts into review events
  for command execution, file change, and permissions flows
  - keep denormalized review counts, final approval outcome, and
  permission-request flags on terminal tool-item events for
  item-associated reviews
  - plumb review completion timing so user-review responses and aborts use
  app-server-observed completion times, while guardian analytics reuse the
  same terminal timestamps emitted on guardian assessment events
  - carry command approval `source` through the protocol and app-server
  layers so review analytics can distinguish `shell` from `unified_exec`
  - add analytics coverage for user-review emission, guardian-review
  emission, permission reviews that should not denormalize onto tool
  items, item-summary isolation across threads, and the serialized
  review-event shape
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18748).
  * __->__ #18748
  * #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-11 22:13:32 +00:00
  a175ddacc0
• fix(app-server): thread history redaction for remote clients (#22178)

  ## Summary
  
  Remote clients can still receive large `thread/resume` histories when
  prior turns include MCP tool call payloads or image-generation results.
  This adds a temporary response-only redaction path for the known remote
  client names.
  
  Longer term we will move towards fully paginated APIs backed by SQLite.
  
  ## Changes
  
  - Redact MCP tool call payload-bearing fields in `thread/resume`
  responses for `codex_chatgpt_android_remote` and
  `codex_chatgpt_ios_remote`.
  - Drop `imageGeneration` items from those `thread/resume` responses.
  - Keep redaction out of persisted rollout files, `thread/read`,
  `thread/turns/list`, live notifications, and token usage replay.
  - Cover the behavior with app-server helper tests and a v2 resume
  integration test that checks both remote clients plus a non-target
  control client.
  
  ## Testing
  
  - `cargo test -p codex-app-server thread_resume_redaction`
  - `cargo test -p codex-app-server
  thread_resume_redacts_payloads_for_chatgpt_remote_clients`

  Owen Lin · 2026-05-11 11:45:25 -07:00
  7bddb3083d
• Unified mentions in TUI (#19068)

  This PR replaces the TUI’s file-only `@mention` popup with a unified
  mentions experience. Typing `@...` now searches across filesystem
  matches, installed plugins, and skills in one popup, with result types
  clearly labeled and selectable from the same flow.
  
  - Adds a unified `@mentions` popup that returns:
    - plugins
    - skills
    - files
    - directories
  
  - Adds search modes so users can narrow the popup without changing their
  query:
    - All Results _(default/same as Codex App)_
    - Filesystem Only
    - Plugins _(...and skills)_
  
  - Preserves existing insertion behavior:
    - selected file paths are inserted into the prompt
    - paths with spaces are quoted
    - image file selections still attach as images when possible
    - selecting a plugin or skill inserts the corresponding `$name`
  - the composer records the canonical mention binding, such as
  `plugin://...` or the skill path
  
  - Expanded `@mentions` rendering:
    - type tags for Plugin, Skill, File, and Dir
    - distinct plugin/filesystem colors
    - stable fixed-height layout (8 rows)
    - truncation behavior for narrow terminals
  
  Note:
  - The unified mentions popup does not display app connectors under
  `@mention` results for Codex App parity. Connector mentions remain
  available through the existing `$mention` path.
  
  
  https://github.com/user-attachments/assets/f93781ed-57d3-4cb5-9972-675bc5f3ef3f

  canvrno-oai · 2026-05-11 11:34:52 -07:00
  eaf05c9002
• Add process-scoped SQLite telemetry (#22154)

  ## Summary
  - add SQLite init, backfill-gate, and fallback telemetry without
  introducing a cross-cutting state-db access wrapper
  - install one process-scoped telemetry sink after OTEL startup and let
  low-level state/rollout paths emit through it directly
  - add process-start metrics for the process owners that initialize
  SQLite
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  jif-oai · 2026-05-11 11:32:40 -07:00
  b401666ca5
• Fix goal update and add /goal edit command in TUI (#21954)

  ## Why
  
  Users have requested the ability to edit a goal's objective after a goal
  has been created. This PR exposes a new `/goal edit` command in the TUI
  to address this request.
  
  In the process of implementing this, I also noticed an existing bug in
  the goal runtime. When a goal's objective is updated through the
  `thread/goal/set` app server API, the goal runtime didn't emit a new
  steering prompt to tell the agent about the new objective. This PR also
  fixes this hole.
  
  ## What Changed
  
  - Adds `/goal edit` in the TUI, opening an edit box prefilled with the
  current goal objective.
  - Keeps active and paused goals in their current state, resets completed
  goals to active, keeps budget-limited goals budget-limited, and
  preserves the existing token budget.
  - Changes the existing `thread/goal/set` behavior so editing an
  objective preserves goal accounting instead of resetting it. The older
  reset-on-new-objective behavior was left over from before
  `thread/goal/clear`; clients that need to reset accounting can now clear
  the existing goal and create a new one.
  - Reuses the existing goal set API path; this does not add or change
  app-server protocol surface area.
  - Adds a dedicated goal runtime steering prompt when an externally
  persisted goal mutation changes the objective, so active turns receive
  the updated objective.
  
  ## Validation
  
  - Make sure `/goal edit` returns an error if no goal currently exists
  - Make sure `/goal edit` displays an edit box that can be optionally
  canceled with no side effects
  - Make sure that an edited goal results in a steer so the agent starts
  pursuing the new objective
  - Make sure the new objective is reflected in the goal if you use
  `/goal` to display the goal summary
  - Make sure that `/goal edit` doesn't reset the token budget, time/token
  accounting on the updated goal

  Eric Traut · 2026-05-11 10:49:19 -07:00
  1e65b3e0af
• chore: drop built-in MCPs (#22173)

  Drop something that was never used

  jif-oai · 2026-05-11 19:45:08 +02:00
  32b1ae7099
• app-server: remove TCP websocket listener (#21843)

  ## Why
  
  The app-server no longer needs to expose a TCP websocket listener.
  Keeping that transport also kept around a separate listener/auth surface
  that is unnecessary now that local clients can use stdio or the
  Unix-domain control socket, while remote connectivity is handled by
  `remote_control`.
  
  ## What Changed
  
  - Removed `ws://IP:PORT` parsing and the `AppServerTransport::WebSocket`
  startup path.
  - Deleted the app-server websocket listener auth module and removed
  related CLI flags/dependencies.
  - Kept websocket framing only where it is still needed: over the
  Unix-domain control socket and in the outbound `remote_control`
  connection.
  - Updated app-server CLI/help text and `app-server/README.md` to
  document only `stdio://`, `unix://`, `unix://PATH`, and `off` for local
  transports.
  - Converted affected app-server integration coverage from TCP websocket
  listeners to UDS-backed websocket connections, and added a parse test
  that rejects `ws://` listen URLs.
  - Removed the now-unused workspace `constant_time_eq` dependency and
  refreshed `Cargo.lock` after `cargo shear` caught the drift.
  - Moved test app-server UDS socket paths to short Unix temp paths so
  macOS Bazel test sandboxes do not exceed Unix socket path limits.
  
  ## Verification
  
  - Added/updated tests around UDS websocket transport behavior and
  `ws://` listen URL rejection.
  - `cargo shear`
  - `cargo metadata --no-deps --format-version 1`
  - `cargo test -p codex-app-server unix_socket_transport`
  - `cargo test -p codex-app-server unix_socket_disconnect`
  - `just fix -p codex-app-server`
  - `git diff --check`
  
  Local full Rust test execution was blocked before compilation by an
  external fetch failure for the pinned `nornagon/crossterm` git
  dependency. `just bazel-lock-update` and `just bazel-lock-check` were
  retried after the manifest cleanup but remain blocked by external
  BuildBuddy/V8 fetch timeouts.

  Ruslan Nigmatullin · 2026-05-11 10:17:26 -07:00
  a124ddb854
• Use goal preview metadata for goal-first threads (#21981)

  Fixes #20792
  
  ## Why
  
  `/goal`-first threads are valid resumable threads, but they can be
  missing from `codex resume` and app recents because discovery depends on
  metadata derived from a normal first user message.
  
  PR #21489 attempted to fix this by using the goal objective as
  `first_user_message`. Review feedback pointed out that
  `first_user_message` does more than provide visible text today: it gates
  listing, supplies preview text, and participates in deciding whether a
  later title should surface as a distinct thread name. Reusing it for the
  goal objective could leave a `/goal`-first thread with
  `first_user_message=<goal>` and `title=<later prompt>`, even though the
  goal should only provide the initial visible preview.
  
  This PR follows that feedback by and keeps the `first_user_message` as
  is but introduces a new `preview` field to separate concerns. The
  `preview` field is populated from the first user message or the goal
  objective. We can extend it in the future to include other sources.
  
  ## What Changed
  
  - Added internal thread `preview` metadata in `codex-state`, including a
  SQLite migration that backfills from `first_user_message` and from
  existing `thread_goals` objectives when needed.
  - Treated `ThreadGoalUpdated` as preview-bearing metadata so goal-first
  threads can be listed and searched without mutating
  `first_user_message`.
  - Updated rollout listing, state queries, thread-store conversion, and
  app-server mapping to use preview metadata while continuing to expose
  the existing public `preview` field.
  - Preserved title/name distinctness behavior around literal
  `first_user_message`, so a later normal prompt after `/goal` does not
  surface as a separate name just because the goal supplied the initial
  preview.
  - Preserved compatibility for older/internal metadata writes by deriving
  preview from `first_user_message` when explicit preview metadata is
  absent.
  
  ## Verification
  
  - Manually verified that a thread that starts with a `/goal <objective>`
  shows up in the resume picker.

  Eric Traut · 2026-05-11 10:12:46 -07:00
  f10ddc3f13
• feat: drop CodexExtension (#22140)

  Drop `CodexExtension` as not needed for now

  jif-oai · 2026-05-11 14:19:51 +02:00
  ebd3d53451
• extension: move git attribution into an extension (#21738)

  ## Why
  
  Git commit attribution is prompt policy, not session orchestration.
  After #21737 adds the extension-registry seam, this moves that
  prompt-only behavior out of `codex-core` so `Session` can consume
  extension-contributed prompt fragments instead of owning a one-off
  policy path itself.
  
  Before this PR, `Session` injected the trailer instruction directly from
  `codex-core` ([session
  assembly](https://github.com/openai/codex/blob/a57a747eb667753118217b8bb47dfd1fff88cbde/codex-rs/core/src/session/mod.rs#L2733-L2739),
  [helper
  module](https://github.com/openai/codex/blob/a57a747eb667753118217b8bb47dfd1fff88cbde/codex-rs/core/src/commit_attribution.rs#L1-L33)).
  This branch moves that same responsibility into
  [`codex-git-attribution`](https://github.com/openai/codex/blob/b5029a67360fe5c948aa849d4cf65fd2597ebaae/codex-rs/ext/git-attribution/src/lib.rs#L14-L100).
  
  ## What changed
  
  - Added the `codex-git-attribution` extension crate.
  - Snapshot `CodexGitCommit` plus `commit_attribution` at thread start,
  then contribute the developer-policy fragment through the extension
  registry.
  - Register the extension in app-server thread extensions.
  - Remove the old `codex-core` helper module and direct `Session`
  injection path.
  
  This keeps the existing behavior intact: the prompt is only contributed
  when `CodexGitCommit` is enabled, blank attribution still disables the
  trailer, and the default remains `Codex <noreply@openai.com>`.
  
  ## Stack
  
  - Stacked on #21737.

  jif-oai · 2026-05-11 12:53:15 +02:00
  569ff6a1c4
• extension: wire extension registries into sessions (#21737)

  ## Why
  
  [#21736](https://github.com/openai/codex/pull/21736) introduces the
  typed extension API, but the runtime does not yet carry a registry
  through thread/session startup or give contributors host-owned stores to
  read from. This PR wires that host-side path so later feature migrations
  can move product-specific behavior behind typed contributions without
  adding another bespoke seam directly to `codex-core`.
  
  ## What changed
  
  - Thread `ExtensionRegistry<Config>` through `ThreadManager`,
  `CodexSpawnArgs`, `Session`, and sub-agent spawn paths.
  - Wire `ThreadStartContributor` and `ContextContributor`
  - Expose the small supporting surface needed by non-core callers that
  construct threads directly, including `empty_extension_registry()`
  through `codex-core-api`.
  
  This PR lands the host plumbing only: the app-server registry is still
  empty, and concrete feature migrations are intended to follow
  separately.

  jif-oai · 2026-05-11 11:38:18 +02:00
  436c0df658
• feat: Add role-aware plugin share context APIs (#21867)

  Expose discoverability and full share principals in share context, carry
  roles through save/updateTargets, hydrate local shared plugin reads, and
  keep share URLs only under plugin.shareContext.

  xl-openai · 2026-05-08 20:46:39 -07:00
  479491ed89
• Move file watcher out of core (#21290)

  ## Why
  
  The app-server watcher relocation leaves the generic filesystem watcher
  as the last watcher-specific implementation still living inside
  `codex-core`. Moving that code to a small crate keeps `codex-core`
  focused on thread execution and lets app-server depend on the watcher
  without reaching back into core for filesystem watching primitives.
  
  This PR is stacked on #21287.
  
  ## What changed
  
  - Added a new `codex-file-watcher` crate containing the existing watcher
  implementation and its unit tests.
  - Updated app-server `fs_watch`, `skills_watcher`, and listener state to
  import watcher types from `codex-file-watcher`.
  - Removed the `file_watcher` module and `notify` dependency from
  `codex-core`.
  - Updated Cargo workspace metadata and `Cargo.lock` for the new internal
  crate.
  
  ## Validation
  
  - `cargo check -p codex-file-watcher -p codex-core -p codex-app-server`
  - `cargo test -p codex-file-watcher`
  - `cargo test -p codex-app-server
  skills_changed_notification_is_emitted_after_skill_change`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-file-watcher`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  pakrym-oai · 2026-05-08 18:19:23 -07:00
  c579da41b1
• Reapply "Move skills watcher to app-server" (#21652)

  ## Why
  
  PR #21460 reverted the earlier move of skills change watching from
  `codex-core` into app-server. This reapplies that boundary change so
  app-server owns client-facing `skills/changed` notifications and core no
  longer carries the watcher.
  
  ## What
  
  - Restore the app-server `SkillsWatcher` and register it from thread
  listener setup.
  - Remove the core-owned skills watcher and its core live-reload
  integration surface.
  - Restore app-server coverage for `skills/changed` notifications after a
  watched skill file changes.
  
  ## Validation
  
  - `cargo test -p codex-app-server --test all
  suite::v2::skills_list::skills_changed_notification_is_emitted_after_skill_change
  -- --exact --nocapture`
  - `cargo test -p codex-core --lib --no-run`

  pakrym-oai · 2026-05-08 17:41:15 -07:00
  408e6218ab
• [codex] support executor registry remote environments (#21323)

  ## Summary
  
  Support registry-backed remote executors end to end so downstream
  services can resolve an executor id into an exec-server URL and make
  that environment available to Codex without relying on the legacy cloud
  environments flow.
  
  ## What changed
  
  - switch remote executor registration to the executor registry bootstrap
  contract
  - allow named remote environments to be inserted into
  `EnvironmentManager` at runtime
  - add the experimental app-server RPC `environment/add` so initialized
  experimental clients can register those remote environments for later
  `thread/start` and `turn/start` selection
  
  ## Validation
  
  Ran focused validation locally:
  - `cargo test -p codex-exec-server environment_manager_`
  - `cargo test -p codex-exec-server
  register_executor_posts_with_bearer_token_header`
  - `cargo test -p codex-app-server-protocol`

  Michael Zeng · 2026-05-08 16:30:07 -07:00
  8f4020846e
• app-server: support daemon-safe restart handling (#21831)

  ## Why
  
  The app-server daemon work needs two app-server behaviors to be safe
  when lifecycle management is driven by a helper process:
  
  - a readiness probe must not become the process-wide client identity
  just because it connects first
  - a graceful reload signal needs to keep draining active turns even if
  it is delivered more than once
  
  ## What changed
  
  - Treat `codex_app_server_daemon` initialization as a probe-only client
  for process-global originator and user-agent suffix state.
  - Distinguish forceable shutdown signals from graceful-only ones, and
  treat Unix `SIGHUP` as graceful-only while leaving `SIGTERM` and Ctrl-C
  forceable.
  - Add regression coverage for daemon probe initialization and repeated
  `SIGHUP` delivery while a turn is still running.
  
  ## Testing
  
  - `cargo test -p codex-app-server`
    - The new daemon-probe and repeated-`SIGHUP` coverage passed.
  - The run still failed in the existing
  `suite::conversation_summary::get_conversation_summary_by_relative_rollout_path_resolves_from_codex_home`
  and
  `suite::conversation_summary::get_conversation_summary_by_thread_id_reads_rollout`
  tests because their initialize handshake timed out.
  - `cargo test -p codex-app-server --test all
  suite::conversation_summary::`
  - Reproduced the same two existing initialize-timeout failures in
  isolation.

  Ruslan Nigmatullin · 2026-05-08 15:47:51 -07:00
  1b86906fa1
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343
• Load configured environments from CODEX_HOME (#20667)

  ## Why
  
  The earlier PRs add stdio transport support and the config-backed
  environment provider, but the feature remains inert until normal Codex
  entrypoints construct `EnvironmentManager` with enough context to
  discover `CODEX_HOME/environments.toml`. This final stack PR activates
  the provider while preserving the legacy `CODEX_EXEC_SERVER_URL`
  fallback when no environments file exists.
  
  **Stack position:** this is PR 5 of 5. It is the product wiring PR that
  activates the configured environment provider added in PR 4.
  
  ## What Changed
  
  - Thread `codex_home` into `EnvironmentManagerArgs`.
  - Change `EnvironmentManager::new(...)` to load the provider from
  `CODEX_HOME`.
  - Preserve legacy behavior by falling back to
  `DefaultEnvironmentProvider::from_env()` when `environments.toml` is
  absent.
  - Make `environments.toml`-backed managers start new threads with all
  configured environments, default first, while keeping the legacy env-var
  path single-default.
  - Update the app-server, TUI, exec, MCP server, connector, prompt-debug,
  and thread-manager-sample callsites to pass `codex_home` and handle
  provider-loading errors.
  
  ## Self-Review Notes
  
  - The multi-environment startup path is intentionally tied to the
  `environments.toml` provider. Using `>1` configured environment as the
  only signal would also expand the legacy `CODEX_EXEC_SERVER_URL`
  provider because it keeps `local` addressable alongside `remote`.
  - The startup environment list is still derived inside
  `EnvironmentManager`; the provider only says whether its snapshot should
  start new threads with all configured environments.
  - The thread-manager sample was updated to pass the current
  `ThreadManager::new(...)` installation id argument so the stack compiles
  under Bazel.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - **5. This PR:** https://github.com/openai/codex/pull/20667 - Load
  configured environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `bazel build --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/thread-manager-sample:codex-thread-manager-sample`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/exec-server:exec-server-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=default_thread_environment_selections_use_manager_default_id
  //codex-rs/core:core-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=start_thread_uses_all_default_environments_from_codex_home
  //codex-rs/core:core-unit-tests`
  
  ## Documentation
  
  This activates `CODEX_HOME/environments.toml`; user-facing documentation
  should be added before this stack is treated as a documented public
  workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 11:17:56 -07:00
  5f2543b74e
• feat: Use installation ID in remote enrollments (#21662)

  * Pass installation ID for storage on enrollments server for
  deduping/grouping multiple appservers per installation
  * Pass installation ID in remoteControl/status/changed events

  David de Regt · 2026-05-08 17:54:01 +00:00
  872b8b15b3
• feat: Update plugin share settings with discoverability (#21637)

  Requires discoverability on plugin/share/updateTargets so the server can
  manage workspace link access consistently, including auto-adding the
  workspace principal for UNLISTED.
  
  Also rejects LISTED on share creation and blocks client-supplied
  workspace principals while preserving response parsing for LISTED.

  xl-openai · 2026-05-07 21:28:18 -07:00
  ae15343243
• Remove skills list extra roots (#21485)

  ## Summary
  - Remove `perCwdExtraUserRoots` / `SkillsListExtraRootsForCwd` from the
  `skills/list` app-server API.
  - Drop Rust app-server and `codex-core-skills` extra-root plumbing so
  skill scans are keyed by the normal cwd/user/plugin roots only.
  - Regenerate app-server schemas and update docs/tests that only existed
  for the removed extra-roots behavior.
  
  ## Validation
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-skills`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core-skills`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`
  
  ## Notes
  - `cargo test -p codex-app-server --test all skills_list` ran the edited
  skills-list cases, but the full filtered run ended on existing
  `skills_changed_notification_is_emitted_after_skill_change` timeout
  after a websocket `401`.
  - `cargo test -p codex-tui --lib` compiled the changed TUI callers, then
  failed two unrelated status permission tests because local
  `/etc/codex/requirements.toml` forbids `DangerFullAccess`.
  - Source-truth check found the OpenAI monorepo still has
  generated/app-server-kit mirror references to the removed field; those
  should be cleaned up when generated app-server types are synced or in a
  companion OpenAI cleanup.

  xli-oai · 2026-05-07 20:56:42 -07:00
  314229fd72
• [codex-analytics] plumb protocol-native review timing (#21434)

  ## Why
  
  We want terminal tool review analytics, but the reducer should not stamp
  review timing from its own wall clock.
  
  This PR plumbs review timing through the real protocol and app-server
  seams so downstream analytics can consume the emitter's timestamps
  directly. Guardian reviews keep their enriched `started_at` /
  `completed_at` analytics fields by deriving those legacy second-based
  values from the same protocol-native millisecond lifecycle timestamps,
  rather than sampling a separate analytics clock.
  
  ## What changed
  
  - add `started_at_ms` to user approval request payloads
  - add `started_at_ms` / `completed_at_ms` to guardian review
  notifications
  - preserve Guardian review `started_at` / `completed_at` enrichment from
  the protocol-native timing source
  - stamp typed `ServerResponse` analytics facts with app-server-observed
  `completed_at_ms`
  - thread the new timing fields through core, protocol, app-server, TUI,
  and analytics fixtures
  
  ## Verification
  
  - `cargo test -p codex-app-server outgoing_message --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-app-server-protocol guardian --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-tui guardian --manifest-path codex-rs/Cargo.toml`
  - `cargo test -p codex-analytics analytics_client_tests --manifest-path
  codex-rs/Cargo.toml`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21434).
  * #18748
  * __->__ #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-07 20:31:41 -07:00
  99016ec732
• feat(app-server, threadstore): Thread pagination APIs and ThreadStore contract (#21566)

  ## Why
  The goal of this PR is to align on app-server and `ThreadStore` API
  updates for paginating through large threads.
  
  
  #### app-server
  ##### `thread/turns/list`
  - Updates `thread/turns/list` to support `itemsView?: "notLoaded" |
  "summary" | "full" | null`, defaulting to `summary`.
  - Implements the current `thread/turns/list` behavior over the existing
  persisted rollout-history fallback:
    - `notLoaded` returns turn envelopes with empty `items`.
  - `summary` returns the first user message and final assistant message
  when available.
    - `full` preserves the existing full item behavior.
  
  Note that this method still uses the naive approach of loading the
  entire rollout file, and returns just the filtered slice of the data.
  Real pagination will come later by leveraging SQLite.
  
  ##### `thread/turns/items/list`
  - Adds the experimental `thread/turns/items/list` protocol, schema,
  dispatcher, and processor stub. The app-server currently returns
  JSON-RPC `-32601` with `thread/turns/items/list is not supported yet`.
  
  #### ThreadStore
  - Adds the experimental `thread/turns/items/list` protocol, schema,
  dispatcher, and processor stub. The app-server currently returns
  JSON-RPC `-32601` with `thread/turns/items/list is not supported yet`.
  - Adds `ThreadStore` contract types and stubbed methods for listing
  thread turns and listing items within a turn.
  - Adds a typed `StoredTurnStatus` and `StoredTurnError` to avoid baking
  app-server API enums or lossy string status values into the store-facing
  turn contract.
  - Adds a typed `StoredTurnStatus` and `StoredTurnError` to avoid baking
  app-server API enums or lossy string status values into the store-facing
  turn contract.
  
  This also sketches the storage abstraction we expect to need once turns
  are indexed/stored. In particular, `notLoaded` is useful only if
  ThreadStore can eventually list turn metadata without loading every
  persisted item for each turn.
  
  ## Validation
  
  - Added/updated protocol serialization coverage for the new request and
  response shapes.
  - Added app-server integration coverage for `thread/turns/list` default
  summary behavior and all three `itemsView` modes.
  - Added app-server integration coverage that `thread/turns/items/list`
  returns the expected unsupported JSON-RPC error when experimental APIs
  are enabled.
  - Added thread-store coverage that the default trait methods return
  `ThreadStoreError::Unsupported`.
  
  No developers.openai.com documentation update is needed for this
  internal experimental app-server API surface.

  Owen Lin · 2026-05-07 15:44:43 -07:00
  0d0835dd53
• [codex] Fix pathless thread summaries (#21266)

  ## Summary
  
  Fix `getConversationSummary` so thread-id summaries work for stored
  threads that do not have a local rollout path, such as remote thread
  stores.
  
  The root cause was that `summary_from_stored_thread` returned `None`
  when `StoredThread.rollout_path` was absent, and
  `get_thread_summary_response_inner` treated that as an internal error.
  This made conversation-id lookups depend on a local-only field even
  though the thread store can address the thread by id.

  Tom · 2026-05-07 11:18:16 -07:00
  0274398901
• Move thread name edits to ThreadStore (#21264)

  - Route live thread renames through `ThreadStore` metadata updates.
  - Read resumed thread names from store metadata with legacy local
  fallback preserved in the store.

  Tom · 2026-05-07 11:12:22 -07:00
  56823ec46b
• app-server: refresh live threads from latest config snapshot (#21187)

  ## Why
  
  App-server config writes were leaving existing threads partially stale.
  After a config mutation, the app-server told each live thread to run
  `Op::ReloadUserConfig`, but that path only re-read the user
  `config.toml` layer. Settings that came from the app-server's
  materialized config snapshot did not propagate to existing threads until
  restart.
  
  This change prevent a FS access from `core` for CCA.
  
  ## What changed
  
  - add `CodexThread::refresh_runtime_config()` and
  `Session::refresh_runtime_config()` so the app-server can push a freshly
  rebuilt config snapshot into a live thread
  - rebuild the latest config with each thread's `cwd` after config
  mutations, then refresh the thread from that snapshot instead of asking
  it to reload only `config.toml`
  - keep session-static settings unchanged during refresh, while updating
  runtime-refreshable state such as the config layer stack,
  `tool_suggest`, and derived hook/plugin/skill state
  - keep `reload_user_config_layer()` as the file-backed fallback for
  legacy local reload flows, but route the shared refresh logic through
  the new runtime refresh path
  
  ## Testing
  
  - add a session test that verifies `refresh_runtime_config()` rebuilds
  hooks from refreshed config
  - add a session test that verifies runtime-refreshable fields update
  while session-static settings like `model` and `notify` stay unchanged
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-07 19:22:04 +02:00
  eb0462f2af
• feat: Expose plugin share metadata in shareContext (#21495)

  Extends PluginSummary.shareContext with shareUrl and reader shareTargets

  xl-openai · 2026-05-07 10:07:03 -07:00
  114bac1409
• device-key: clean up unused crate (#21487)
  Ruslan Nigmatullin · 2026-05-07 09:01:44 -07:00
  e64a8979b0
• [codex] add account id to feedback uploads (#21498)

  ## Why
  
  Feedback uploads already carry auth-derived context like
  `chatgpt_user_id`, but they do not include the authenticated
  workspace/account id. Adding `account_id` makes feedback triage easier
  when a user can operate across multiple ChatGPT workspaces.
  
  ## What changed
  
  - emit auth-derived `account_id` into feedback tags in `app-server`
  before the feedback snapshot is uploaded
  - preserve that tag through `codex-feedback` upload tag assembly
  alongside the existing merge behavior for other tags
  - extend `codex-feedback` coverage to assert that snapshot-derived
  `account_id` is present in uploaded tags
  
  ## Verification
  
  - `cargo test -p codex-feedback
  upload_tags_include_client_tags_and_preserve_reserved_fields`
  - `cargo test -p codex-app-server --lib feedback_processor`

  pakrym-oai · 2026-05-07 08:45:16 -07:00
  acac786d91
• Show plugin hooks in plugin details (#21447)

  Supersedes the abandoned #19859, rebuilt on latest `main`.
  
  # Why
  
  PR #19705 adds discovery for hooks bundled with plugins, but `/plugins`
  still only shows skills, apps, and MCP servers. This follow-up makes
  bundled hooks visible in the same plugin detail view so users can
  inspect the full plugin surface in one place.
  
  We also need `PluginHookSummary` to populate Plugin Hooks in the app;
  `hooks/list` is not enough there because plugin detail needs to show
  hooks for disabled plugins too.
  
  # What
  
  - extend `plugin/read` with `PluginHookSummary` entries for bundled
  hooks
  - summarize plugin hooks while loading plugin details
  - render a `Hooks` row in the `/plugins` detail popup
  
  <img width="3456" height="848" alt="CleanShot 2026-04-27 at 11 45 34@2x"
  src="https://github.com/user-attachments/assets/fe3a38d6-a260-4351-8513-fb04c93d725b"
  />

  Abhinav · 2026-05-07 00:21:14 -07:00
  40e282849c
• Revert state DB injection and agent graph store (#21481)

  ## Why
  
  Reverts #20689 to restore the previous optional state DB plumbing. The
  conflict resolution keeps the newer installation ID and session/thread
  identity changes that landed after #20689, while removing the mandatory
  state DB and agent graph store dependency from ThreadManager
  construction.
  
  ## What changed
  
  - Restored `Option<StateDbHandle>` through app-server, MCP server,
  prompt debug, and test entry points.
  - Removed the `codex-core` dependency on `codex-agent-graph-store` and
  reverted descendant lookup back to the existing state DB path when
  available.
  - Kept newer `installation_id` forwarding by passing it beside the
  optional DB handle.
  - Kept local thread-name updates working when the optional state DB
  handle is absent.
  
  ## Validation
  
  - `git diff --check`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-state -p codex-rollout -p
  codex-app-server-protocol`
  - Attempted `env CARGO_INCREMENTAL=0 cargo test -p codex-core -p
  codex-app-server -p codex-app-server-client -p codex-mcp-server -p
  codex-thread-manager-sample -p codex-tui`; blocked locally by a rustc
  ICE while compiling `v8 v146.4.0` with `rustc 1.93.0 (254b59607
  2026-01-19)` on `aarch64-apple-darwin`.

  pakrym-oai · 2026-05-06 22:48:29 -07:00
  a8488fec5e
• [codex] Parallelize skills list cwd loading (#21441)

  ## Summary
  - process `skills/list` cwd entries with bounded concurrency of 5
  - preserve the caller's requested cwd order in the response
  - add coverage that verifies response ordering remains stable
  
  ## Why
  Cold-start desktop traces showed that `skills/list` can dominate the
  shared config queue when it scans many workspace roots serially. The
  expensive work is largely independent per cwd, so the request was paying
  the sum of all cwd costs instead of the cost of the slowest bounded
  batch.
  
  ## Impact
  This keeps current request semantics intact while reducing the
  wall-clock time of large multi-root `skills/list` calls. That should
  also reduce how long later config-family requests, such as
  `plugin/list`, wait behind `skills/list` during startup.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-app-server
  skills_list_preserves_requested_cwd_order`

  xli-oai · 2026-05-06 21:25:24 -07:00
  5bc33fe31f
• [codex] allow shared config reads in app-server queue (#21340)

  ## Summary
  - add a shared-read serialization mode for global app-server request
  families
  - let consecutive leading shared reads for the same family run together
  while keeping exclusive requests ordered
  - mark only `skills/list`, `config/read` and `plugin/list` as shared
  reads for now
  
  ## Why
  `skills/list` and `plugin/list` are read-only config-family requests,
  but the app-server queue currently treats every config request as
  exclusive. That means one long `skills/list` can make a later
  `plugin/list` wait even though the two requests do not mutate config.
  
  This change keeps the existing queue order but lets adjacent reads
  overlap. If a write is already waiting, later reads still stay behind
  it, so writes do not starve.
  
  ## Scope
  This intentionally keeps the first pass narrow:
  - shared reads: `skills/list`, `plugin/list`
  - still exclusive: `plugin/install`, `marketplace/*`,
  `skills/config/write`, `config/*write`, `config/read`, and the rest of
  the config family
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  
  ## Desktop verification
  I ran the dev desktop app against this branch's built binary with the
  existing UI timing logs enabled. The app did use
  `/Users/xli/code/codex_6/codex-rs/target/debug/codex`.
  
  The new scheduler behavior works, but this narrow change does not remove
  every cold-start delay: in the observed trace, an earlier exclusive
  `config/read` was already queued ahead of the later `skills/list` and
  `plugin/list` requests, so the page-open plugin requests still waited
  behind that earlier exclusive config-family request before they could
  run together.
  
  That means this PR is the scheduler primitive needed for shared reads,
  not the complete end-to-end latency fix by itself.
  
  ## Not run
  - full workspace test suite, because repo policy requires explicit
  approval before running it after touching `app-server-protocol`

  xli-oai · 2026-05-06 21:16:31 -07:00
  05cd5c313e
• Revert "Move skills watcher to app-server" (#21460)

  Reverts openai/codex#21287

  pakrym-oai · 2026-05-07 02:24:20 +00:00
  103dc2b6ae
• Add compact lifecycle hooks (started by vincentkoc - external contrib) (#19905)

  Based on work from Vincent K -
  https://github.com/openai/codex/pull/19060
  
  <img width="1836" height="642" alt="CleanShot 2026-04-29 at 20 47 40@2x"
  src="https://github.com/user-attachments/assets/b647bb89-65fe-40c8-80b0-7a6b7c984634"
  />
  
  ## Why
  
  Compaction rewrites the conversation context that future model turns
  receive, but hooks currently have no deterministic lifecycle point
  around that rewrite. This adds compact lifecycle hooks so users can
  audit manual and automatic compaction, surface hook messages in the UI,
  and run post-compaction follow-up without overloading tool or prompt
  hooks.
  
  ## What Changed
  
  - Added `PreCompact` and `PostCompact` hook events across hook config,
  discovery, dispatch, generated schemas, app-server notifications,
  analytics, and TUI hook rendering.
  - Added trigger matching for compact hooks with the documented `manual`
  and `auto` matcher values.
  - Wired `PreCompact` before both local and remote compaction, and
  `PostCompact` after successful local or remote compaction.
  - Kept compact hook command input to lifecycle metadata: session id,
  Codex turn id, transcript path, cwd, hook event name, model, and
  trigger.
  - Made compact stdout handling consistent with other hooks: plain stdout
  is ignored as debug output, while malformed JSON-looking stdout is
  reported as failed hook output.
  - Added integration coverage for compact hook dispatch, trigger
  matching, post-compact execution, and the audited behavior that
  `decision:"block"` does not block compaction.
  
  ## Out of Scope
  
  - Hook-specific compaction blocking is not implemented;
  `decision:"block"` and exit-code-2 blocking semantics are intentionally
  unsupported for `PreCompact`.
  - Custom compaction instructions are not exposed to compact hooks in
  this PR.
  - Compact summaries, summary character counts, and summary previews are
  not exposed to compact hooks in this PR.
  
  ## Verification
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core
  manual_pre_compact_block_decision_does_not_block_compaction`
  - `cargo test -p codex-app-server hooks_list`
  - `cargo test -p codex-core config_schema_matches_fixture`
  - `cargo test -p codex-tui hooks_browser`
  
  ## Docs
  
  The developer documentation for Codex hooks should be updated alongside
  this feature to document `PreCompact` and `PostCompact`, the
  `manual`/`auto` matcher values, and the compact hook payload fields.
  
  ---------
  
  Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

  Andrei Eternal · 2026-05-06 18:08:31 -07:00
  527d52df03
• feat: Add marketplace source filtering and plugin share context (#21419)

  Adds marketplaceKinds to plugin/list for local, workspace-directory, and
  shared-with-me; omitted params keep default local plus gated global
  behavior, while explicit kinds are exact.
  
  Exposes shareContext on plugin summaries from local share mappings and
  remote workspace/shared responses, including remotePluginId and nullable
  creator metadata.
  
  Adds shared-with-me listing through /ps/plugins/workspace/shared,
  renames the workspace remote namespace to workspace-directory, and keeps
  direct remote read/share/install/update/delete paths gated by plugins
  rather than remote_plugin.

  xl-openai · 2026-05-06 16:12:23 -07:00
  11106016ff
• Move skills watcher to app-server (#21287)

  ## Why
  
  Skills update notifications are app-server API behavior, but the watcher
  lived in `codex-core` and surfaced through
  `EventMsg::SkillsUpdateAvailable`. Moving the watcher out keeps core
  focused on thread execution and lets app-server own both cache
  invalidation and the `skills/changed` notification.
  
  ## What changed
  
  - Added an app-server-owned skills watcher that watches local skill
  roots, clears the shared skills cache, and emits `skills/changed`
  directly.
  - Registers skill watches from the common app-server thread listener
  attach path, including direct starts, resumes, and app-server-observed
  child or forked threads.
  - Stores the `WatchRegistration` on `ThreadState`, so listener
  replacement, thread teardown, idle unload, and app-server shutdown
  deregister by dropping the RAII guard.
  - Removed `EventMsg::SkillsUpdateAvailable`, the core watcher, and the
  old core live-reload test.
  - Extended the app-server skills change test to verify a cached skills
  list is refreshed after a filesystem change without forcing reload.
  
  ## Validation
  
  - `cargo check -p codex-core -p codex-app-server -p codex-mcp-server -p
  codex-rollout -p codex-rollout-trace`
  - `cargo test -p codex-app-server
  skills_changed_notification_is_emitted_after_skill_change`

  pakrym-oai · 2026-05-06 15:38:11 -07:00
  d5eea229cc
• [codex-analytics] emit tool item events from item lifecycle (#17090)

  ## Why
  
  After the tool-item schemas are in place, analytics needs to emit them
  from the app-server item lifecycle rather than requiring bespoke
  tracking at each callsite. The reducer should also reuse the shared
  thread analytics context introduced below it in the stack so later event
  families do not repeat the same reducer joins or missing-state ladder.
  
  ## What changed
  
  - Tracks tool-item completion notifications and emits the matching tool
  analytics event when a terminal item arrives.
  - Derives event-specific payload details for command execution, file
  changes, MCP calls, dynamic tools, collaboration tools, web search, and
  image generation.
  - Denormalizes thread, app-server client, runtime, and subagent
  provenance metadata through the shared thread analytics context.
  - Adds reducer coverage for item lifecycle emission and subagent
  metadata inheritance.
  
  ## Duration semantics
  
  `duration_ms` is computed from the app-server item lifecycle timestamps:
  `completed_at_ms - started_at_ms`. That makes it the duration of the
  lifecycle Codex observed locally, not necessarily the upstream
  provider's full execution time.
  
  - Web search usually has a meaningful observed lifecycle because
  Responses can send `response.output_item.added` before
  `response.output_item.done`; in that case `started_at_ms` comes from the
  added event and `completed_at_ms` comes from the done event.
  - Image generation can be much less precise. In the current observed
  stream, image generation often arrives only as a completed
  `response.output_item.done`; when there is no earlier added event, Codex
  synthesizes the started item immediately before completion, so
  `duration_ms` can be `0` even though upstream image generation took
  longer.
  - Standalone web search and standalone image generation work is expected
  to land after this stack. Those paths may introduce more direct
  lifecycle events or timing points, so the current
  web-search/image-generation duration semantics should be treated as the
  best available item-lifecycle approximation, not the final latency
  contract for those tool families.
  - `execution_duration_ms` is populated only where the completed item
  already carries a native execution duration; otherwise it remains `null`
  while `duration_ms` still reflects the local lifecycle interval.
  
  ## Currently placeholder / partial fields
  
  Some fields are included in the schema for the intended steady-state
  contract, but this PR does not yet populate them from real
  approval/review state:
  
  - `review_count`, `guardian_review_count`, and `user_review_count`
  currently default to `0`.
  - `final_approval_outcome` currently defaults to `unknown`.
  - `requested_additional_permissions` and `requested_network_access`
  currently default to `false`.
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17090).
  * #18748
  * #18747
  * __->__ #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-06 20:27:41 +00:00
  fbdbc6b2fe
• 2- Use string service tiers in session protocol (#20971)

  ## Summary
  - break service tier session/op/app-server protocol fields from the
  closed enum to string tier ids
  - send the service tier string directly through model requests, prewarm,
  compaction, memories, and TUI/app-server turn starts
  - regenerate app-server protocol JSON/TypeScript schemas, removing the
  standalone ServiceTier TS enum
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-app-server -p codex-tui
  - just write-app-server-schema
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-06 18:00:21 +03:00
  be1d3cff93
• feat(app-server): move v2 sessionId onto Thread (#21336)

  ## Why
  
  `session_id` and `thread_id` are separate identities after #20437, but
  app-server only surfaced `sessionId` on the `thread/start`,
  `thread/resume`, and `thread/fork` response envelopes. Other
  thread-bearing surfaces such as `thread/list`, `thread/read`,
  `thread/started`, `thread/rollback`, `thread/metadata/update`, and
  `thread/unarchive` either lacked the grouping key or forced clients to
  special-case those three responses.
  
  Making `sessionId` part of the reusable `Thread` payload gives every v2
  API surface one place to expose session-tree identity.
  
  ## Mental model
    1. thread.sessionId lives on `Thread`
  2. It is a view/runtime identity for the current live session tree, not
  durable stored lineage metadata
  3. When app-server has a live loaded thread, it copies the real value
  from core’s session_configured.session_id
  4. When it only has stored/unloaded data, it falls back to
  thread.sessionId = thread.id
  
  ## What changed
  
  - Added `sessionId` to the v2
  [`Thread`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server-protocol/src/protocol/v2/thread_data.rs#L105-L109).
  - Removed the duplicate top-level `sessionId` fields from
  `thread/start`, `thread/resume`, and `thread/fork`; clients should now
  read `response.thread.sessionId`.
  - Populated `thread.sessionId` when building live thread responses,
  replaying loaded threads, and returning stored-thread summaries so the
  field is present across start, resume, fork, list, read, rollback,
  metadata-update, unarchive, and `thread/started` paths. See
  [`load_thread_from_resume_source_or_send_internal`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/src/request_processors/thread_processor.rs#L2824-L2918)
  and
  [`thread_from_stored_thread`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/src/request_processors/thread_processor.rs#L3671-L3719).
  - Preserved the stored-thread fallback: if a thread has not been loaded
  into a live session tree yet, `thread.sessionId` falls back to
  `thread.id`; once the thread is live again, the field reports the active
  session tree root.
  - Regenerated the JSON/TypeScript schemas and updated the app-server
  README examples to show
  [`thread.sessionId`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/README.md#L306-L310)
  on the thread object.

  jif-oai · 2026-05-06 15:23:25 +02:00
  5ecff05196
• Move installation ID resolution out of core startup (#21182)

  ## Summary
  
  - resolve or inject the installation ID before core startup and pass it
  through `ThreadManager`, `CodexSpawnArgs`, and `Session` as a plain
  `String`
  - keep child sessions on the parent installation ID instead of
  rediscovering it inside core
  - propagate installation ID startup failures in `mcp-server` instead of
  panicking
  
  ## Why
  
  Core was still touching the filesystem on the session startup path to
  discover `installation_id`. This moves that work to the outer host
  boundary so core no longer depends on `codex_home` reads during session
  construction.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:54 +00:00
  8f3bb355f4
• feat: return session ID from thread/fork (#21332)

  ## Why
  
  `thread/start` and `thread/resume` already return `sessionId`, but
  `thread/fork` only returned the new thread. That left clients to infer
  the forked thread's session identity from `thread.id`, which kept the
  new `session_id` / `thread_id` split implicit at one lifecycle boundary.
  Follow-up to #20437.
  
  ## What changed
  
  - Add `sessionId` to `ThreadForkResponse`.
  - Populate it from the forked session configuration.
  - Regenerate the v2 JSON/TypeScript schema fixtures and update the
  app-server docs/example.
  - Extend the fork integration test to assert the returned `sessionId`.
  
  ## Verification
  
  - Added coverage in `thread_fork_creates_new_thread_and_emits_started`
  for the new response field.

  jif-oai · 2026-05-06 12:04:27 +02:00
  06e5dfa4dd
• feat: add session_id (#20437)

  ## Summary
  
  Related to
  https://openai.slack.com/archives/C095U48JNL9/p1777537279707449
  TLDR:
  We update the meaning of session ids and thread ids:
  * thread_id stays as now
  * session_id become a shared id between every thread under a /root
  thread (i.e. every sub-agent share the same session id)
  
  This PR introduces an explicit `SessionId` and threads it through the
  protocol/client boundary so `session_id` and `thread_id` can diverge
  when they need to, while preserving compatibility for older serialized
  `session_configured` events.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:37 +02:00
  a98623511b
• Preserve session MCP config on refresh (#21055)

  # Overview
  MCP refreshes were rebuilding active threads from fresh disk-backed
  config only, which dropped thread-start session overlays such as
  app-injected MCP servers. This keeps refreshes current with disk config
  while preserving the thread-local config that only the active thread
  knows about.
  
  # Changes
  - Rebuild refreshed config per active thread using that thread's current
  `cwd`, rather than fanning out one app-server config to every thread.
  - Preserve each thread's `SessionFlags` layer while replacing reloadable
  config layers with freshly loaded config, then derive the MCP refresh
  payload from the rebuilt result.
  - Move MCP refresh orchestration into app-server so manual refreshes
  fail loudly while background refreshes remain best-effort, and route
  plugin-triggered refreshes through the same per-thread reload path.
  - Add regression coverage for session overlays, fresh project config,
  plugin-derived MCP config, current requirements, and strict vs
  best-effort refresh behavior.
  
  # Verification
  - Passed focused Rust coverage for the thread-config rebuild behavior
  and deferred MCP refresh flow, plus `cargo test -p codex-app-server
  --lib`.
  - Verified end to end in the Codex dev app against the locally built
  CLI: registered an MCP via thread config, verified that it could be used
  successfully before refresh, manually triggered MCP refresh, and
  verified that it continued to be available afterward.

  aaronl-openai · 2026-05-05 21:09:28 -07:00
  9f06d171e2
• app-server: align dynamic tool identifiers with Responses API (#20724)

  ## Why
  
  Codex currently accepts dynamic tool names and namespaces that the
  upstream Responses function-tool path does not actually support. In
  practice, that means app-server can register a dynamic tool successfully
  and only discover later that the LLM-facing tool contract will reject or
  mishandle it.
  
  This PR tightens the app-server-side dynamic tool contract to match the
  Responses API before we stack dynamic tool hook support on top of it.
  
  ## What changed
  
  - validate dynamic tool `name` against the Responses function-tool
  identifier contract: `^[a-zA-Z0-9_-]+$`, length `1..128`
  - validate dynamic tool `namespace` the same way, with the Responses
  namespace length limit `1..64`
  - reject namespaces that collide with the always-reserved Responses
  runtime namespaces such as `functions`, `multi_tool_use`, `file_search`,
  `web`, `browser`, `image_gen`, `computer`, `container`, `terminal`,
  `python`, `python_user_visible`, `api_tool`, `tool_search`, and
  `submodel_delegator`
  - escape invalid identifiers in error messages so control characters do
  not spill raw into logs or client-visible error text
  - document the tightened dynamic tool identifier contract in
  `codex-rs/app-server/README.md`
  - add both unit coverage for the validator and an app-server integration
  test that rejects a `thread/start` request with Responses-incompatible
  dynamic tool identifiers
  
  ## Verification
  
  - `cargo test -p codex-app-server validate_dynamic_tools_`
  - `cargo test -p codex-app-server --test all
  thread_start_rejects_dynamic_tools_not_supported_by_responses`

  Andrei Eternal · 2026-05-05 21:05:00 -07:00
  8ef31894dc
• feat: Add plugin share access controls (#21124)

  Extends `plugin/share/save` to accept optional discoverability and
  shareTargets while uploading plugin contents, and adds
  `plugin/share/updateTargets` for share-only target updates without
  re-uploading.

  xl-openai · 2026-05-05 20:14:18 -07:00
  5119680f85