47 Commits

• Separate local and remote plugin analytics IDs (#29495)

  ## Why
  
  Plugin analytics overloaded `plugin_id`: most events used the Codex
  `<plugin>@<marketplace>` identity, while remote install events used the
  backend plugin ID. That makes the same field change meaning across event
  types and complicates downstream identity resolution.
  
  This change makes the contract unambiguous:
  
  - `plugin_id`: the local Codex `<plugin>@<marketplace>` identity, when
  resolved
  - `remote_plugin_id`: the backend plugin identity, when available
  
  For a remote install failure that happens before plugin details resolve,
  `plugin_id` is `null` and `remote_plugin_id` remains populated.
  
  ## What changed
  
  All six plugin analytics events use the same identity contract:
  
  - `codex_plugin_installed`
  - `codex_plugin_install_failed`
  - `codex_plugin_uninstalled`
  - `codex_plugin_enabled`
  - `codex_plugin_disabled`
  - `codex_plugin_used`
  
  Remote identity is resolved from the current installed-plugin snapshot
  first, with persisted install metadata as fallback. The telemetry
  metadata type keeps local identity optional for failures that occur
  before remote details are available.
  
  The app-server test client's manual analytics smokes now find remote
  mutation events through `remote_plugin_id` and validate that `plugin_id`
  remains local.
  
  ## Remote uninstall
  
  Resolve and capture telemetry metadata before removing the local plugin
  cache, then emit `codex_plugin_uninstalled` after the backend confirms
  success. The event is also emitted when backend uninstall succeeds but
  local cache cleanup reports `CacheRemove`.
  
  If a concurrent remote-cache refresh removes the local bundle before
  telemetry capture, the already-fetched remote plugin detail supplies
  fallback capability metadata.
  
  ## Validation
  
  - `just test -p codex-analytics` — 82 passed
  - `just test -p codex-core-plugins` — 271 passed
  - `just test -p codex-app-server-test-client` — 5 passed
  - `just test -p codex-plugin` — 3 passed
  - `just test -p codex-app-server plugin_install` — 37 passed
  - `just test -p codex-app-server plugin_uninstall` — 10 passed
  
  The production app-server install/uninstall flow was also exercised
  against `plugins~Plugin_f1b845ac33888191ac156169c58733c2`
  (`build-ios-apps@openai-curated-remote`), and the plugin's original
  uninstalled state was restored.

  jameswt-oai · 2026-06-23 12:27:14 -07:00
  ff50b47dce
• [codex] Track plugin install and import telemetry failures (#28731)

  ## Summary
  - Track plugin install failures through the unified
  `codex_plugin_install_failed` event for local installs, remote install
  preflight failures, bundle failures, and remote catalog/backend
  failures.
  - Send classified `error_type` values in plugin install failure
  analytics instead of raw error strings.
  - Stop sending raw external-agent import errors in analytics while
  preserving raw failure details in app-facing import
  notifications/history.
  - Keep raw plugin/migration diagnostics in `tracing::warn!` logs.
  - Keep remote failure plugin names as the existing local placeholder
  (`unknown`) and remove the extra telemetry plugin-name override.
  - Change `ExternalAgentConfigImportParams.source` from a generated enum
  to `string | null`, with legacy `claudeCode` / `claudeCowork` inputs
  normalized to existing analytics values.
  
  ## Testing

  charlesgong-openai · 2026-06-17 13:16:34 -07:00
  3959ab0ffc
• Add Guardian catalog diagnostics metadata (#27109)

  ## Why
  
  We need request-level evidence for Guardian cases where
  `codex-auto-review` is missing from the client-side model catalog and
  the review falls back to the parent model.
  
  ## What changed
  
  - Add `guardian_catalog_contains_auto_review` to Guardian Responses API
  client metadata.
  - Add `guardian_model_provider_id` to Guardian Responses API client
  metadata.
  - Keep review-session metadata optional so callers without metadata
  preserve the existing `None` path.
  - Add tests for override, normal preferred-model, and
  missing-auto-review-catalog behavior.
  
  ## Validation
  
  - `just test -p codex-core
  guardian_review_records_missing_auto_review_model_in_request_metadata`
  - `just test -p codex-core
  guardian_review_uses_model_catalog_override_when_preferred_review_model_exists`
  - `just test -p codex-core
  guardian_review_uses_preferred_review_model_without_model_catalog_override`
  - `git diff --check origin/main`

  Won Park · 2026-06-12 15:50:30 -07:00
  0605f9c14f
• Emit plugin ID on MCP tool call analytics events (#27483)

  MCP tool-call items already carry the runtime-resolved plugin owner, but
  the analytics reducer dropped that field. Forwarding the existing value
  provides direct attribution without downstream server-name inference.
  
  ## Summary
  
  - emit `plugin_id` on `codex_mcp_tool_call_event` payloads
  - preserve `null` for MCP calls without a plugin owner
  - verify the serialized field through the MCP item lifecycle test
  
  ## Test
  
  - `cd codex-rs && just test -p codex-analytics`
  - `cd codex-rs && just fix -p codex-analytics`
  - `cd codex-rs && just fmt`

  Chris Dong · 2026-06-11 09:55:53 -07:00
  df9dd22248
• [codex-analytics] Emit structured compaction codex errors (#27082)

  ## Summary
  - replace raw compaction `error` analytics with `codex_error_kind` and
  `codex_error_http_status_code`
  - derive compaction error telemetry from `CodexErr` using the same
  `CodexErrKind` mapping and HTTP status helper used by turn events
  - remove the pre-compact hook stop reason from the internal compaction
  outcome now that it is no longer emitted as raw analytics text
  
  ## Why
  Compaction `error` was a raw `CodexErr::to_string()` value, which can
  carry free-form provider or user-derived text. Structured Codex error
  fields preserve useful low-cardinality telemetry without sending the raw
  string.
  
  ## Validation
  - `just fmt`
  - `just test -p codex-analytics`
  - `just test -p codex-core
  compact::tests::build_token_limited_compacted_history_appends_summary_message`
  
  Attempted `just test -p codex-core`; the changed crate compiled, but the
  full target failed in unrelated environment-dependent tests such as
  missing helper binaries and shell snapshot timeouts.

  rhan-oai · 2026-06-11 06:07:06 +00:00
  8d9f33c87c
• [codex-analytics] report cached input tokens for v2 compaction (#27103)

  ## Summary
  
  - add nullable `cached_input_tokens` to the compaction analytics event
  - populate it from response usage for compaction v2
  - leave it `null` for other compaction implementations
  
  This adds visibility into prompt-cache usage for v2 compaction without
  changing compaction behavior.
  
  ## Testing
  
  - `just test -p codex-analytics`
  - `just test -p codex-core
  collect_compaction_output_accepts_additional_output_items`

  rhan-oai · 2026-06-10 22:47:22 -07:00
  383708e74e
• [codex] Retry transient Guardian review failures (#27062)

  ## Background
  
  Codex can use **Auto Review** for permission requests. Instead of asking
  the user immediately, Codex starts a separate locked-down reviewer
  session called **Guardian**, which returns a structured `allow` or
  `deny` assessment.
  
  The Guardian reviewer is itself a Codex session, so its model request
  can fail for transient infrastructure reasons such as model overload,
  HTTP connection failure, or response-stream disconnect. Today, any such
  failure immediately ends the Auto Review attempt and blocks the action.
  
  This PR adds bounded retries for failures that the existing protocol
  explicitly identifies as transient.
  
  Linear context:
  [CA-539](https://linear.app/openai/issue/CA-539/retry-auto-review-infrastructure-failures-and-fall-back-to-manual)
  
  ## What changes
  
  A Guardian review can now make at most **three total attempts**:
  
  1. Run the review normally.
  2. Retry after a jittered delay of roughly 180–220 ms if the first
  attempt fails with an eligible error.
  3. Retry after a jittered delay of roughly 360–440 ms if the second
  attempt also fails with an eligible error.
  
  All attempts share the original review deadline. Jitter spreads retries
  from concurrent clients to reduce synchronized load during broader
  outages. The retries do not reset the user's maximum wait time, and the
  backoff waits terminate early if the review is cancelled or the deadline
  expires.
  
  Before retrying, the existing Guardian session lifecycle decides whether
  the session remains usable. Healthy trunks are reused, broken trunks are
  removed by the existing cleanup path, and ephemeral sessions continue to
  clean themselves up.
  
  The review still emits one logical lifecycle to clients. Recoverable
  intermediate failures do not produce warnings or terminal events.
  
  ## Retry policy
  
  ### Retried up to twice
  
  - model/server overload
  - HTTP connection failure
  - response-stream connection failure
  - response-stream disconnect
  - internal server error
  - a final reviewer message that cannot be parsed as the required
  Guardian assessment
  
  ### Not retried
  
  - bad or invalid requests
  - authentication failures
  - usage limits
  - cyber-policy failures
  - errors without a structured category
  - a request that already exhausted the lower-level Responses retry
  budget
  - a completed Guardian turn with no assessment payload
  - prompt-construction failures
  - Guardian review timeout
  - cancellation or abort
  - a valid `deny` assessment
  
  The session-error classification uses `ErrorEvent.codex_error_info`; it
  does not inspect error-message strings.
  
  ## Implementation notes
  
  - `wait_for_guardian_review` preserves the complete `ErrorEvent`,
  including structured `codex_error_info`.
  - Guardian session failures preserve the original message and optional
  structured `CodexErrorInfo`.
  - The retry policy classifies the explicitly transient `CodexErrorInfo`
  variants; unknown, absent, and deterministic categories are not retried.
  - The Guardian session manager receives the caller's deadline rather
  than creating a new timeout per attempt.
  - Analytics record the final `attempt_count`.
  - Retry orchestration does not add a separate session-cleanup protocol;
  it relies on the existing trunk and ephemeral lifecycle decisions.
  
  ## Automated testing
  
  Focused Guardian coverage verifies:
  
  - every supported transient `CodexErrorInfo` is classified as retryable,
  while absent and non-transient categories are not;
  - structured transient session failure -> retry -> approval with the
  healthy trunk reused;
  - two invalid Guardian responses -> third attempt -> approval, with
  exactly three requests;
  - three invalid responses -> existing fail-closed result, with exactly
  three requests and one terminal lifecycle;
  - valid denial, missing payload, invalid request, timeout, cancellation,
  and prompt/session construction failures are not retried;
  - retry eligibility ends after the third attempt;
  - retry delays use the shared exponential backoff helper and remain
  within the expected jitter bounds;
  - cancellation and deadline expiry interrupt the backoff wait;
  - healthy trunks are reused across retryable failures;
  - broken event streams remove the trunk through the existing lifecycle
  cleanup;
  - an ephemeral retry does not disturb a concurrent trunk review.
  
  Validation performed:
  
  - `just test -p codex-core guardian_review_
  guardian_ephemeral_retry_preserves_parallel_trunk_and_fork_history
  run_review_removes_trunk_when_event_stream_is_broken` — **42 passed**;
  - `just test -p codex-analytics` — **71 passed**;
  - scoped Clippy fixes for `codex-core` and `codex-analytics` passed.
  
  A prior full `codex-core` run had unrelated environment-sensitive
  failures outside Guardian coverage.
  
  ## Manual QA
  
  The focused integration tests use the local mock Responses server to
  inspect exact request counts and emitted lifecycle events. They confirm
  that retries are internal, a successful later attempt supplies the final
  decision, non-retryable failures issue only one request, and exhausted
  retries emit only one terminal result.

  kbazzi · 2026-06-10 11:46:57 -07:00
  ccf1a18518
• [codex-analytics] emit goal lifecycle analytics (#27078)

  ## Why
  - Currently, there is no analytics event for `/goal` behavior
  - Existing events cannot identify goal execution or its resulting
  outcome
  - The original update in
  [#26182](https://github.com/openai/codex/pull/26182) was implemented
  before `/goal` moved into `codex-goal-extension`.
  
  ## What Changed
  - Adds `codex_goal_event` serialization and enrichment to
  `codex-analytics`
  - Emits goal events from the canonical `codex-goal-extension` mutation
  and accounting paths:
    - `created` when a new logical goal is persisted
    - `usage_accounted` when cumulative goal usage is persisted
    - `status_changed` when the stored goal status changes
    - `cleared` when the goal is deleted
  - Preserves causal `turn_id` for turn driven events and uses null
  attribution for external or idle lifecycle events
  - Changes goal deletion to return the deleted row so `cleared` retains
  the stable goal ID
  
  ## Event Details
  
  Includes standard analytics metadata along with goal specific fields:
  - `goal_id`: Stable ID stored in the local SQLite goal row and shared
  across the goal's events
  - `event_kind`: Observed operation (see the 4 lifecycle events cited in
  the above bullet)
  - `goal_status`: Resulting or last stored status: `active`, `paused`,
  `blocked`, `usage_limited`, etc.
    - `has_token_budget`: Indicates whether a token budget is configured
    - `turn_id`: Causal turn ID, or null when no causal turn exists
  - `cumulative_tokens_accounted`: Cumulative tokens on `usage_accounted`
  events; null otherwise
  - `cumulative_time_accounted_seconds`: Cumulative active time on
  `usage_accounted` events; null otherwise
  
  ## Validation
  - `just test -p codex-analytics -p codex-state -p codex-goal-extension`
  - `just test -p codex-core -E 'test(/goal/)'`
  - `just test -p codex-app-server`
  - `cargo build -p codex-analytics -p codex-core -p codex-state -p
  codex-app-server`

  marksteinbrick-oai · 2026-06-09 18:45:54 -07:00
  608b8b1cc6
• [codex-analytics] stop sending codex error subreason (#27060)

  ## Summary
  - stop emitting `codex_error_subreason` on `codex_turn_event`
  - remove the transient analytics fact plumbing that copied
  `CodexErr::InvalidRequest(String)` into the event
  - update analytics serialization coverage accordingly
  
  ## Why
  `codex_error_subreason` is a free-form copy of `InvalidRequest(String)`,
  including raw provider 400 bodies in some paths. That makes it unsafe as
  an analytics field because it can carry user-derived or sensitive text.
  
  ## Validation
  - `just fmt`
  - `just test -p codex-analytics`

  rhan-oai · 2026-06-08 21:29:06 +00:00
  ee6c91d5cf
• [codex-analytics] report compaction analytics details (#26680)

  ## Why
  
  Compaction analytics adds retained image count and compaction summary
  output tokens for v1.5 specifically.
  
  ## What changed
  
  - Add nullable `retained_image_count` and `compaction_summary_tokens`
  fields to `codex_compaction_event`.
  - Populate them only for `responses_compaction_v2`: retained images come
  from the retained v2 compacted history, and summary tokens come from
  `response.completed.token_usage.output_tokens`.
  - Leave local and legacy remote compaction events as `null` for these
  detail fields.
  
  ## Verification
  
  - `just fmt`
  - `just fix -p codex-core`
  - `just test -p codex-core
  build_v2_compacted_history_counts_retained_input_images`
  - `git diff --check`

  rhan-oai · 2026-06-08 10:52:31 -07:00
  f1c18df9ae
• [codex] Add turn profiling analytics (#26484)

  ## Summary
  
  Add flat profiling fields to `codex_turn_event` so analytics can explain
  where turn wall-clock time is spent without changing tool execution
  behavior.
  
  The profile reports:
  - time before the first sampling request
  - sampling time across all attempts and follow-ups
  - overhead between sampling requests
  - time blocked in the post-sampling tool drain
  - time after the final sampling request
  - sampling request and retry counts
  
  ## Implementation
  
  - Extend the existing turn timing state with constant-memory phase
  accounting and one RAII phase guard.
  - Observe sampling and the existing post-sampling drain only at turn
  orchestration boundaries.
  - Keep tool runtime, tool futures, response item handling, and turn
  lifecycle values unchanged.
  - Add the profiling fields directly to the existing analytics turn event
  without changing app-server protocol or rollout persistence.
  - Use the existing turn `status` to distinguish completed, failed, and
  interrupted profiles.
  
  Exact sampling/tool overlap is intentionally omitted because measuring
  tool completion accurately would require hooks in the tool execution
  path.
  
  ## Validation
  
  - Add app-server end-to-end coverage for a single-sampling turn with no
  blocking tool work.
  - Add app-server end-to-end coverage for `request_user_input` blocking
  followed by a second sampling request.
  - CI is running on the PR; tests were not executed locally per
  repository guidance.

  Ahmed Ibrahim · 2026-06-05 11:27:10 -07:00
  8d72fb6de9
• [codex-analytics] emit forked thread id on initialization (#26248)

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

  kbazzi · 2026-06-04 11:24:12 -07:00
  9e41f8ddbe
• log plugin MCP server names (#26002)

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

  Chris Dong · 2026-06-03 16:06:52 -07:00
  4d4837c495
• Populate workspace kind on Codex turn events (#25135)

  ## Summary
  - carry `workspace_kind` from Responses API client metadata into the
  turn resolved analytics fact
  - serialize the optional value on `codex_turn_event`
  - cover both the turn metadata source and turn event serialization
  
  The `workspace_kind` tells us whether a thread had a project attached vs
  projectless. this is an indicator for who is adopting Codex for
  knowledge work outside of coding
  
  ## Testing
  - `env UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just fmt`
  - `env PATH=/private/tmp/cargo-tools/bin:$PATH
  CARGO_HOME=/private/tmp/cargo-home UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just test -p codex-analytics`
  - `env PATH=/private/tmp/cargo-tools/bin:$PATH
  CARGO_HOME=/private/tmp/cargo-home UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just test -p codex-core turn_metadata`
  
  Paired with openai/openai#970661, which keeps forwarding the same
  metadata key through Responses API headers.

  knittel-openai · 2026-06-02 12:46:14 -07:00
  b794182ea7
• [codex-analytics] Track CodexErr details in turn analytics (#25707)

  ## Summary
  - add analytics-only `CodexErr` telemetry to `codex_turn_event` while
  leaving existing `turn_error` unchanged
  - record terminal `CodexErr` facts from core immediately before the
  existing turn error event is sent
  - emit source-truth `codex_error_*` fields for downstream analytics,
  including the raw `CodexErr::InvalidRequest(String)` message as
  `codex_error_subreason`
  
  ## Validation
  - `just test -p codex-analytics`
  - attempted `just test -p codex-core`, but the local run timed out
  across unrelated integration suites in this environment and is not being
  used as validation

  rhan-oai · 2026-06-02 11:40:35 -07:00
  8e4b92d294
• store and expose parent_thread_id on Threads (#25113)

  ## Why
  
  This PR
  https://github.com/openai/codex/pull/24161#discussion_r3325692763
  revealed a subagent data modeling issue, where we overloaded
  `forked_from_id` to also mean `parent_thread_id`. That's incorrect since
  guardian and review subagents can be a subagent and NOT fork the main
  thread's history.
  
  The solution here is to explicitly store a new `parent_thread_id` on
  `SessionMeta`, alongside `forked_from_id` which already exists. While
  we're at it, also expose it in the app-server protocol on the `Thread`
  object.
  
  A thread->subagent relationship and a fork of thread history are
  orthogonal concepts.
  
  ## What Changed
  
  - Added top-level `parent_thread_id` persistence on `SessionMeta` and
  runtime/session plumbing through `SessionConfiguredEvent`,
  `CodexSpawnArgs`, `SessionConfiguration`, `ThreadConfigSnapshot`,
  `TurnContext`, and `ModelClient`.
  - Made turn metadata, request headers, analytics, and subagent-start
  events read the separate runtime/top-level parent field instead of
  deriving general parent lineage from `SessionSource` or
  `forked_from_thread_id`.
  - Passed parent lineage separately at delegated subagent, review,
  guardian, agent-job, and multi-agent spawn construction sites;
  copied-history fork lineage remains derived only from `InitialHistory`.
  - Persisted and exposed parent lineage through rollout/thread-store
  projections and app-server v2 `Thread.parentThreadId`.
  - Updated app-server README text and regenerated app-server schema
  fixtures for the additive `parentThreadId` response field.

  Owen Lin · 2026-06-01 04:33:20 +00:00
  cf0911076f
• Add cloud-managed config layer support (#24620)

  ## Summary
  
  PR 3 of 5 in the cloud-managed config client stack.
  
  Adds enterprise-managed cloud config as a first-class config layer
  source. The layer metadata is preserved through config loading,
  diagnostics, debug output, hook attribution, and app-server protocol
  surfaces.
  
  ## Details
  
  - Enterprise-managed config becomes a normal config layer source with
  backend-supplied `id` and display `name` attached for provenance.
  - These layers are designed to behave like non-file managed config: they
  can surface syntax/type diagnostics by layer name even though there is
  no physical config file.
  - Relative path settings are resolved from a stored config base so
  cloud-delivered config remains consistent with existing MDM-delivered
  config semantics.
  - Hook attribution distinguishes config-delivered hooks from
  requirements-delivered hooks via `HookSource::CloudManagedConfig`.
  - This remains pull-based and snapshot-oriented; the PR adds layer
  identity/diagnostics, not dynamic reload behavior.
  
  ## Validation
  
  Validated through the targeted stack checks after rebasing onto current
  `main`:
  
  - Rust crate tests for
  config/hooks/cloud-config/backend-client/app-server-protocol
  - Filtered `codex-core` and `codex-app-server` `cloud_config_bundle`
  tests
  - Python generated-file contract test
  - `cargo shear --deny-warnings`
  - Targeted `argument-comment-lint` for config/hooks

  joeflorencio-openai · 2026-05-31 15:54:31 -07:00
  8a556296f0
• Add subagent lineage metadata for responsesapi (#24161)

  ## Why
  
  We recently added `forked_from_thread_id` which lets us trace where a
  thread's _context_ comes from, but we also want to understand subagent
  lineage (e.g. which parent thread spawned this subagent? what kind of
  subagent is it?) which is orthogonal.
  
  This PR adds `parent_thread_id` and `subagent_kind` to the
  `x-codex-turn-metadata` header sent to ResponsesAPI.
  
  ## What changed
  
  - Adds `parent_thread_id` and `subagent_kind` to core-owned
  `x-codex-turn-metadata`.
  - Restores persisted `SessionSource` and `ThreadSource` from resumed
  session metadata so cold-resumed subagent threads keep their lineage on
  later Responses API requests.
  - Centralizes parent-thread extraction on `SessionSource` /
  `SubAgentSource` and reuses it in the Responses client, analytics, agent
  control, and state parsing paths.
  - Extends reserved-key, git-enrichment, thread-spawn, and app-server v2
  metadata coverage for the new lineage fields.
  
  ## Verification
  
  - Not run locally per request.
  - Added focused coverage in `core/src/turn_metadata_tests.rs` and
  `app-server/tests/suite/v2/client_metadata.rs`.

  Owen Lin · 2026-05-29 11:28:12 -07:00
  fc9cf62efb
• [codex-analytics] add grouped session id to runtime events (#24655)

  ## Why
  - Runtime analytics events report `thread_id`, which identifies the
  individual thread emitting an event
  - They don't report `session_id`, which identifies the shared session
  for a root thread and its subagent threads
  - Emitting both identifiers allows analytics to group related activity
  
  ## What Changed
  - Adds `session_id` to relevant analytics events (thread_initalized,
  turn, turn_steer, compaction, guardian_review)
  - Tracks each thread's session ID in the analytics reducer so subsequent
  thread scoped events emit the same value
  - Carries the shared session ID through subagent initialization
  
  ## Verification
  - `just test -p codex-analytics` validates event payloads and subagent
  session grouping.
  - Focused `codex-app-server` tests validate session IDs for thread,
  turn, and steer events.
  - Focused `codex-core` tests validate root and subagent session ID
  propagation.

  marksteinbrick-oai · 2026-05-26 16:38:46 -07:00
  487521733b
• Add SubagentStop hook (#22873)

  # What
  
  <img width="1792" height="1024" alt="image"
  src="https://github.com/user-attachments/assets/8f81d232-5813-4994-a61d-e42a05a93a3e"
  />
  
  `SubagentStop` runs when a thread-spawned subagent turn is about to
  finish. Thread-spawned subagents use `SubagentStop` instead of the
  normal root-agent `Stop` hook.
  
  Configured handlers match on `agent_type`. Hook input includes the
  normal stop fields plus:
  
  - `agent_id`: the child thread id.
  - `agent_type`: the resolved subagent type.
  - `agent_transcript_path`: the child subagent transcript path.
  - `transcript_path`: the parent thread transcript path.
  - `last_assistant_message`: the final assistant message from the child
  turn, when available.
  - `stop_hook_active`: `true` when the child is already continuing
  because an earlier stop-like hook blocked completion.
  
  `SubagentStop` shares the same completion-control semantics as `Stop`,
  scoped to the child turn:
  
  - No decision allows the child turn to finish.
  - `decision: "block"` with a non-empty `reason` records that reason as
  hook feedback and continues the child with that prompt.
  - `continue: false` stops the child turn. If `stopReason` is present,
  Codex surfaces it as the stop reason.
  
  # Lifecycle Scope
  
  Only thread-spawned subagents run `SubagentStop`.
  
  Internal/system subagents such as Review, Compact, MemoryConsolidation,
  and Other do not run normal `Stop` hooks and do not run `SubagentStop`.
  This avoids exposing synthetic matcher labels for internal
  implementation paths.
  
  # Stack
  
  1. #22782: add `SubagentStart`.
  2. This PR: add `SubagentStop`.
  3. #22882: add subagent identity to normal hook inputs.

  Abhinav · 2026-05-20 14:59:41 -07:00
  eee3e60db3
• Add SubagentStart hook (#22782)

  # What
  
  `SubagentStart` runs once when Codex creates a thread-spawned subagent,
  before that child sends its first model request. Thread-spawned
  subagents use `SubagentStart` instead of the normal root-agent
  `SessionStart` hook.
  
  Configured handlers match on the subagent `agent_type`, using the same
  value passed to `spawn_agent`. When no agent type is specified, Codex
  uses the default agent type.
  
  Hook input includes the normal session-start fields plus:
  
  - `agent_id`: the child thread id.
  - `agent_type`: the resolved subagent type.
  
  `SubagentStart` may return `hookSpecificOutput.additionalContext`. That
  context is added to the child conversation before the first model
  request.
  
  # Lifecycle Scope
  
  Only thread-spawned subagents run `SubagentStart`.
  
  Internal/system subagents such as Review, Compact, MemoryConsolidation,
  and Other do not run normal `SessionStart` hooks and do not run
  `SubagentStart`. This avoids exposing synthetic matcher labels for
  internal implementation paths.
  
  Also the `SessionStart` hook no longer fires for subagents, this matches
  behavior with other coding agents' implementation
  
  # Stack
  
  1. This PR: add `SubagentStart`.
  2. #22873: add `SubagentStop`.
  3. #22882: add subagent identity to normal hook inputs.

  Abhinav · 2026-05-19 12:45:08 -07:00
  d661ab70ed
• [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
• [codex-analytics] add turn tool counts to turn events (#21431)

  ## Summary
  - accumulate completed tool-item counts per turn from the item lifecycle
  - populate the reserved count fields on `codex_turn_event`
  - add reducer coverage for zero-count turns and mixed completed tool
  items
  
  ## Why
  PR #17090 moved tool-item analytics onto the item lifecycle, so the turn
  reducer can now derive the per-turn tool counts from the same completed
  items instead of leaving the reserved fields null.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-analytics`

  rhan-oai · 2026-05-11 18:18:02 +00:00
  cf6342b75b
• Emit accepted line fingerprint analytics (#21601)

  ## Why
  
  Codex assisted-code attribution needs a client-side accepted-code source
  that does not upload raw code. This adds a hash-only analytics event
  derived from the turn diff so downstream attribution can compare
  accepted Codex lines against commit or PR diffs.
  
  ## What Changed
  
  - Parse accepted/effective added lines from the final turn diff and emit
  `codex_accepted_line_fingerprints` analytics.
  - Hash repo, path, and normalized line content before upload; raw code
  and raw diffs are not included in the event.
  - Chunk large fingerprint payloads and send accepted-line fingerprint
  events in isolated requests while preserving normal batching for other
  analytics events.
  - Canonicalize Git remote URLs before repo hashing so SSH/HTTPS GitHub
  remotes join to the same repo hash.
  - Add parser coverage for unified diff hunk lines that look like `+++`
  or `---` file headers.
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-git-utils canonicalize_git_remote_url`
  - `just fix -p codex-analytics`
  - `just bazel-lock-check`
  - `git diff --check`

  alexsong-oai · 2026-05-08 12:16:24 -07:00
  bbb6bf0a37
• [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
• [codex-analytics] add tool review event schema (#18747)

  ## Why
  
  We want to emit terminal review analytics for tool-related approval
  flows, but the event contract needs to exist before the reducer can
  publish anything.
  
  This PR is the schema-only slice for the Codex review event family.
  
  ## What changed
  
  - add the `ReviewEvent` analytics envelope in
  `codex-rs/analytics/src/events.rs`
  - define the review subject kind, reviewer, trigger, terminal status,
  and post-review resolution enums
  - define the review event payload with thread, turn, item, lineage,
  tool, and timing fields that the emitter stack will populate
  
  ## Verification
  
  - stacked verification in dependent PRs: `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/18747).
  * #18748
  * #21434
  * __->__ #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-07 09:46:46 -07:00
  3444b0d60a
• 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
• [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
• [codex-analytics] rework thread_source for thread analytics (#20949)

  ## Summary
  - make `thread_source` an explicit optional thread-level field on
  `thread/start`, `thread/fork`, and returned thread payloads
  - persist `thread_source` in rollout/session metadata so resumed live
  threads retain the original value
  - replace the old best-effort `session_source` -> `thread_source`
  mapping with an explicit caller-supplied analytics classification
  
  ## Why
  Before this change, analytics `thread_source` was populated by a
  best-effort mapping from `session_source`. `session_source` describes
  the runtime/client surface, not the actual thread-level origin, so that
  projection was not accurate enough to distinguish cases such as `user`,
  `subagent`, `memory_consolidation`, and future thread origins reliably.
  
  Making `thread_source` explicit keeps one thread-level analytics field
  while letting callers provide the real classification directly instead
  of recovering it indirectly from `session_source`.
  
  ## Impact
  For new analytics events, `thread_source` now reflects the explicit
  thread-level classification supplied by the caller rather than an
  inferred value derived from `session_source`. Existing protocol fields
  remain optional; callers that omit `threadSource` now produce `null`
  instead of a best-effort inferred value.
  
  ## Validation
  - `just write-app-server-schema`
  - `cargo test -p codex-analytics -p codex-core -p
  codex-app-server-protocol --no-run`
  - `cargo test -p codex-app-server-protocol
  generated_ts_optional_nullable_fields_only_in_params`
  - `cargo test -p codex-analytics
  thread_initialized_event_serializes_expected_shape`
  - `cargo test -p codex-core
  resume_stopped_thread_from_rollout_preserves_thread_source`

  rhan-oai · 2026-05-06 02:12:31 +00:00
  b3d4f1a9f0
• [codex-analytics] add tool item event schemas (#17089)

  ## Why
  
  Tool analytics need stable, typed payloads before the later lifecycle
  reducer starts emitting them. Keeping the event schema definitions
  isolated in their own PR makes the emitted surface reviewable separately
  from the reducer logic that produces those events.
  
  ## What changed
  
  - Adds the common tool-item analytics event base plus event payload
  types for command execution, file changes, MCP calls, dynamic tools,
  collaboration tools, web search, and image generation.
  - Extends `TrackEventRequest` with the corresponding tool-item variants.
  - Adds serialization coverage for the command-execution 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/17089).
  * #18748
  * #18747
  * #17090
  * __->__ #17089
  * #20514

  rhan-oai · 2026-05-05 11:49:30 -07:00
  fb7e1eb6fc
• Add turn_id to Codex skill invocation analytics (#21122)
  edwardysun3 · 2026-05-05 00:11:06 -04:00
  7e71d02610
• Add plugin ID to skill analytics (#20923)

  ## Summary
  - thread plugin skill roots through the skills loader with their plugin
  ID
  - store plugin ID on loaded skill metadata for plugin-provided skills
  - include plugin ID on skill invocation analytics events
  
  ## Test plan
  - cargo check -p codex-core-skills
  - cargo check -p codex-core -p codex-core-plugins -p codex-analytics
  - cargo check -p codex-tui
  - cargo check -p codex-plugin -p codex-core -p codex-core-plugins -p
  codex-analytics
  - cargo check -p codex-app-server
  - cargo test -p codex-analytics
  - HOME=/private/tmp/codex-empty-home cargo test -p codex-core-skills
  - just fix -p codex-core-skills
  - just fix -p codex-analytics
  - just fix -p codex-core-plugins
  - just fix -p codex-core
  - just fmt
  - git diff --check

  alexsong-oai · 2026-05-04 20:36:29 -07:00
  3ad7cf0993
• Emit analytics for remote plugin installs (#20267)

  ## Summary
  
  - emit `codex_plugin_installed` after a remote plugin install succeeds
  - keep local installs unchanged, but let remote installs override the
  analytics `plugin_id` with the backend remote plugin id
  (`plugins~Plugin_...`)
  - preserve the local/display identity in `plugin_name` and
  `marketplace_name`, plus capability metadata from the installed bundle
  - add regression coverage for local install analytics, remote install
  analytics, and analytics id override serialization
  
  ## Testing
  
  - `just fmt`
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-app-server`

  xli-oai · 2026-04-30 17:27:16 -07:00
  acdf908268
• Add persisted hook enablement state (#19840)

  ## Why
  
  After `hooks/list` exposes the hook inventory, clients need a way to
  persist user hook preferences, make those changes effective in
  already-open sessions, and distinguish user-controllable hooks from
  managed requirements without adding another bespoke app-server write
  API.
  
  ## What
  
  - Extends `hooks/list` entries with effective `enabled` state.
  - Persists user-level hook state under `hooks.state.<hook-id>` so the
  model can grow beyond a single boolean over time.
  - Uses the existing `config/batchWrite` path for hook state updates
  instead of introducing a dedicated hook write RPC.
  - Refreshes live session hook engines after config writes so
  already-open threads observe updated enablement without a restart.
  
  ## Stack
  
  1. openai/codex#19705
  2. openai/codex#19778
  3. This PR - openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  The generated schema files account for much of the raw diff. The core
  behavior is in:
  
  - `hooks/src/config_rules.rs`, which resolves per-hook user state from
  the config layer stack.
  - `hooks/src/engine/discovery.rs`, which projects effective enablement
  into `hooks/list` from source-derived managedness.
  - `config/src/hook_config.rs`, which defines the new `hooks.state`
  representation.
  - `core/src/session/mod.rs`, which rebuilds live hook state after user
  config reloads.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-30 04:46:32 +00:00
  8f3c06cc97
• Discover hooks bundled with plugins (#19705)

  ## Why
  
  Plugins can bundle lifecycle hooks, but Codex previously only discovered
  hooks from user, project, and managed config layers. This adds the
  plugin discovery and runtime plumbing needed for plugin-bundled hooks
  while keeping execution behind the `plugin_hooks` feature flag.
  
  ## What
  
  - Discovers plugin hook sources from each plugin's default
  `hooks/hooks.json`.
  - Supports `plugin.json` manifest `hooks` entries as either relative
  paths or inline hook objects.
  - Plumbs discovered plugin hook sources through plugin loading into the
  hook runtime when `plugin_hooks` is enabled.
  - Marks plugin-originated hook runs as `HookSource::Plugin`.
  - Injects `PLUGIN_ROOT` and `CLAUDE_PLUGIN_ROOT` into plugin hook
  command environments.
  - Updates generated schemas and hook source metadata for the plugin hook
  source.
  
  ## Stack
  
  1. This PR - openai/codex#19705
  2. openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  - Core logic is in `codex-rs/core-plugins/src/loader.rs` and
  `codex-rs/hooks/src/engine/discovery.rs`
  - Moved existing / adding new tests to
  `codex-rs/core-plugins/src/loader_tests.rs` hence the large diff there
  - Otherwise mostly plumbing and minor schema updates
  
  ### Core Changes
  
  The `codex-rs/core` changes are limited to wiring plugin hook support
  into existing core flows:
  
  - `core/src/session/session.rs` conditionally pulls effective plugin
  hook sources and plugin hook load warnings from `PluginsManager` when
  `plugin_hooks` is enabled, then passes them into `HooksConfig`.
  - `core/src/hook_runtime.rs` adds the `plugin` metric tag for
  `HookSource::Plugin`.
  - `core/config.schema.json` picks up the new `plugin_hooks` feature
  flag, and `core/src/plugins/manager_tests.rs` updates fixtures for the
  added plugin hook fields.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-28 14:17:18 -07:00
  c6e7d564c3
• permissions: make profiles represent enforcement (#19231)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions abstraction,
  but the old shape only carried optional filesystem and network fields.
  It could describe allowed access, but not who is responsible for
  enforcing it. That made `DangerFullAccess` and `ExternalSandbox` lossy
  when profiles were exported, cached, or round-tripped through app-server
  APIs.
  
  The important model change is that active permissions are now a disjoint
  union over the enforcement mode. Conceptually:
  
  ```rust
  pub enum PermissionProfile {
      Managed {
          file_system: FileSystemSandboxPolicy,
          network: NetworkSandboxPolicy,
      },
      Disabled,
      External {
          network: NetworkSandboxPolicy,
      },
  }
  ```
  
  This distinction matters because `Disabled` means Codex should apply no
  outer sandbox at all, while `External` means filesystem isolation is
  owned by an outside caller. Those are not equivalent to a broad managed
  sandbox. For example, macOS cannot nest Seatbelt inside Seatbelt, so an
  inner sandbox may require the outer Codex layer to use no sandbox rather
  than a permissive one.
  
  ## How Existing Modeling Maps
  
  Legacy `SandboxPolicy` remains a boundary projection, but it now maps
  into the higher-fidelity profile model:
  
  - `ReadOnly` and `WorkspaceWrite` map to `PermissionProfile::Managed`
  with restricted filesystem entries plus the corresponding network
  policy.
  - `DangerFullAccess` maps to `PermissionProfile::Disabled`, preserving
  the “no outer sandbox” intent instead of treating it as a lax managed
  sandbox.
  - `ExternalSandbox { network_access }` maps to
  `PermissionProfile::External { network }`, preserving external
  filesystem enforcement while still carrying the active network policy.
  - Split runtime policies that legacy `SandboxPolicy` cannot faithfully
  express, such as managed unrestricted filesystem plus restricted
  network, stay `Managed` instead of being collapsed into
  `ExternalSandbox`.
  - Per-command/session/turn grants remain partial overlays via
  `AdditionalPermissionProfile`; full `PermissionProfile` is reserved for
  complete active runtime permissions.
  
  ## What Changed
  
  - Change active `PermissionProfile` into a tagged union: `managed`,
  `disabled`, and `external`.
  - Keep partial permission grants separate with
  `AdditionalPermissionProfile` for command/session/turn overlays.
  - Represent managed filesystem permissions as either `restricted`
  entries or `unrestricted`; `glob_scan_max_depth` is non-zero when
  present.
  - Preserve old rollout compatibility by accepting the pre-tagged `{
  network, file_system }` profile shape during deserialization.
  - Preserve fidelity for important edge cases: `DangerFullAccess`
  round-trips as `disabled`, `ExternalSandbox` round-trips as `external`,
  and managed unrestricted filesystem + restricted network stays managed
  instead of being mistaken for external enforcement.
  - Preserve configured deny-read entries and bounded glob scan depth when
  full profiles are projected back into runtime policies, including
  unrestricted replacements that now become `:root = write` plus deny
  entries.
  - Regenerate the experimental app-server v2 JSON/TypeScript schema and
  update the `command/exec` README example for the tagged
  `permissionProfile` shape.
  
  ## Compatibility
  
  Legacy `SandboxPolicy` remains available at config/API boundaries as the
  compatibility projection. Existing rollout lines with the old
  `PermissionProfile` shape continue to load. The app-server
  `permissionProfile` field is experimental, so its v2 wire shape is
  intentionally updated to match the higher-fidelity model.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo check --tests`
  - `cargo test -p codex-protocol permission_profile`
  - `cargo test -p codex-protocol
  preserving_deny_entries_keeps_unrestricted_policy_enforceable`
  - `cargo test -p codex-app-server-protocol
  permission_profile_file_system_permissions`
  - `cargo test -p codex-app-server-protocol serialize_client_response`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox`
  - `just fix`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  Michael Bolin · 2026-04-23 23:02:18 -07:00
  4816b89204
• [codex-analytics] guardian review analytics events emission (#17693)

  ## Why
  
  Guardian approvals now run as review sessions, but Codex analytics did
  not have a terminal event for those reviews. That made it hard to
  measure approval outcomes, failure modes, Guardian session reuse, model
  metadata, token usage, and timing separately from the parent turn.
  
  ## What changed
  
  Adds `codex_guardian_review` analytics emission for Guardian approval
  reviews. The event is emitted from the Guardian review path with review
  identity, target item id, approval request source, a PII-minimized
  reviewed-action shape, terminal decision/status, failure reason,
  Guardian assessment fields, Guardian session metadata, token usage, and
  timing metadata.
  
  The reviewed-action payload intentionally omits high-risk fields such as
  shell commands, working directories, argv, file paths, network
  targets/hosts, rationale, retry reason, and permission justifications.
  It also classifies prompt-build failures separately from Guardian
  session/runtime failures so fail-closed cases are distinguishable in
  analytics.
  
  ## Verification
  
  - Guardian review analytics tests cover terminal success,
  timeout/cancel/fail-closed paths, session metadata, and token usage
  plumbing.
  - `cargo clippy -p codex-core --lib --tests -- -D warnings`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17693).
  * #17696
  * #17695
  * __->__ #17693

  rhan-oai · 2026-04-22 01:02:47 -07:00
  4e7399c6b9
• [codex-analytics] guardian review analytics schema polishing (#17692)

  ## Why
  
  Guardian review analytics needs a Rust event shape that matches the
  backend schema while avoiding unnecessary PII exposure from reviewed
  tool calls. This PR narrows the analytics payload to the fields we
  intend to emit and keeps shared Guardian assessment enums in protocol
  instead of duplicating equivalent analytics-only enums.
  
  ## What changed
  
  - Uses protocol Guardian enums directly for `risk_level`,
  `user_authorization`, `outcome`, and command source values.
  - Removes high-risk reviewed-action fields from the analytics payload,
  including raw commands, display strings, working directories, file
  paths, network targets/hosts, justification text, retry reason, and
  rationale text.
  - Makes `target_item_id` and `tool_call_count` nullable so the Codex
  event can represent cases where the app-server protocol or producer does
  not have those values.
  - Keeps lower-risk structured reviewed-action metadata such as sandbox
  permissions, permission profile, `tty`, `execve` source/program, network
  protocol/port, and MCP connector/tool labels.
  - Adds an analytics reducer/client test covering `codex_guardian_review`
  serialization with an optional `target_item_id` and absent removed
  fields.
  
  ## Verification
  
  - `cargo test -p codex-analytics
  guardian_review_event_ingests_custom_fact_with_optional_target_item`
  - `cargo fmt --check`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17692).
  * #17696
  * #17695
  * #17693
  * __->__ #17692

  rhan-oai · 2026-04-20 13:08:17 -07:00
  7f53e47250
• Add PermissionRequest hooks support (#17563)

  ## Why
  
  We need `PermissionRequest` hook support!
  
  Also addresses:
  - https://github.com/openai/codex/issues/16301
  - run a script on Hook to do things like play a sound to draw attention
  but actually no-op so user can still approve
  - can omit the `decision` object from output or just have the script
  exit 0 and print nothing
  - https://github.com/openai/codex/issues/15311
    - let the script approve/deny on its own
    - external UI what will run on Hook and relay decision back to codex
  
  
  ## Reviewer Note
  
  There's a lot of plumbing for the new hook, key files to review are:
  - New hook added in `codex-rs/hooks/src/events/permission_request.rs`
  - Wiring for network approvals
  `codex-rs/core/src/tools/network_approval.rs`
  - Wiring for tool orchestrator `codex-rs/core/src/tools/orchestrator.rs`
  - Wiring for execve
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs`
  
  ## What
  
  - Wires shell, unified exec, and network approval prompts into the
  `PermissionRequest` hook flow.
  - Lets hooks allow or deny approval prompts; quiet or invalid hooks fall
  back to the normal approval path.
  - Uses `tool_input.description` for user-facing context when it helps:
    - shell / `exec_command`: the request justification, when present
    - network approvals: `network-access <domain>`
  - Uses `tool_name: Bash` for shell, unified exec, and network approval
  permission-request hooks.
  - For network approvals, passes the originating command in
  `tool_input.command` when there is a single owning call; otherwise falls
  back to the synthetic `network-access ...` command.
  
  <details>
  <summary>Example `PermissionRequest` hook input for a shell
  approval</summary>
  
  ```json
  {
    "session_id": "<session-id>",
    "turn_id": "<turn-id>",
    "transcript_path": "/path/to/transcript.jsonl",
    "cwd": "/path/to/cwd",
    "hook_event_name": "PermissionRequest",
    "model": "gpt-5",
    "permission_mode": "default",
    "tool_name": "Bash",
    "tool_input": {
      "command": "rm -f /tmp/example"
    }
  }
  ```
  
  </details>
  
  <details>
  <summary>Example `PermissionRequest` hook input for an escalated
  `exec_command` request</summary>
  
  ```json
  {
    "session_id": "<session-id>",
    "turn_id": "<turn-id>",
    "transcript_path": "/path/to/transcript.jsonl",
    "cwd": "/path/to/cwd",
    "hook_event_name": "PermissionRequest",
    "model": "gpt-5",
    "permission_mode": "default",
    "tool_name": "Bash",
    "tool_input": {
      "command": "cp /tmp/source.json /Users/alice/export/source.json",
      "description": "Need to copy a generated file outside the workspace"
    }
  }
  ```
  
  </details>
  
  <details>
  <summary>Example `PermissionRequest` hook input for a network
  approval</summary>
  
  ```json
  {
    "session_id": "<session-id>",
    "turn_id": "<turn-id>",
    "transcript_path": "/path/to/transcript.jsonl",
    "cwd": "/path/to/cwd",
    "hook_event_name": "PermissionRequest",
    "model": "gpt-5",
    "permission_mode": "default",
    "tool_name": "Bash",
    "tool_input": {
      "command": "curl http://codex-network-test.invalid",
      "description": "network-access http://codex-network-test.invalid"
    }
  }
  ```
  
  </details>
  
  ## Follow-ups
  
  - Implement the `PermissionRequest` semantics for `updatedInput`,
  `updatedPermissions`, `interrupt`, and suggestions /
  `permission_suggestions`
  - Add `PermissionRequest` support for the `request_permissions` tool
  path
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-17 14:45:47 +00:00
  8494e5bd7b
• Add codex_hook_run analytics event (#17996)

  # Why
  Add product analytics for hook handler executions so we can understand
  which hooks are running, where they came from, and whether they
  completed, failed, stopped, or blocked work.
  
  # What
  - add the new `codex_hook_run` analytics event and payload plumbing in
  `codex-rs/analytics`
  - emit hook-run analytics from the shared hook completion path in
  `codex-rs/core`
  - classify hook source from the loaded hook path as `system`, `user`,
  `project`, or `unknown`
  
  ```
  {
    "event_type": "codex_hook_run",
    "event_params": {
      "thread_id": "string",
      "turn_id": "string",
      "model_slug": "string",
      "hook_name": "string, // any HookEventName
      "hook_source": "system | user | project | unknown",
      "status": "completed | failed | stopped | blocked"
    }
  }
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-16 19:43:16 +00:00
  8720b7bdce
• [codex-analytics] add session source to client metadata (#17374)

  ## Summary
  
  Adds `thread_source` field to the existing Codex turn metadata sent to
  Responses API
  - Sends `thread_source: "user"` for user-initiated sessions: CLI, VS
  Code, and Exec
  - Sends `thread_source: "subagent"` for subagent sessions
  - Omits `thread_source` for MCP, custom, and unknown session sources
  - Uses the existing turn metadata transport:
    - HTTP requests send through the `x-codex-turn-metadata` header
  - WebSocket `response.create` requests send through
  `client_metadata["x-codex-turn-metadata"]`
  
  ## Testing
  - `cargo test -p codex-protocol
  session_source_thread_source_name_classifies_user_and_subagent_sources`
  - `cargo test -p codex-core turn_metadata_state`
  - `cargo test -p codex-core --test responses_headers
  responses_stream_includes_turn_metadata_header_for_git_workspace_e2e --
  --nocapture`

  marksteinbrick-oai · 2026-04-14 08:55:12 -07:00
  61fe23159e
• [codex-analytics] feature plumbing and emittance (#16640)

  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16640).
  * #16870
  * #16706
  * #16641
  * __->__ #16640

  rhan-oai · 2026-04-13 23:11:49 -07:00
  b704df85b8
• feat(analytics): add guardian review event schema (#17055)

  Just the analytics schema definition for guardian evaluations. No wiring
  done yet.

  Owen Lin · 2026-04-10 17:33:58 -07:00
  58933237cd
• [codex-analytics] add compaction analytics event (#17155)

  - event for compaction analytics
  - introduces thread-connection and thread metadata caches for data
  denormalization, expected to be useful for denormalization onto core
  emitted events in general
  - threads analytics event client into core (mirrors approved
  implementation in #16640)
  - denormalizes key thread metadata: thread_source, subagent_source,
  parent_thread_id, as well as app-server client and runtime metadata)
  - compaction strategy defaults to memento, forward compatible with
  expected prefill_compaction strategy
  
  1. Manual standalone compact, local
  `INFO | 2026-04-09 17:35:50 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d0-5cfb-70c0-bef9-165c3bf9b2df', 'turn_id':
  '019d74d0-d7f6-7c81-acc6-aae2030243d6', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'manual', 'reason':
  'user_requested', 'implementation': 'responses', 'phase':
  'standalone_turn', 'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 20170, 'active_context_tokens_after':
  4830, 'started_at': 1775781337, 'completed_at': 1775781350,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 13524} | `
  
  2. Auto pre-turn compact, local
  `INFO | 2026-04-09 17:37:30 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d2-45ef-71d1-9c93-23cc0c13d988', 'turn_id':
  '019d74d2-7b42-7372-9f0e-c0da3f352328', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'auto', 'reason':
  'context_limit', 'implementation': 'responses', 'phase': 'pre_turn',
  'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 20063, 'active_context_tokens_after':
  4822, 'started_at': 1775781444, 'completed_at': 1775781449,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 5497} | `
  
  3. Auto mid-turn compact, local
  `INFO | 2026-04-09 17:38:28 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d3-212f-7a20-8c0a-4816a978675e', 'turn_id':
  '019d74d3-3ee1-7462-89f6-2ffbeefcd5e3', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'auto', 'reason':
  'context_limit', 'implementation': 'responses', 'phase': 'mid_turn',
  'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 20325, 'active_context_tokens_after':
  14641, 'started_at': 1775781500, 'completed_at': 1775781508,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 7507} | `
  
  4. Remote /responses/compact, manual standalone
  `INFO | 2026-04-09 17:40:20 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:526 | Tracked
  codex_compaction_event event params={'thread_id':
  '019d74d4-7a11-78a1-89f7-0535a1149416', 'turn_id':
  '019d74d4-e087-7183-9c20-b1e40b7578c0', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': True}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'trigger': 'manual', 'reason':
  'user_requested', 'implementation': 'responses_compact', 'phase':
  'standalone_turn', 'strategy': 'memento', 'status': 'completed',
  'active_context_tokens_before': 23461, 'active_context_tokens_after':
  6171, 'started_at': 1775781601, 'completed_at': 1775781620,
  'thread_source': 'user', 'subagent_source': None, 'parent_thread_id':
  None, 'error': None, 'duration_ms': 18971} | `

  rhan-oai · 2026-04-10 13:03:54 -07:00
  5779be314a
• adding parent_thread_id in guardian (#17249)

  ## Summary
  
  This PR adds the parent conversation/session id to the subagent-start
  analytics event for Guardian subagents.
  
  Previously, Guardian sessions were emitted as subagent
  thread-initialized events, but their `parent_thread_id` was serialized
  as `null`. After this change, the `codex_thread_initialized` analytics
  event for a Guardian child session includes the parent user conversation
  id.

  Won Park · 2026-04-10 06:25:05 +00:00
  4e910bf151
• [codex-analytics] subagent analytics (#15915)

  - creates custom event that emits subagent thread analytics from core
  - wires client metadata (`product_client_id, client_name,
  client_version`), through from app-server
  - creates `created_at `timestamp in core
  - subagent analytics are behind `FeatureFlag::GeneralAnalytics`
  
  PR stack
  - [[telemetry] thread events
  #15690](https://github.com/openai/codex/pull/15690)
  - --> [[telemetry] subagent events
  #15915](https://github.com/openai/codex/pull/15915)
  - [[telemetry] turn events
  #15591](https://github.com/openai/codex/pull/15591)
  - [[telemetry] steer events
  #15697](https://github.com/openai/codex/pull/15697)
  - [[telemetry] queued prompt data
  #15804](https://github.com/openai/codex/pull/15804)
  
  Notes:
  - core does not spawn a subagent thread for compact, but represented in
  mapping for consistency
  
  `INFO | 2026-04-01 13:08:12 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:399 | Tracked
  codex_thread_initialized event params={'thread_id':
  '019d4aa9-233b-70f2-a958-c3dbae1e30fa', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': None}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'model': 'gpt-5.3-codex', 'ephemeral':
  False, 'initialization_mode': 'new', 'created_at': 1775074091,
  'thread_source': 'subagent', 'subagent_source': 'thread_spawn',
  'parent_thread_id': '019d4aa8-51ec-77e3-bafb-2c1b8e29e385'} | `
  
  `INFO | 2026-04-01 13:08:41 | codex_backend.routers.analytics_events |
  analytics_events.track_analytics_events:399 | Tracked
  codex_thread_initialized event params={'thread_id':
  '019d4aa9-94e3-75f1-8864-ff8ad0e55e1e', 'product_surface': 'codex',
  'app_server_client': {'product_client_id': 'CODEX_CLI', 'client_name':
  'codex-tui', 'client_version': '0.0.0', 'rpc_transport': 'in_process',
  'experimental_api_enabled': None}, 'runtime': {'codex_rs_version':
  '0.0.0', 'runtime_os': 'macos', 'runtime_os_version': '26.4.0',
  'runtime_arch': 'aarch64'}, 'model': 'gpt-5.3-codex', 'ephemeral':
  False, 'initialization_mode': 'new', 'created_at': 1775074120,
  'thread_source': 'subagent', 'subagent_source': 'review',
  'parent_thread_id': None} | `
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  rhan-oai · 2026-04-04 11:06:43 -07:00
  4fd5c35c4f
• [codex-analytics] thread events (#15690)

  - add event for thread initialization
  - thread/start, thread/fork, thread/resume
  - feature flagged behind `FeatureFlag::GeneralAnalytics`
  - does not yet support threads started by subagents
  
  PR stack:
  - --> [[telemetry] thread events
  #15690](https://github.com/openai/codex/pull/15690)
  - [[telemetry] subagent events
  #15915](https://github.com/openai/codex/pull/15915)
  - [[telemetry] turn events
  #15591](https://github.com/openai/codex/pull/15591)
  - [[telemetry] steer events
  #15697](https://github.com/openai/codex/pull/15697)
  - [[telemetry] queued prompt data
  #15804](https://github.com/openai/codex/pull/15804)
  
  
  Sample extracted logs in Codex-backend
  ```
  INFO     | 2026-03-29 16:39:37 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bf7-9f5f-7f82-9877-6d48d1052531 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774827577 | 
  INFO     | 2026-03-29 16:45:46 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3b84-5731-79d0-9b3b-9c6efe5f5066 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=resumed subagent_source=None parent_thread_id=None created_at=1774820022 | 
  INFO     | 2026-03-29 16:45:49 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bfd-4cd6-7c12-a13e-48cef02e8c4d product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=forked subagent_source=None parent_thread_id=None created_at=1774827949 | 
  INFO     | 2026-03-29 17:20:29 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3c1d-0412-7ed2-ad24-c9c0881a36b0 product_surface=codex product_client_id=CODEX_SERVICE_EXEC client_name=codex_exec client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774830027 | 
  ```
  
  Notes
  - `product_client_id` gets canonicalized in codex-backend
  - subagent threads are addressed in a following pr

  rhan-oai · 2026-03-31 12:16:44 -07:00
  e8de4ea953