58 Commits

• feat(app-server): add history_mode to thread (#29927)

  ## Description
  
  This PR adds a new `historyMode = "legacy" | "paginated"` to `Thread`.
  This will be stored in `SessionMeta` in the JSONL rollout file and as a
  new column in the SQLite thread_metadata table, and exposed on
  `thread/start` and on the `Thread` object in app-server.
  
  ## What changed
  
  - Added canonical `ThreadHistoryMode` with `legacy` and `paginated`,
  defaulting old and new SessionMeta to `legacy`.
  - Carried `history_mode` through core session config, ThreadStore stored
  metadata, local/in-memory stores, rollout metadata extraction, and the
  existing SQLite `threads` table.
  - Added experimental `historyMode` to app-server v2 `Thread` and
  `thread/start`.
  - Made paginated stored threads metadata-discoverable but unsupported
  for legacy full-history reads, `load_history`, live resume, and create
  paths.
  - Regenerated app-server schema fixtures and added
  protocol/state/thread-store/app-server coverage for persistence and
  fail-closed behavior.
  
  ## Compatibility floor
  Because users may be running various versions of Codex binaries on the
  same machine (TUI, Codex App, etc.), we will need to establish a
  compatibility floor for upcoming paginated threads, which will change
  how thread storage reads and writes work.
  
  The overall plan here:
  ```
  Release N:
  - Add historyMode to SessionMeta / Thread / SQLite metadata.
  - Teach binaries to understand paginated threads.
  - If a binary sees `historyMode="paginated"` but does not support the paginated contract, it refuses to resume/mutate the thread.
  - Default remains `"legacy"`.
  
  Release N+1:
  - First-party clients start opting into paginated threads where appropriate.
  - Internal dogfood / staged rollout.
  - Measure old-client usage and paginated-thread unsupported errors.
  
  Release N+2:
  - Only after Release N+ is overwhelmingly deployed, make paginated the default.
  - Accept that a small tail of N-1-or-older binaries may not understand paginated threads.
  ```
  
  The important behavior change is fail-closed handling for a binary that
  encounters a persisted `paginated` thread before it knows how to fully
  support paginated history. In app-server, if a thread is `paginated`, we
  will:
  
  - allow metadata-only discovery paths like `thread/list` and
  `thread/read(includeTurns=false)`, so clients can still see the thread
  and inspect its `historyMode`
  - reject legacy full-history/live-thread paths like
  `thread/read(includeTurns=true)` and `thread/resume` with an unsupported
  JSON-RPC error
  - avoid silently treating an unknown or future `historyMode` as `legacy`
  
  Under the hood, the ThreadStore layer also rejects legacy operations
  that would need to load or replay the full thread history for a
  paginated thread. That gives us the behavior we want for Release N:
  future paginated threads are visible, but this binary fails closed
  instead of trying to operate on them as if they were legacy threads.

  Owen Lin · 2026-06-26 09:12:42 -07:00
  5267e805fb
• [codex] Attribute app-server analytics by thread originator (#29935)

  ## Why
  
  Desktop Work threads and regular Codex threads can share the same
  app-server connection. App-server analytics currently copy
  `product_client_id` from connection metadata for every thread-scoped
  event, so Work thread activity is attributed to the Desktop connection
  instead of the thread's resolved originator. This prevents analytics
  from distinguishing the two products on a shared connection.
  
  ## What changed
  
  - Publish the resolved originator after a thread is materialized,
  covering new, resumed, forked, and subagent threads.
  - Store that originator in the analytics reducer's existing per-thread
  state.
  - Override only `app_server_client.product_client_id` for thread, turn,
  tool, review, goal, guardian, and compaction events while preserving the
  connection's client name, version, and transport metadata.
  - Fall back to the connection-wide product client ID when a thread has
  no originator override.
  - Preserve persisted originators in thread initialization analytics for
  resume and fork flows.
  
  ## Validation
  
  - `just test -p codex-analytics
  thread_originator_overrides_shared_connection_across_thread_events
  subagent_events_keep_thread_originator_with_explicit_turn_connection`
  - `just test -p codex-app-server
  turn_start_tracks_thread_originator_in_analytics
  thread_start_tracks_thread_initialized_analytics
  thread_fork_tracks_thread_initialized_analytics
  thread_resume_tracks_thread_initialized_analytics`
  - `just test -p codex-core thread_manager`

  alexsong-oai · 2026-06-25 18:15:48 -07:00
  841f30598c
• [codex] Surface MCP reauthentication-required startup failures (#29877)

  ## Summary
  
  - distinguish expired, non-refreshable stored MCP OAuth credentials from
  first-time missing credentials
  - carry a typed `failureReason: "reauthenticationRequired"` on the
  existing `mcpServer/startupStatus/updated` notification only when user
  action is required
  - keep the public MCP auth-status API unchanged and regenerate the
  app-server protocol schemas and documentation
  
  ## Why
  
  An MCP server with an expired access token and no usable refresh token
  currently fails startup without giving clients a reliable, typed
  recovery signal.
  
  The existing startup-status notification is the natural place to carry
  this state. Its nullable `failureReason` keeps the recovery reason
  attached to the failed startup transition without adding a one-off
  notification. Internally, Codex distinguishes first-time login from
  reauthentication and emits the reason only when the startup error itself
  requires authentication.
  
  ## User impact
  
  App clients can prompt an existing user to reconnect an MCP server when
  automatic recovery is impossible by handling a failed
  `mcpServer/startupStatus/updated` notification whose `failureReason` is
  `reauthenticationRequired`. Starting, ready, cancelled, unrelated
  failures, and first-time setup carry no reauthentication reason.
  
  ## Companion app PR
  
  - openai/openai#1069582
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` — 248 passed; schema fixture
  tests passed
  - `cargo check -p codex-app-server -p codex-tui`
  - `just test -p codex-rmcp-client -p codex-mcp` — 184 passed, 2 skipped
  - `just test -p codex-protocol -p codex-app-server-protocol -p
  codex-mcp` — 579 passed
  - `just write-app-server-schema`
  - `just fmt`

  felixxia-oai · 2026-06-25 21:50:36 +00:00
  a6d20ed297
• feat: add provider-aware model fallback to thread start (#29942)

  ## Why
  
  Helper threads such as task title generation can request a model ID that
  is valid for the default OpenAI provider but unavailable from the active
  provider. With Amazon Bedrock, `gpt-5.4-mini` is rejected while the
  provider static catalog exposes Bedrock model IDs such as
  `openai.gpt-5.5` and `openai.gpt-5.4`. This causes repeated background
  404s and can surface a misleading turn error even when the main turn
  succeeds.
  
  Clients need an explicit way to ask app-server to resolve an unavailable
  helper model to the active provider default. That fallback must remain
  limited to providers with an authoritative static catalog so custom or
  dynamically discovered model IDs are not rewritten based on an
  incomplete catalog.
  
  Fixes #28741.
  
  ## What changed
  
  - Add the experimental `allowProviderModelFallback` option to
  `thread/start`, defaulting to `false` to preserve existing behavior.
  - Thread the option through thread creation and model selection.
  - When enabled for a static model manager, preserve requested models
  present in the catalog and replace unavailable models with the provider
  default.
  - Continue preserving explicit model IDs for dynamic model managers
  without fetching a catalog solely to validate them.
  - Document the new `thread/start` behavior in the app-server API
  overview.
  
  ## Test
  Temporary test-client harness:
  ```
  ThreadStartParams {
      model: Some("gpt-5.4-mini".to_string()),
      allow_provider_model_fallback: true,
      ..Default::default()
  }
  ```
  Command:
  ```
  CODEX_HOME=/tmp/codex-bedrock-thread-start-home \
  CODEX_E2E_BEDROCK_THREAD_START_ONLY=1 \
  ./target/debug/codex-app-server-test-client \
    --codex-bin ./target/debug/codex \
    -c 'model_provider="amazon-bedrock"' \
    send-message-v2 --experimental-api ignored
  ```
  Relevant output:
  ```
  > "method": "thread/start",
  > "params": {
  >   "model": "gpt-5.4-mini",
  >   "modelProvider": null,
  >   "allowProviderModelFallback": true,
  >   ...
  > }
  
  < "result": {
  <   "model": "openai.gpt-5.5",
  <   "modelProvider": "amazon-bedrock",
  <   ...
  < }
  ```

  Celia Chen · 2026-06-25 18:24:34 +00:00
  6d9dbacf1a
• test: use automatic environments in app-server integration tests (#29789)

  ## Why
  
  Topology-neutral app-server integration tests should exercise automatic
  environment selection so the same setup covers local and remote
  executors.
  
  ## What
  
  Migrate eligible tests to `TestAppServer::new_with_auto_env()` and
  `send_thread_start_request_with_auto_env()`. Leave explicit-topology
  tests unchanged, and skip the request-permissions case on Windows with a
  TODO for cross-platform tool routing.
  
  ## Validation
  
  - `just test -p codex-app-server`
  - `bazel test //codex-rs/app-server:app-server-all-wine-exec-test
  --test_output=errors`
  
  Stacked on #29788.

  Adam Perry @ OpenAI · 2026-06-23 22:48:06 -07:00
  c2b3e3b4f5
• core: load AGENTS.md from foreign environments (#28958)

  ## Why
  
  Make it possible to load AGENTS.md from remote exec-servers whose OS is
  different than app-server.
  
  ## What
  
  - keep `AGENTS.md` discovery and provenance as `PathUri`, with
  root-aware parent and ancestor traversal
  - expose lifecycle instruction sources as legacy app-server path strings
  in events while retaining `PathUri` internally
  - preserve and test mixed POSIX and Windows paths in model context and
  TUI status output
  - cover remote Windows loading end to end by seeding the Wine prefix
  through host filesystem APIs
  - fix bug in `PathUri`'s parent() implementation that would erase
  Windows drive letters

  Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00
  dce673905a
• app-server: preserve target-native environment cwd (#28146)

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

  Adam Perry @ OpenAI · 2026-06-16 21:42:28 +00:00
  f8850cab1d
• [codex] Load user instructions through an injected provider (#27101)

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

  Adam Perry @ OpenAI · 2026-06-11 19:28:47 +00:00
  236b50125d
• fix(tui): scope MCP startup status by thread (#26639)

  ## Why
  
  MCP startup failures from spawned subagents were rendered as global
  notifications, so a child thread's failure could pollute the visible
  parent transcript. Routing the notification to the child exposed two
  related replay problems: session refresh could discard the buffered
  event, and a newly created child `ChatWidget` did not know the expected
  MCP server set, which could leave its startup spinner running after
  every server had settled.
  
  MCP startup diagnostics should remain visible in the thread that owns
  the startup without affecting other transcripts. The protocol also needs
  to support a future app-scoped MCP lifecycle where startup is not owned
  by any thread.
  
  ## Reported Behavior
  
  The [originating Slack
  report](https://openai.slack.com/archives/C08JZTV654K/p1780604538859939)
  called out that using subagents could turn MCP startup failures into a
  wall of yellow CLI warnings because repeated failures were not
  deduplicated. The intended behavior is for those diagnostics to remain
  visible once in the thread that owns the startup, without polluting the
  parent transcript.
  
  ## What Changed
  
  - add nullable `threadId` ownership to `mcpServer/startupStatus/updated`
  - populate it from the app-server conversation ID for the current
  thread-scoped lifecycle and regenerate the protocol schema and
  TypeScript artifacts
  - treat a missing or null `threadId` as app-scoped without injecting it
  into the active chat transcript
  - route and buffer thread-owned MCP startup notifications by thread in
  the TUI
  - preserve buffered MCP startup events across child session refresh
  - seed expected MCP servers before replaying a thread snapshot so
  startup reaches its terminal state
  - suppress an identical repeated failure warning for the same server
  within one startup round
  
  The owning thread still renders the detailed failure and final `MCP
  startup incomplete (...)` summary.
  
  ## How to Test
  
  1. Configure an optional MCP server named `smoke` that exits during
  initialization.
  2. Launch the TUI with multi-agent support enabled.
  3. Confirm the main thread's own startup failure renders one detailed
  `smoke` warning and one incomplete-startup summary.
  4. Spawn exactly one subagent.
  5. Confirm the parent transcript does not receive the subagent's MCP
  startup failure.
  6. Switch to the subagent thread and confirm it contains exactly one
  detailed `smoke` failure and one incomplete-startup summary.
  7. Confirm the subagent's MCP startup spinner disappears and the thread
  remains usable.
  8. Switch between the parent and subagent and confirm the warnings
  neither move nor duplicate.
  
  Targeted tests:
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  thread_start_emits_mcp_server_status_updated_notifications`
  - `just test -p codex-tui mcp_startup`
  
  The parent/child behavior and spinner completion were also exercised
  manually in tmux. `just argument-comment-lint` was attempted but blocked
  by an unrelated local Bazel LLVM empty-glob failure; touched Rust
  callsites were inspected manually.

  Felipe Coury · 2026-06-07 20:12:05 -07:00
  5a440c03f2
• Make runtime workspace roots absolute in app-server API (#26552)

  Stacked on #26532.
  
  ## Why
  
  #26532 moves cwd normalization to the app-server/core boundary.
  `runtimeWorkspaceRoots` still accepted raw paths in v2 requests and in
  `ConfigOverrides`, which left core responsible for interpreting those
  roots later. This makes runtime workspace roots follow the same
  absolute-path boundary as cwd.
  
  ## What
  
  - Change v2 `runtimeWorkspaceRoots` request fields for `thread/start`,
  `thread/resume`, `thread/fork`, and `turn/start` to `AbsolutePathBuf`.
  - Deduplicate already-absolute runtime roots in app-server handlers and
  pass them through `ConfigOverrides.workspace_roots` as
  `AbsolutePathBuf`.
  - Update TUI and exec client request builders to pass absolute runtime
  roots directly.
  - Update app-server docs, schema fixtures, and focused tests for
  absolute runtime roots.
  
  ## Testing
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server runtime_workspace_roots`
  - `just test -p codex-core
  session_permission_profile_rebinds_runtime_workspace_roots`
  - `just test -p codex-tui app_server_session`
  - `just test -p codex-exec`

  pakrym-oai · 2026-06-05 11:36:53 -07:00
  76c0a5379c
• [codex] Preserve logical paths during AGENTS.md discovery (#26465)

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

  Adam Perry @ OpenAI · 2026-06-04 15:08:52 -07:00
  59ca34206b
• Route AGENTS.md loading through environment filesystems (#26205)

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

  Adam Perry @ OpenAI · 2026-06-04 12:43:07 -07:00
  e64b469bbc
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• app-server: remove experimental persist_extended_history bool flag (#25712)

  ## Summary
  
  Remove the dead experimental `persistExtendedHistory` app-server flag
  and collapse rollout persistence to the single policy app-server already
  used.
  
  ## What Changed
  
  - Removed `persistExtendedHistory` from v2 thread start/resume/fork
  params and deleted its deprecation notice path.
  - Removed the persistence-mode enums and plumbing through core, rollout,
  and thread-store.
  - Made rollout filtering mode-free, keeping the existing limited
  persisted-history behavior.
  
  ## Test Plan
  
  - `just write-app-server-schema`
  - `cargo nextest run --no-fail-fast -p codex-app-server-protocol
  schema_fixtures`
  - `cargo nextest run --no-fail-fast -p codex-app-server
  thread_shell_command_history_responses_exclude_persisted_command_executions`
  - `cargo nextest run --no-fail-fast -p codex-rollout -p
  codex-thread-store`
  - final `rg` for removed flag/type names

  Owen Lin · 2026-06-01 23:33:42 +00:00
  11e0f3d3ae
• fix: rename McpServer to TestAppServer (#25701)

  This PR brought to you via VS Code rather than Codex...
  
  - opened `codex-rs/app-server/tests/common/mcp_process.rs`
  - put the cursor on `McpServer`
  - hit `F2` and renamed the symbol to `TestAppServer`
  - went to the file tree
  - hit enter and renamed `mcp_process.rs` to `test_app_server.rs`
  - ran **Save All Files** from the Command Palette
  - ran `just fmt`
  
  The End
  
  (Admittedly, most of the local variables for `TestAppServer` are still
  named `mcp`, though.)

  Michael Bolin · 2026-06-01 21:49:38 +00:00
  6536841d89
• [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
• Honor client-resolved service tier defaults (#23537)

  ## Why
  
  Model catalog responses can now advertise a nullable
  `default_service_tier` for each model. Codex needs to preserve three
  distinct states all the way from config/app-server inputs to inference:
  
  - no explicit service tier, so the client may apply the current model
  catalog default when FastMode is enabled
  - explicit `default`, meaning the user intentionally wants standard
  routing
  - explicit catalog tier ids such as `priority`, `flex`, or future tiers
  
  Keeping those states distinct prevents the UI from showing one tier
  while core sends another, especially after model switches or app-server
  `thread/start` / `turn/start` updates.
  
  ## What Changed
  
  - Plumbed `default_service_tier` through model catalog protocol types,
  app-server model responses, generated schemas, model cache fixtures, and
  provider/model-manager conversions.
  - Added the request-only `default` service tier sentinel and normalized
  legacy config spelling so `fast` in `config.toml` still materializes as
  the runtime/request id `priority`.
  - Moved catalog default resolution to the TUI/client side, including
  recomputing the effective service tier when model/FastMode-dependent
  surfaces change.
  - Updated app-server thread lifecycle config construction so
  `serviceTier: null` preserves explicit standard-routing intent by
  mapping to `default` instead of internal `None`.
  - Kept core responsible for validating explicit tiers against the
  current model and stripping `default` before `/v1/responses`, without
  applying catalog defaults itself.
  
  ## Validation
  
  - `CARGO_INCREMENTAL=0 cargo build -p codex-cli`
  - `CARGO_INCREMENTAL=0 cargo test -p codex-app-server model_list`
  - `cargo test -p codex-tui service_tier`
  - `cargo test -p codex-protocol service_tier_for_request`
  - `cargo test -p codex-core get_service_tier`
  - `RUST_MIN_STACK=8388608 CARGO_INCREMENTAL=0 cargo test -p codex-core
  service_tier`

  Shijie Rao · 2026-05-20 15:57:50 -07:00
  370b13afc9
• app-server: use permission ids and runtime workspace roots (#22611)

  ## Why
  
  This PR builds on [#22610](https://github.com/openai/codex/pull/22610)
  and is the app-server side of the migration from mutable per-turn
  `SandboxPolicy` replacement toward selecting immutable permission
  profiles by id plus mutable runtime workspace roots.
  
  Once permission profiles can carry their own immutable
  `workspace_roots`, app-server no longer needs to mutate the selected
  `PermissionProfile` just to represent thread-specific filesystem
  context. The mutable part now lives on the thread as explicit
  `runtimeWorkspaceRoots`, while `:workspace_roots` remains symbolic until
  the sandbox is realized for a turn.
  
  ## What Changed
  
  - Replaced the v2 permission-selection wrapper surface with plain
  profile ids for `thread/start`, `thread/resume`, `thread/fork`, and
  `turn/start`.
  - Removed the API surface for profile modifications
  (`PermissionProfileSelectionParams`,
  `PermissionProfileModificationParams`,
  `ActivePermissionProfileModification`).
  - Added experimental `runtimeWorkspaceRoots` fields to the thread
  lifecycle and turn-start APIs.
  - Threaded runtime workspace roots through core session/thread
  snapshots, turn overrides, app-server request handling, and command
  execution permission resolution.
  - Kept session permission state symbolic so later runtime root updates
  and cwd-only implicit-root retargeting rebind `:workspace_roots`
  correctly.
  - Updated the embedded clients just enough to send and restore the new
  thread state.
  - Refreshed the generated schema/TypeScript artifacts and the app-server
  README to match the new contract.
  
  ## Verification
  
  Targeted coverage for this layer lives in:
  
  - `codex-rs/app-server-protocol/src/protocol/v2/tests.rs`
  - `codex-rs/app-server/tests/suite/v2/thread_start.rs`
  - `codex-rs/app-server/tests/suite/v2/thread_resume.rs`
  - `codex-rs/app-server/tests/suite/v2/turn_start.rs`
  - `codex-rs/core/src/session/tests.rs`
  
  The key regression checks exercise that:
  
  - `runtimeWorkspaceRoots` resolve against the effective cwd on thread
  start.
  - Profile-declared workspace roots are excluded from the runtime
  workspace roots returned by app-server.
  - A turn-level runtime workspace-root update persists onto the thread
  and is returned by `thread/resume`.
  - A named permission profile selected on one turn remains symbolic so a
  later runtime-root-only turn update changes the actual sandbox writes.
  - A cwd-only turn update retargets the implicit runtime cwd root while
  preserving additional runtime roots.
  - The protocol fixtures and generated client artifacts stay in sync with
  the string-based permission selection contract.
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22611).
  * #22612
  * __->__ #22611

  Michael Bolin · 2026-05-14 23:00:05 -07:00
  8a5306ff88
• 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
• 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
• [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
• app-server: ignore persist_extended_history param (#21225)

  ## Why
  
  Taking a step to removing the `persistExtendedHistory` field. It's not
  scalable to be persisting so much data in the rollout file and returning
  it in the thread history.
  
  When a client explicitly sends `true`, the server now tells that client
  the parameter is deprecated and ignored so the caller has a clear
  migration signal via the `deprecationNotice` notification.
  
  ## What changed
  
  - Keep the `persist_extended_history` / `persistExtendedHistory` field
  in the v2 protocol for compatibility, but document it as deprecated and
  ignored.
  - Ignore the parameter in app-server `thread/start`, `thread/resume`,
  and `thread/fork`; those paths always use limited history persistence
  now.
  - Stop treating `persistExtendedHistory` as a running-thread resume
  override mismatch.
  - Emit a connection-scoped `deprecationNotice` when a request explicitly
  sets `persist_extended_history: true`.
  
  ## Verification
  
  - Added `thread_start_deprecates_persist_extended_history_true` to cover
  the deprecation notice.
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-app-server-protocol`

  Owen Lin · 2026-05-05 18:36:13 +00:00
  6075b77001
• [codex-analytics] remove ga flag (#19863)
  rhan-oai · 2026-04-27 19:29:19 +00:00
  215d5a8f7c
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• Add sticky environment API and thread state (#18897)

  ## Summary
  - add sticky environment selections to app-server v2 thread/start and
  turn/start request flow
  - carry thread-level selections through core session/thread state
  - add app-server coverage for sticky selections and turn overrides
  
  ## Stack
  1. This PR: API and thread persistence
  2. #18898: config.toml named environment loading
  3. #18899: downstream tool/runtime consumers
  
  ## Validation
  - Not run locally; split only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-23 18:57:13 -07:00
  49fb25997f
• Respect explicit untrusted project config (#18626)

  ## Why
  
  Fixes #18475. A `-c` override such as `projects.<cwd>.trust_level =
  "untrusted"` is meant to be a runtime config override, but app-server
  thread startup treated any non-trusted project as eligible for automatic
  trust persistence when a permissive sandbox/cwd was requested. That
  meant an explicit `untrusted` session override could still cause
  `config.toml` to be updated with `trusted`.
  
  ## What changed
  
  The app-server auto-trust path now runs only when the active project
  trust level is unknown. Explicit `trusted` and explicit `untrusted`
  values are both respected, regardless of whether they came from
  persisted config or session flags.
  
  A focused `thread/start` test now covers the explicit `untrusted` case
  with a permissive sandbox request.
  
  ## Verification
  
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server`

  Eric Traut · 2026-04-23 10:51:17 -07:00
  c2423f42d1
• Update models.json (#18586)

  - Replace the active models-manager catalog with the deleted core
  catalog contents.
  - Replace stale hardcoded test model slugs with current bundled model
  slugs.
  - Keep this as a stacked change on top of the cleanup PR.

  Ahmed Ibrahim · 2026-04-20 10:27:01 -07:00
  316cf0e90b
• fix: trust-gate project hooks and exec policies (#14718)

  ## Summary
  - trust-gate project `.codex` layers consistently, including repos that
  have `.codex/hooks.json` or `.codex/execpolicy/*.rules` but no
  `.codex/config.toml`
  - keep disabled project layers in the config stack so nested trusted
  project layers still resolve correctly, while preventing hooks and exec
  policies from loading until the project is trusted
  - update app-server/TUI onboarding copy to make the trust boundary
  explicit and add regressions for loader, hooks, exec-policy, and
  onboarding coverage
  
  ## Security
  Before this change, an untrusted repo could auto-load project hooks or
  exec policies from `.codex/` as long as `config.toml` was absent. This
  makes trust the single gate for project-local config, hooks, and exec
  policies.
  
  ## Stack
  - Parent of #15936
  
  ## Test
  - cargo test -p codex-core without_config_toml
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-17 17:56:58 -07:00
  370bed4bf4
• Refactor config loading to use filesystem abstraction (#18209)

  Initial pass propagating FileSystem through config loading.

  pakrym-oai · 2026-04-17 00:51:21 +00:00
  9effa0509f
• Async config loading (#18022)

  Parts of config will come from executor. Prepare for that by making
  config loading methods async.

  pakrym-oai · 2026-04-15 19:18:38 -07:00
  bd61737e8a
• Spread AbsolutePathBuf (#17792)

  Mechanical change to promote absolute paths through code.

  pakrym-oai · 2026-04-14 14:26:10 -07:00
  dd1321d11b
• [codex-analytics] enable general analytics by default (#17389)

  ## Summary
  - Make GeneralAnalytics stable and enabled by default.
  - Update feature tests and app-server lifecycle fixtures for explicit
  general_analytics=false.
  - Keep app-server integration tests isolated from host managed config so
  explicit feature fixtures are deterministic.
  
  ## Validation
  - cargo test -p codex-features
  - cargo test -p codex-app-server general_analytics (matched 0 tests)
  - cargo test -p codex-app-server thread_start_
  - cargo test -p codex-app-server thread_fork_
  - cargo test -p codex-app-server thread_resume_
  - cargo test -p codex-app-server
  config_read_includes_system_layer_and_overrides

  rhan-oai · 2026-04-14 13:20:46 -07:00
  d6b13276c7
• [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
• Expose instruction sources (AGENTS.md) via app server (#17506)

  Addresses #17498
  
  Problem: The TUI derived /status instruction source paths from the local
  client environment, which could show stale <none> output or incorrect
  paths when connected to a remote app server.
  
  Solution: Add an app-server v2 instructionSources snapshot to thread
  start/resume/fork responses, default it to an empty list when older
  servers omit it, and render TUI /status from that server-provided
  session data.
  
  Additional context: The app-server field is intentionally named
  instructionSources rather than AGENTS.md-specific terminology because
  the loaded instruction sources can include global instructions, project
  AGENTS.md files, AGENTS.override.md, user-defined instruction files, and
  future dynamic sources.

  Eric Traut · 2026-04-12 15:50:12 -07:00
  46ab9974dc
• Refactor config types into a separate crate (#16962)

  Move config types into a separate crate because their macros expand into
  a lot of new code.

  pakrym-oai · 2026-04-07 00:32:41 +00:00
  1f2411629f
• [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
• Fix Windows Bazel app-server trust tests (#16711)

  ## Why
  
  Extracted from [#16528](https://github.com/openai/codex/pull/16528) so
  the Windows Bazel app-server test failures can be reviewed independently
  from the rest of that PR.
  
  This PR targets:
  
  -
  `suite::v2::thread_shell_command::thread_shell_command_runs_as_standalone_turn_and_persists_history`
  -
  `suite::v2::thread_start::thread_start_with_elevated_sandbox_trusts_project_and_followup_loads_project_config`
  -
  `suite::v2::thread_start::thread_start_with_nested_git_cwd_trusts_repo_root`
  
  There were two Windows-specific assumptions baked into those tests and
  the underlying trust lookup:
  
  - project trust keys were persisted and looked up using raw path
  strings, but Bazel's Windows test environment can surface canonicalized
  paths with `\\?\` / UNC prefixes or normalized symlink/junction targets,
  so follow-up `thread/start` requests no longer matched the project entry
  that had just been written
  - `item/commandExecution/outputDelta` assertions compared exact trailing
  line endings even though shell output chunk boundaries and CRLF handling
  can differ on Windows, and Bazel made that timing-sensitive mismatch
  visible
  
  There was also one behavior bug separate from the assertion cleanup:
  `thread/start` decided whether to persist trust from the final resolved
  sandbox policy, but on Windows an explicit `workspace-write` request may
  be downgraded to `read-only`. That incorrectly skipped writing trust
  even though the request had asked to elevate the project, so the new
  logic also keys off the requested sandbox mode.
  
  ## What
  
  - Canonicalize project trust keys when persisting/loading `[projects]`
  entries, while still accepting legacy raw keys for existing configs.
  - Persist project trust when `thread/start` explicitly requests
  `workspace-write` or `danger-full-access`, even if the resolved policy
  is later downgraded on Windows.
  - Make the Windows app-server tests compare persisted trust paths and
  command output deltas in a path/newline-normalized way.
  
  ## Verification
  
  - Existing app-server v2 tests cover the three failing Windows Bazel
  cases above.

  Michael Bolin · 2026-04-03 21:41:25 +00:00
  a70aee1a1e
• Auto-trust cwd on thread start (#16492)

  - Persist trusted cwd state during thread/start when the resolved
  sandbox is elevated.
  - Add app-server coverage for trusted root resolution and confirm
  turn/start does not mutate trust.

  Ahmed Ibrahim · 2026-04-03 00:02:56 +00:00
  95e809c135
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• [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
• [codex-cli][app-server] Update self-serve business usage limit copy in error returned (#15478)

  ## Summary
  - update the self-serve business usage-based limit message to direct
  users to their admin for additional credits
  - add a focused unit test for the self_serve_business_usage_based plan
  branch
  
  Added also: 
  
  If you are at a rate limit but you still have credits, codex cli would
  tell you to switch the model. We shouldnt do this if you have credits so
  fixed this.
  
  ## Test
  - launched the source-built CLI and verified the updated message is
  shown for the self-serve business usage-based plan
  
  ![Test
  screenshot](https://raw.githubusercontent.com/openai/codex/5cc3c013ef17ac5c66dfd9395c0d3c4837602231/docs/images/self-serve-business-usage-limit.png)

  dhruvgupta-oai · 2026-03-24 04:41:38 +00:00
  c2410060ea
• feat(app-server): add mcpServer/startupStatus/updated notification (#15220)

  Exposes the legacy `codex/event/mcp_startup_update` event as an API v2
  notification.
  
  The legacy event has this shape:
  ```
  #[derive(Debug, Clone, Deserialize, Serialize, JsonSchema, TS)]
  pub struct McpStartupUpdateEvent {
      /// Server name being started.
      pub server: String,
      /// Current startup status.
      pub status: McpStartupStatus,
  }
  
  #[derive(Debug, Clone, Deserialize, Serialize, JsonSchema, TS)]
  #[serde(rename_all = "snake_case", tag = "state")]
  #[ts(rename_all = "snake_case", tag = "state")]
  pub enum McpStartupStatus {
      Starting,
      Ready,
      Failed { error: String },
      Cancelled,
  }
  ```

  Owen Lin · 2026-03-19 15:09:59 -07:00
  9e695fe830
• Refactor cloud requirements error and surface in JSON-RPC error (#14504)

  Refactors cloud requirements error handling to carry structured error
  metadata and surfaces that metadata through JSON-RPC config-load
  failures, including:
  * adds typed CloudRequirementsLoadErrorCode values plus optional
  statusCode
  * marks thread/start, thread/resume, and thread/fork config failures
  with structured cloud-requirements error data

  alexsong-oai · 2026-03-13 03:30:51 +00:00
  650beb177e
• support 'flex' tier in app-server in addition to 'fast' (#13391)
  Val Kharitonov · 2026-03-03 22:46:05 -08:00
  4f6c4bb143
• app-server: Silence thread status changes caused by thread being created (#13079)

  Currently we emit `thread/status/changed` with `Idle` status right
  before sending `thread/started` event (which also has `Idle` status in
  it).
  It feels that there is no point in that as client has no way to know
  prior state of the thread as it didn't exist yet, so silence these kinds
  of notifications.

  Ruslan Nigmatullin · 2026-03-03 00:52:28 +00:00
  9022cdc563
• app-server: Add ephemeral field to Thread object (#13084)

  Currently there is no alternative way to know that thread is ephemeral,
  only client which did create it has the knowledge.

  Ruslan Nigmatullin · 2026-02-27 17:42:25 -08:00
  8c1e3f3e64
• feat: add service name to app-server (#12319)

  Add service name to the app-server so that the app can use it's own
  service name
  
  This is on thread level because later we might plan the app-server to
  become a singleton on the computer

  jif-oai · 2026-02-25 09:51:42 +00:00
  10c04e11b8
• Add field to Thread object for the latest rename set for a given thread (#12301)

  Exposes through the app server updated names set for a thread. This
  enables other surfaces to use the core as the source of truth for thread
  naming. `threadName` is gathered using the helper functions used to
  interact with `session_index.jsonl`, and is hydrated in:
  - `thread/list`
  - `thread/read`
  - `thread/resume`
  - `thread/unarchive`
  - `thread/rollback`
  
  We don't do this for `thread/start` and `thread/fork`.

  natea-oai · 2026-02-20 18:26:57 -08:00
  936e744c93
• app-server: expose loaded thread status via read/list and notifications (#11786)

  Motivation
  - Today, a newly connected client has no direct way to determine the
  current runtime status of threads from read/list responses alone.
  - This forces clients to infer state from transient events, which can
  lead to stale or inconsistent UI when reconnecting or attaching late.
  
  Changes
  - Add `status` to `thread/read` responses.
  - Add `statuses` to `thread/list` responses.
  - Emit `thread/status/changed` notifications with `threadId` and the new
  status.
  - Track runtime status for all loaded threads and default unknown
  threads to `idle`.
  - Update protocol/docs/tests/schema fixtures for the revised API.
  
  Testing
  - Validated protocol API changes with automated protocol tests and
  regenerated schema/type fixtures.
  - Validated app-server behavior with unit and integration test suites,
  including status transitions and notifications.

  Ruslan Nigmatullin · 2026-02-18 15:20:03 -08:00
  1f54496c48