89 Commits

• Move cloud requirements crate to cloud config (#24621)

  ## Summary
  
  - Moves the existing `codex-cloud-requirements` crate to
  `codex-cloud-config`.
  - Updates workspace dependencies and imports to the new crate name.
  - Intentionally keeps runtime behavior unchanged: this still fetches the
  legacy cloud requirements endpoint.
  
  ## Details
  
  This PR exists to make the lineage obvious before the bundle migration.
  GitHub should show the old `codex-rs/cloud-requirements/src/lib.rs`
  implementation as moved to `codex-rs/cloud-config/src/lib.rs`, rather
  than as unrelated new code.
  
  The follow-up PR adapts this moved crate to the new config bundle API
  and switches runtime consumers over.

  joeflorencio-openai · 2026-06-01 16:43:52 -07:00
  0b3a6f7185
• Add feature-gated standalone image generation extension (#24723)

  ## Why
  
  Add a standalone image generation path that can be exercised
  independently of hosted Responses image generation, while retaining the
  hosted tool as fallback unless the extension is actually available to
  the model.
  
  ## What changed
  
  - Added the `codex-image-generation-extension` crate with standalone
  generate/edit execution, prior-image selection for edits, model-visible
  image output, and local generated-image persistence.
  - Installed the extension in app-server behind the disabled-by-default
  `imagegenext` feature and backend eligibility checks.
  - Updated core tool planning so eligible `image_gen.imagegen` exposure
  replaces hosted `image_generation`, while unavailable configurations
  retain hosted fallback.
  - Added coverage for extension behavior, edit history reuse, feature
  gating, auth eligibility, and hosted-tool replacement.
  - The extension is installed through app-server only in this PR; other
  execution paths retain hosted image generation because hosted
  replacement occurs only when the standalone executor is actually
  registered and model-visible.
  - The initial extension contract intentionally fixes the image model to
  `gpt-image-2` and uses automatic image parameters.
  - Native generated-image history/card parity and rollout persistence
  cleanup are intentionally deferred follow-up work.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-features`
  - `just test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`
  - `just test -p codex-app-server`
  - `just fix -p codex-image-generation-extension -p codex-features -p
  codex-core -p codex-app-server`
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Won Park · 2026-05-28 11:44:55 -07:00
  ecb41fcb64
• Attach Windows sandbox log to feedback reports (#24623)

  ## Why
  
  Windows sandbox diagnostics are currently hard to recover from
  `/feedback` even though they are often the most useful artifact when
  debugging sandbox behavior. Now that sandbox logging uses daily rolling
  files, feedback can safely include the current day's sandbox log without
  uploading the old ever-growing legacy `sandbox.log`.
  
  ## What changed
  
  - Add a `codex-windows-sandbox` helper that resolves the current daily
  sandbox log from `codex_home`.
  - When feedback is submitted with logs enabled on Windows, app-server
  attaches today's sandbox log if it exists.
  - Upload the attachment under the stable filename `windows-sandbox.log`,
  independent of the dated on-disk filename.
  - Keep existing raw `extra_log_files` behavior unchanged for rollout and
  desktop log attachments.
  
  ## Verification
  
  - `cargo fmt -p codex-app-server -p codex-windows-sandbox`
  - `cargo test -p codex-windows-sandbox
  current_log_file_path_for_codex_home_uses_sandbox_dir`
  - `cargo test -p codex-app-server
  windows_sandbox_log_attachment_uses_current_log`
  - Manual CLI/TUI `/feedback` test confirmed Sentry received
  `windows-sandbox.log`.

  iceweasel-oai · 2026-05-26 15:59:25 -07:00
  9826581e7b
• standalone websearch extension (#23823)

  ## Summary
  
  Add the extension-backed standalone `web.run` tool so Codex can call the
  standalone search endpoint through the `codex-api` search client and
  return its encrypted output to Responses.
  
  - gate the new tool behind `standalone_web_search`
  - install the extension in the app-server thread registry and hide
  hosted `web_search` when standalone search is enabled for OpenAI
  providers so the two paths stay mutually exclusive
  - build search context from persisted history using a small tail
  heuristic: previous user message, assistant text between the last two
  user turns capped at about 1k tokens, and current user message
  
  ## Test Plan
  
  - `cargo test -p codex-web-search-extension`
  - `cargo test -p codex-api`
  - `cargo test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`

  sayan-oai · 2026-05-26 11:12:24 -07:00
  a22706dfae
• Move memory prompt injection to app-server extension (#22841)

  ## Why
  
  Memory prompt injection should be owned by the extension path that
  app-server composes at runtime, not by an inlined special case inside
  `codex-core`. This keeps `codex-core` focused on session orchestration
  while allowing the memories extension to own its app-server prompt
  behavior.
  
  ## What Changed
  
  - Registers `codex-memories-extension` in the app-server extension
  registry.
  - Moves the memory developer-instruction injection out of
  `core/src/session/mod.rs` and into the memories extension prompt
  contributor.
  - Adds config-change handling so the extension keeps its per-thread
  memory settings in sync after startup.
  - Leaves memories read/retrieval tools unregistered for now so this PR
  only changes prompt injection.
  - Removes the stale `cargo-shear` ignore now that app-server depends on
  the extension crate.
  
  ## Validation
  
  Not run locally; validation is left to CI.

  jif-oai · 2026-05-15 16:19:34 +02:00
  cccde930ce
• chore(config) rm Feature::CodexGitCommit (#22412)

  ## Summary
  Removes the unused Feature::CodexGitCommit
  
  ## Testing
  - [x] tests pass

  Dylan Hurd · 2026-05-13 12:33:36 -07:00
  d18a7c982e
• Restore app-server websocket listener with auth guard (#22404)

  ## Why
  PR #21843 removed the TCP websocket app-server listener, but that also
  removed functionality that still needs to exist. Restoring it as-is
  would reopen the old remote exposure problem, so this keeps the restored
  listener while making remote and non-loopback usage require explicit
  auth.
  
  ## What Changed
  - Mostly reverts #21843 and reapplies the small merge-conflict
  resolutions needed on top of current main.
  - Restores ws://IP:PORT parsing, the app-server TCP websocket acceptor,
  websocket auth CLI flags, and the associated tests.
  - The only intentional behavior change from the restored code is that
  non-loopback websocket listeners now fail startup unless --ws-auth
  capability-token or --ws-auth signed-bearer-token is configured.
  Loopback listeners remain available for local and SSH-forwarding
  workflows.
  
  ## Reviewer Focus
  Please focus review on the small auth-enforcement delta layered on top
  of the revert:
  
  - codex-rs/app-server-transport/src/transport/websocket.rs:
  start_websocket_acceptor now rejects unauthenticated non-loopback
  websocket binds before accepting connections.
  - codex-rs/app-server-transport/src/transport/auth.rs: helper logic
  classifies unauthenticated non-loopback listeners.
  - codex-rs/app-server/tests/suite/v2/connection_handling_websocket.rs:
  tests cover unauthenticated ws://0.0.0.0 startup rejection and
  authenticated non-loopback capability-token startup.
  
  Everything else is intended to be revert/merge-conflict restoration
  rather than new product behavior.
  
  ## Verification
  
  - Manually verified that TUI remoting is restored and that auth is
  enforced for non-localhost urls.

  Eric Traut · 2026-05-12 18:40:53 -07:00
  51bfb5f3b1
• feat: guardian as an extension (contributors part) (#22216)

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

  jif-oai · 2026-05-12 14:41:45 +02:00
  d996f5366f
• app-server: remove TCP websocket listener (#21843)

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

  Ruslan Nigmatullin · 2026-05-11 10:17:26 -07:00
  a124ddb854
• extension: move git attribution into an extension (#21738)

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

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

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

  jif-oai · 2026-05-11 11:38:18 +02:00
  436c0df658
• Move file watcher out of core (#21290)

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

  pakrym-oai · 2026-05-08 18:19:23 -07:00
  c579da41b1
• Disable empty Cargo test targets (#21584)

  ## Summary
  
  `cargo test` has entails both running standard Rust tests and doctests.
  It turns out that the doctest discovery is fairly slow, and it's a cost
  you pay even for crates that don't include any doctests.
  
  This PR disables doctests with `doctest = false` for crates that lack
  any doctests.
  
  For the collection of crates below, this speeds up test execution by
  >4x.
  
  E.g., before this PR:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):      1.849 s ±  4.455 s    [User: 0.752 s, System: 1.367 s]
    Range (min … max):    0.418 s … 14.529 s    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):     428.6 ms ±   6.9 ms    [User: 187.7 ms, System: 219.7 ms]
    Range (min … max):   418.0 ms … 436.8 ms    10 runs
  ```
  
  For a single crate, with >2x speedup, before:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     491.1 ms ±   9.0 ms    [User: 229.8 ms, System: 234.9 ms]
    Range (min … max):   480.9 ms … 512.0 ms    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     213.9 ms ±   4.3 ms    [User: 112.8 ms, System: 84.0 ms]
    Range (min … max):   206.8 ms … 221.0 ms    13 runs
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-07 15:44:17 -07:00
  54ef99a365
• Upgrade cargo-shear to 1.11.2 (#21547)

  ## Summary
  
  Catches a few additional dependencies (`sha2`, `url`) that should be in
  `dev-dependencies`.

  Charlie Marsh · 2026-05-07 11:07:18 -07:00
  0dc1885a5c
• device-key: clean up unused crate (#21487)
  Ruslan Nigmatullin · 2026-05-07 09:01:44 -07:00
  e64a8979b0
• app-server: move transport into dedicated crate (#20545)

  ## Why
  
  `codex-app-server` currently owns both request-processing code and
  transport implementation details. Splitting the transport layer into its
  own crate makes that boundary explicit, reduces the amount of
  transport-specific dependency surface carried by `codex-app-server`, and
  gives future transport work a narrower place to evolve.
  
  ## What changed
  
  - Added `codex-app-server-transport` and moved the existing transport
  tree into it, including stdio, unix socket, websocket, remote-control
  transport, and websocket auth.
  - Moved shared transport-facing message types into the new crate so both
  the transport implementation and `codex-app-server` use the same
  definitions.
  - Kept processor-facing connection state and outbound routing in
  `codex-app-server`, with the routing tests moved next to that local
  wrapper.
  - Updated workspace metadata, Bazel crate metadata, and
  `codex-app-server` dependencies for the new crate boundary.
  
  ## Validation
  
  - `cargo metadata --locked --no-deps`
  - `git diff --check`
  - Attempted `cargo test -p codex-app-server-transport`, `cargo test -p
  codex-app-server`, `just fix -p codex-app-server-transport`, and `just
  fix -p codex-app-server`; all were blocked before compilation by the
  existing `packageproxy` resolution failure for locked `rustls-webpki =
  0.103.13`.
  - Attempted Bazel build / lockfile validation; those were blocked by
  external fetch failures against BuildBuddy / GitHub while resolving
  `v8`.

  Ruslan Nigmatullin · 2026-05-01 09:23:47 -07:00
  41e171fcf2
• Move plugin out of core. (#20348)
  xl-openai · 2026-04-30 14:26:14 -07:00
  7b3de63041
• Add hooks/list app-server RPC (#19778)

  ## Why
  
  We need a way to list the available hooks to expose via the TUI and App
  so users can view and manage their hooks
  
  ## What
  
  - Adds `hooks/list` for one or more `cwd` values that returns discovered
  hook metadata
  
  ## Stack
  
  1. openai/codex#19705
  2. This PR - openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Review Notes
  
  The generated schema files account for most of the raw diff, these files
  have the core change:
  
  - `hooks/src/engine/discovery.rs` builds the inventory entries during
  hook discovery while leaving runtime handlers focused on execution.
  - `app-server/src/codex_message_processor.rs` wires `hooks/list` into
  the app-server flow for each requested `cwd`.
  - `app-server-protocol/src/protocol/v2.rs` defines the new v2
  request/response payloads exposed on the wire.
  
  ### Core Changes
  
  `core/src/plugins/manager.rs` adds `plugins_for_layer_stack(...)` so
  `skills/list` and `hooks/list`can resolve plugin state for each
  requested `cwd`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-29 23:39:57 +00:00
  8774229a89
• Support detect and import MCP, Subagents, hooks, commands from external (#19949)

  ## Why
  This PR expands the migration path so Codex can detect and import MCP
  server config, hooks, commands, and subagents configs in a Codex-native
  shape.
  
  ## What changed
  
  - Added a `codex-external-agent-migration` crate that owns conversion
  logic for external-agent MCP servers, hooks, commands, and subagents.
  - Extended the app-server external-agent config detection/import API
  with migration item types for MCP server config, hooks, commands, and
  subagents.
  
  ## Migration strategy
  
  The migration is intentionally conservative: Codex only imports
  external-agent config that can be represented safely in Codex today.
  Unsupported or ambiguous config is skipped instead of being partially
  translated into behavior that may not match the source system.
  
  - **MCP servers**: import supported stdio and HTTP MCP server
  definitions into `mcp_servers`. Disabled servers and servers filtered
  out by source `enabledMcpjsonServers` / `disabledMcpjsonServers` are
  skipped. Project-scoped MCP entries from `.claude.json` are included
  when they match the repo path.
  - **Hooks**: import only supported command hooks into
  `.codex/hooks.json`. Unsupported hook features such as conditional
  groups, async handlers, prompt/http hooks, or unknown fields are
  skipped. Referenced hook scripts are copied into `.codex/hooks/`,
  preserving any existing target scripts.
  - **Commands**: import supported external commands as Codex skills under
  `.agents/skills/source-command-*`. Commands that rely on source runtime
  expansion such as `$ARGUMENTS`, `$1`, `@file` references, shell
  interpolation, or colliding generated names are skipped.
  - **Subagents**: import valid subagent Markdown files into
  `.codex/agents/*.toml` when they have the minimum Codex agent fields.
  Source model names are not migrated, so imported agents keep the user’s
  Codex default model; compatible reasoning effort and sandbox mode are
  migrated when present.
  - **Skills and project guidance**: copy missing skill directories into
  `.agents/skills` and migrate `CLAUDE.md` guidance into `AGENTS.md`,
  rewriting source-agent terminology to Codex terminology where
  appropriate.
  - **Detection details**: detected migration items include lightweight
  details for UI preview, such as MCP server names, hook event names,
  generated command skill names, and subagent names. Import still
  recomputes from disk instead of trusting details as the source of truth.
  
  - Adds focused coverage for the new migration behavior and app-server
  import flow.
  
  ## Verification
  
  - `cargo test -p codex-external-agent-migration`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server external_agent_config`
  - `just bazel-lock-check`

  alexsong-oai · 2026-04-29 00:45:24 +00:00
  cb8b1bbcd6
• External agent session support (#19895)

  ## Summary
  
  This extends external agent detection/import beyond config artifacts so
  Codex can detect recent sessions files from the external agent home and
  import them into Codex rollout history.
  
  ## What changed
  
  - Added a focused `external_agent_sessions` module for:
    - session discovery
    - source-record parsing
    - rollout construction
    - import ledger tracking
  - Wired session detection/import into the app-server external agent
  config API.
  - Added compaction handling so large imported sessions can be resumed
  safely before the first follow-up turn.
  
  ## Testing
  
  Added coverage for:
  - recent-session detection
  - custom-title handling
  - recency filtering
  - dedupe and re-detect-after-source-change behavior
  - visible imported turn construction
  - backward-compatible import payload deserialization
  - end-to-end RPC import flow
  - rejection of undetected session paths
  - repeat-import behavior
  - large-session compaction before first follow-up
  
  Ran:
  - `cargo test -p codex-app-server external_agent_config_import_ --test
  all`

  stefanstokic-oai · 2026-04-28 17:42:36 +00:00
  4c68bd728f
• feat: split memories part 2 (#19860)

  Keep extracting memories out of core and moving the write trigger in the
  app-server
  This is temporary and it should move at the client level as a follow-up
  This makes core fully independant from `codex-memories-write`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-28 13:03:28 +02:00
  431ebeaef7
• feat: Cache remote plugin bundles on install (#19914)

  Remote installs now fetch, validate, download, and cache the plugin
  bundle locally

  xl-openai · 2026-04-28 00:53:27 -07:00
  7d72fc8f53
• refactor: route Codex auth through AuthProvider (#18811)

  ## Summary
  
  This PR moves Codex backend request authentication from direct
  bearer-token handling to `AuthProvider`.
  
  The new `codex-auth-provider` crate defines the shared request-auth
  trait. `CodexAuth::provider()` returns a provider that can apply all
  headers needed for the selected auth mode.
  
  This lets ChatGPT token auth and AgentIdentity auth share the same
  callsite path:
  - ChatGPT token auth applies bearer auth plus account/FedRAMP headers
  where needed.
  - AgentIdentity auth applies AgentAssertion plus account/FedRAMP headers
  where needed.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Callsite Migration
  
  | Area | Change |
  | --- | --- |
  | backend-client | accepts an `AuthProvider` instead of a raw
  token/header |
  | chatgpt client/connectors | applies auth through
  `CodexAuth::provider()` |
  | cloud tasks | keeps Codex-backend gating, applies auth through
  provider |
  | cloud requirements | uses Codex-backend auth checks and provider
  headers |
  | app-server remote control | applies provider headers for backend calls
  |
  | MCP Apps/connectors | gates on `uses_codex_backend()` and keys caches
  from generic account getters |
  | model refresh | treats AgentIdentity as Codex-backend auth |
  | OpenAI file upload path | rejects non-Codex-backend auth before
  applying headers |
  | core client setup | keeps model-provider auth flow and allows
  AgentIdentity through provider-backed OpenAI auth |
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. This PR: migrate Codex backend auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-23 17:14:02 -07:00
  5882f3f95e
• app-server: add Unix socket transport (#18255)

  ## Summary
  - add unix:// app-server transport backed by the shared codex-uds crate
  - reuse the websocket connection loop for axum and tungstenite-backed
  streams
  - add codex app-server proxy to bridge stdio clients to the control
  socket
  - tolerate Windows UDS backends that report a missing rendezvous path as
  connection refused before binding
  
  ## Tests
  - cargo test -p codex-app-server
  control_socket_acceptor_forwards_websocket_text_messages_and_pings
  - cargo test -p codex-app-server
  - just fmt
  - just fix -p codex-app-server
  - git -c core.fsmonitor=false diff --check

  Ruslan Nigmatullin · 2026-04-23 11:09:25 -07:00
  8a0ab3fc13
• Use remote plugin IDs for detail reads and enlarge list pages (#19079)

  1. For remote plugin use plugin id (plugin name) directly for read
  plugin details;
  2. Request up to 200 remote plugins per directory list page.

  xl-openai · 2026-04-22 22:50:20 -07:00
  fb6308cf64
• feat: Support remote plugin list/read. (#18452)

  Add a temporary internal remote_plugin feature flag that merges remote
  marketplaces into plugin/list and routes plugin/read through the remote
  APIs when needed, while keeping pure local marketplaces working as
  before.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-21 18:39:07 -07:00
  a978e411f6
• app-server: implement device key v2 methods (#18430)

  ## Why
  
  The device-key protocol needs an app-server implementation that keeps
  local key operations behind the same request-processing boundary as
  other v2 APIs.
  
  app-server owns request dispatch, transport policy, documentation, and
  JSON-RPC error shaping. `codex-device-key` owns key binding, validation,
  platform provider selection, and signing mechanics. Keeping the adapter
  thin makes the boundary easier to review and avoids moving local
  key-management details into thread orchestration code.
  
  ## What changed
  
  - Added `DeviceKeyApi` as the app-server adapter around
  `DeviceKeyStore`.
  - Converted protocol protection policies, payload variants, algorithms,
  and protection classes to and from the device-key crate types.
  - Encoded SPKI public keys and DER signatures as base64 protocol fields.
  - Routed `device/key/create`, `device/key/public`, and `device/key/sign`
  through `MessageProcessor`.
  - Rejected remote transports before provider access while allowing local
  `stdio` and in-process callers to reach the device-key API.
  - Added stdio, in-process, and websocket tests for device-key validation
  and transport policy.
  - Documented the device-key methods in the app-server v2 method list.
  
  ## Test coverage
  
  - `device_key_create_rejects_empty_account_user_id`
  - `in_process_allows_device_key_requests_to_reach_device_key_api`
  - `device_key_methods_are_rejected_over_websocket`
  
  ## Stack
  
  This is PR 3 of 4 in the device-key app-server stack. It is stacked on
  #18429.
  
  ## Validation
  
  - `cargo test -p codex-app-server device_key`
  - `just fix -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-21 14:07:08 -07:00
  69c3d12274
• Refactor app-server config loading into ConfigManager (#18442)

  Localize app-server configuration loading in one place.

  pakrym-oai · 2026-04-21 10:22:26 -07:00
  5fe767e8e1
• Add session config loader interface (#18208)

  ## Why
  
  Cloud-hosted sessions need a way for the service that starts or manages
  a thread to provide session-owned config without treating all config as
  if it came from the same user/project/workspace TOML stack.
  
  The important boundary is ownership: some values should be controlled by
  the session/orchestrator, some by the authenticated user, and later some
  may come from the executor. The earlier broad config-store shape made
  that boundary too fuzzy and overlapped heavily with the existing
  filesystem-backed config loader. This PR starts with the smaller piece
  we need now: a typed session config loader that can feed the existing
  config layer stack while preserving the normal precedence and merge
  behavior.
  
  ## What Changed
  
  - Added `ThreadConfigLoader` and related typed payloads in
  `codex-config`.
  - `SessionThreadConfig` currently supports `model_provider`,
  `model_providers`, and feature flags.
  - `UserThreadConfig` is present as an ownership boundary, but does not
  yet add TOML-backed fields.
  - `NoopThreadConfigLoader` preserves existing behavior when no external
  loader is configured.
    - `StaticThreadConfigLoader` supports tests and simple callers.
  
  - Taught thread config sources to produce ordinary `ConfigLayerEntry`
  values so the existing `ConfigLayerStack` remains the place where
  precedence and merging happen.
  
  - Wired the loader through `ConfigBuilder`, the config loader, and
  app-server startup paths so app-server can provide session-owned config
  before deriving a thread config.
  
  - Added coverage for:
    - translating typed thread config into config layers,
  - inserting thread config layers into the stack at the right precedence,
  - applying session-provided model provider and feature settings when
  app-server derives config from thread params.
  
  ## Follow-Ups
  
  This intentionally stops short of adding the remote/service transport.
  The next pieces are expected to be:
  
  1. Define the proto/API shape for this interface.
  2. Add a client implementation that can source session config from the
  service side.
  
  ## Verification
  
  - Added unit coverage in `codex-config` for the loader and layer
  conversion.
  - Added `codex-core` config loader coverage for thread config layer
  precedence.
  - Added app-server coverage that verifies session thread config wins
  over request-provided config for model provider and feature settings.

  Rasmus Rygaard · 2026-04-20 23:05:49 +00:00
  7b994100b3
• Extract plugin loading and marketplace logic into codex-core-plugins (#18070)

  Split plugin loading, marketplace, and related infrastructure out of
  core into codex-core-plugins, while keeping the core-facing
  configuration and orchestration flow in codex-core.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-15 23:13:17 -07:00
  48cf3ed7b0
• [codex] Add local thread store listing (#17824)

  Builds on top of #17659 
  
  Move the filesystem + sqlite thread listing-related operations inside of
  a local ThreadStore implementation and call ThreadStore from the places
  that used to perform these filesystem/sqlite operations.
  
  This is the first of a series of PRs that will implement the rest of the
  local ThreadStore.
  
  Testing:
  - added unit tests for the thread store implementation
  - adjusted some unit tests in the realtime + personality packages whose
  callsites changed. Specifically I'm trying to hide ThreadMetadata inside
  of the local implementation and make ThreadMetadata a sqlite
  implementation detail concern rather than a public interface, preferring
  the more generate StoredThread interface instead
  - added a corner case test for the personality migration package that
  wasn't covered by the existing test suite
  - adjust the behavior of searched thread listing to run the existing
  local rollout repair/backfill pass _before_ querying SQLite results, so
  callers using ThreadStore::list_threads do not miss matches after a
  partial metadata warm-up

  Tom · 2026-04-15 11:34:27 -07:00
  cdfcd2ca92
• app-server: Add transport for remote control (#15951)
  Ruslan Nigmatullin · 2026-04-06 14:55:59 -07:00
  73dab2046f
• remove temporary ownership re-exports (#16626)

  Stacked on #16508.
  
  This removes the temporary `codex-core` / `codex-login` re-export shims
  from the ownership split and rewrites callsites to import directly from
  `codex-model-provider-info`, `codex-models-manager`, `codex-api`,
  `codex-protocol`, `codex-feedback`, and `codex-response-debug-context`.
  
  No behavior change intended; this is the mechanical import cleanup layer
  split out from the ownership move.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-03 00:33:34 -07:00
  af8a9d2d2b
• [codex] Remove codex-core config type shim (#16529)

  ## Why
  
  This finishes the config-type move out of `codex-core` by removing the
  temporary compatibility shim in `codex_core::config::types`. Callers now
  depend on `codex-config` directly, which keeps these config model types
  owned by the config crate instead of re-expanding `codex-core` as a
  transitive API surface.
  
  ## What Changed
  
  - Removed the `codex-rs/core/src/config/types.rs` re-export shim and the
  `core::config::ApprovalsReviewer` re-export.
  - Updated `codex-core`, `codex-cli`, `codex-tui`, `codex-app-server`,
  `codex-mcp-server`, and `codex-linux-sandbox` call sites to import
  `codex_config::types` directly.
  - Added explicit `codex-config` dependencies to downstream crates that
  previously relied on the `codex-core` re-export.
  - Regenerated `codex-rs/core/config.schema.json` after updating the
  config docs path reference.

  Michael Bolin · 2026-04-02 01:19:44 -07:00
  c1d18ceb6f
• 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
• core: use codex-mcp APIs directly (#16510)

  ## Why
  
  `codex-mcp` already owns the shared MCP API surface, including `auth`,
  `McpConfig`, `CODEX_APPS_MCP_SERVER_NAME`, and tool-name helpers in
  [`codex-rs/codex-mcp/src/mcp/mod.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/codex-mcp/src/mcp/mod.rs#L1-L35).
  Re-exporting that surface from `codex_core::mcp` gives downstream crates
  two import paths for the same API and hides the real crate dependency.
  
  This PR keeps `codex_core::mcp` focused on the local `McpManager`
  wrapper in
  [`codex-rs/core/src/mcp.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/core/src/mcp.rs#L13-L40)
  and makes consumers import shared MCP APIs from `codex_mcp` directly.
  
  ## What
  
  - Remove the `codex_mcp::mcp` re-export surface from `core/src/mcp.rs`.
  - Update `codex-core` internals plus `codex-app-server`, `codex-cli`,
  and `codex-tui` test code to import MCP APIs from `codex_mcp::mcp`
  directly.
  - Add explicit `codex-mcp` dependencies where those crates now use that
  API surface, and refresh `Cargo.lock`.
  
  ## Verification
  
  - `just bazel-lock-check`
  - `cargo test -p codex-core -p codex-cli -p codex-tui`
    - `codex-cli` passed.
  - `codex-core` still fails five unrelated config tests in
  `core/src/config/config_tests.rs` (`approvals_reviewer_*` and
  `smart_approvals_alias_*`).
  - A broader `cargo test -p codex-core -p codex-app-server -p codex-cli
  -p codex-tui` run previously hung in `codex-app-server` test
  `in_process_start_uses_requested_session_source_for_thread_start`.

  Michael Bolin · 2026-04-01 21:55:22 -07:00
  cc97982bbb
• codex-tools: extract shared tool schema parsing (#15923)

  ## Why
  
  `parse_tool_input_schema` and the supporting `JsonSchema` model were
  living in `core/src/tools/spec.rs`, but they already serve callers
  outside `codex-core`.
  
  Keeping that shared schema parsing logic inside `codex-core` makes the
  crate boundary harder to reason about and works against the guidance in
  `AGENTS.md` to avoid growing `codex-core` when reusable code can live
  elsewhere.
  
  This change takes the first extraction step by moving the schema parsing
  primitive into its own crate while keeping the rest of the tool-spec
  assembly in `codex-core`.
  
  ## What changed
  
  - added a new `codex-tools` crate under `codex-rs/tools`
  - moved the shared tool input schema model and sanitizer/parser into
  `tools/src/json_schema.rs`
  - kept `tools/src/lib.rs` exports-only, with the module-level unit tests
  split into `json_schema_tests.rs`
  - updated `codex-core` to use `codex-tools::JsonSchema` and re-export
  `parse_tool_input_schema`
  - updated `codex-app-server` dynamic tool validation to depend on
  `codex-tools` directly instead of reaching through `codex-core`
  - wired the new crate into the Cargo workspace and Bazel build graph

  Michael Bolin · 2026-03-27 00:03:35 +00:00
  44d28f500f
• feat: add websocket auth for app-server (#14847)

  ## Summary
  This change adds websocket authentication at the app-server transport
  boundary and enforces it before JSON-RPC `initialize`, so authenticated
  deployments reject unauthenticated clients during the websocket
  handshake rather than after a connection has already been admitted.
  
  During rollout, websocket auth is opt-in for non-loopback listeners so
  we do not break existing remote clients. If `--ws-auth ...` is
  configured, the server enforces auth during websocket upgrade. If auth
  is not configured, non-loopback listeners still start, but app-server
  logs a warning and the startup banner calls out that auth should be
  configured before real remote use.
  
  The server supports two auth modes: a file-backed capability token, and
  a standard HMAC-signed JWT/JWS bearer token verified with the
  `jsonwebtoken` crate, with optional issuer, audience, and clock-skew
  validation. Capability tokens are normalized, hashed, and compared in
  constant time. Short shared secrets for signed bearer tokens are
  rejected at startup. Requests carrying an `Origin` header are rejected
  with `403` by transport middleware, and authenticated clients present
  credentials as `Authorization: Bearer <token>` during websocket upgrade.
  
  ## Validation
  - `cargo test -p codex-app-server transport::auth`
  - `cargo test -p codex-cli app_server_`
  - `cargo clippy -p codex-app-server --all-targets -- -D warnings`
  - `just bazel-lock-check`
  
  Note: in the broad `cargo test -p codex-app-server
  connection_handling_websocket` run, the touched websocket auth cases
  passed, but unrelated Unix shutdown tests failed with a timeout in this
  environment.
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  viyatb-oai · 2026-03-25 12:35:57 -07:00
  6124564297
• Move git utilities into a dedicated crate (#15564)

  - create `codex-git-utils` and move the shared git helpers into it with
  file moves preserved for diff readability
  - move the `GitInfo` helpers out of `core` so stacked rollout work can
  depend on the shared crate without carrying its own git info module
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-24 13:26:23 -07:00
  0f957a93cd
• Move sandbox policy transforms into codex-sandboxing (#15599)

  ## Summary
  - move the pure sandbox policy transform helpers from `codex-core` into
  `codex-sandboxing`
  - move the corresponding unit tests with the extracted implementation
  - update `core` and `app-server` callers to import the moved APIs
  directly, without re-exports or proxy methods
  
  ## Testing
  - cargo test -p codex-sandboxing
  - cargo test -p codex-core sandboxing
  - cargo test -p codex-app-server --lib
  - just fix -p codex-sandboxing
  - just fix -p codex-core
  - just fix -p codex-app-server
  - just fmt
  - just argument-comment-lint

  pakrym-oai · 2026-03-23 22:22:44 -07:00
  9deb8ce3fc
• Split features into codex-features crate (#15253)

  - Split the feature system into a new `codex-features` crate.
  - Cut `codex-core` and workspace consumers over to the new config and
  warning APIs.
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 20:12:07 -07:00
  2e22885e79
• Move environment abstraction into exec server (#15125)

  The idea is that codex-exec exposes an Environment struct with services
  on it. Each of those is a trait.
  
  Depending on construction parameters passed to Environment they are
  either backed by local or remote server but core doesn't see these
  differences.

  pakrym-oai · 2026-03-19 08:31:14 -07:00
  dee03da508
• Add FS abstraction and use in view_image (#14960)

  Adds an environment crate and environment + file system abstraction.
  
  Environment is a combination of attributes and services specific to
  environment the agent is connected to:
  File system, process management, OS, default shell.
  
  The goal is to move most of agent logic that assumes environment to work
  through the environment abstraction.

  pakrym-oai · 2026-03-17 17:36:23 -07:00
  83a60fdb94
• app-server: add v2 filesystem APIs (#14245)

  Add a protocol-level filesystem surface to the v2 app-server so Codex
  clients can read and write files, inspect directories, and subscribe to
  path changes without relying on host-specific helpers.
  
  High-level changes:
  - define the new v2 fs/readFile, fs/writeFile, fs/createDirectory,
  fs/getMetadata, fs/readDirectory, fs/remove, fs/copy RPCs
  - implement the app-server handlers, including absolute-path validation,
  base64 file payloads, recursive copy/remove semantics
  - document the API, regenerate protocol schemas/types, and add
  end-to-end tests for filesystem operations, copy edge cases
  
  Testing plan:
  - validate protocol serialization and generated schema output for the
  new fs request, response, and notification types
  - run app-server integration coverage for file and directory CRUD paths,
  metadata/readDirectory responses, copy failure modes, and absolute-path
  validation

  Ruslan Nigmatullin · 2026-03-13 14:42:20 -07:00
  f8f82bfc2b
• feat(app-server): propagate traces across tasks and core ops (#14387)

  ## Summary
  
  This PR keeps app-server RPC request trace context alive for the full
  lifetime of the work that request kicks off (e.g. for `thread/start`,
  this is `app-server rpc handler -> tokio background task -> core op
  submissions`). Previously we lose trace lineage once the request handler
  returns or hands work off to background tasks.
  
  This approach is especially relevant for `thread/start` and other RPC
  handlers that run in a non-blocking way. In the near future we'll most
  likely want to make all app-server handlers run in a non-blocking way by
  default, and only queue operations that must operate in order (e.g.
  thread RPCs per thread?), so we want to make sure tracing in app-server
  just generally works.
  
  Depends on https://github.com/openai/codex/pull/14300
  
  **Before**
  <img width="155" height="207" alt="image"
  src="https://github.com/user-attachments/assets/c9487459-36f1-436c-beb7-fafeb40737af"
  />
  
  
  **After**
  <img width="299" height="337" alt="image"
  src="https://github.com/user-attachments/assets/727392b2-d072-4427-9dc4-0502d8652dea"
  />
  
  ## What changed
  
  - Keep request-scoped trace context around until we send the final
  response or error, or the connection closes.
  - Thread that trace context through detached `thread/start` work so
  background startup stays attached to the originating request.
  - Pass request trace context through to downstream core operations,
  including:
    - thread creation
    - resume/fork flows
    - turn submission
    - review
    - interrupt
    - realtime conversation operations
  - Add tracing tests that verify:
    - remote W3C trace context is preserved for `thread/start`
    - remote W3C trace context is preserved for `turn/start`
    - downstream core spans stay under the originating request span
    - request-scoped tracing state is cleaned up correctly
  - Clean up shutdown behavior so detached background tasks and spawned
  threads are drained before process exit.

  Owen Lin · 2026-03-11 20:18:31 -07:00
  5bc82c5b93
• Stabilize app-server notify initialize test (#13939)

  ## What changed
  - This PR changes only the flaky test setup for
  `turn_start_notify_payload_includes_initialize_client_name`.
  - Instead of shelling out to `python3` to write the notify payload, the
  test uses the first-party `codex-app-server-test-notify-capture` helper.
  - The helper writes `notify.json` atomically and the test waits for the
  file to exist before reading it.
  
  ## Why this fixes the flake
  - The old test depended on an external Python interpreter being present
  and behaving consistently on every CI runner.
  - It also raced the file write: the test could observe the path before
  the payload had been fully written, which produced partial reads and
  intermittent assertion failures.
  - Moving the write into a repo-owned helper removes the external
  dependency, and atomic write-plus-wait makes the handoff deterministic.
  
  ## Scope
  - Test-only change.

  Ahmed Ibrahim · 2026-03-09 23:41:58 -07:00
  f3f47cf455
• codex-rs/app-server: add health endpoints for --listen websocket server (#13782)

  Healthcheck endpoints for the websocket server
  
  - serve `GET /readyz` and `GET /healthz` from the same listener used for
  `--listen ws://...`
  - switch the websocket listener over to `axum` upgrade handling instead
  of manual socket parsing
  - add websocket transport coverage for the health endpoints and document
  the new behavior
  
  Testing
  - integration tests
  - built and tested e2e
  
  ```
  > curl -i http://127.0.0.1:9234/readyz
  HTTP/1.1 200 OK
  content-length: 0
  date: Fri, 06 Mar 2026 19:20:23 GMT
  
  >  curl -i http://127.0.0.1:9234/healthz
  HTTP/1.1 200 OK
  content-length: 0
  date: Fri, 06 Mar 2026 19:20:24 GMT
  ```

  Max Johnson · 2026-03-09 22:11:30 +00:00
  66e71cce11
• app-server: Add streaming and tty/pty capabilities to command/exec (#13640)

  * Add an ability to stream stdin, stdout, and stderr
  * Streaming of stdout and stderr has a configurable cap for total amount
  of transmitted bytes (with an ability to disable it)
  * Add support for overriding environment variables
  * Add an ability to terminate running applications (using
  `command/exec/terminate`)
  * Add TTY/PTY support, with an ability to resize the terminal (using
  `command/exec/resize`)

  Ruslan Nigmatullin · 2026-03-06 17:30:17 -08:00
  e9bd8b20a1
• feat(app-server): support mcp elicitations in v2 api (#13425)

  This adds a first-class server request for MCP server elicitations:
  `mcpServer/elicitation/request`.
  
  Until now, MCP elicitation requests only showed up as a raw
  `codex/event/elicitation_request` event from core. That made it hard for
  v2 clients to handle elicitations using the same request/response flow
  as other server-driven interactions (like shell and `apply_patch`
  tools).
  
  This also updates the underlying MCP elicitation request handling in
  core to pass through the full MCP request (including URL and form data)
  so we can expose it properly in app-server.
  
  ### Why not `item/mcpToolCall/elicitationRequest`?
  This is because MCP elicitations are related to MCP servers first, and
  only optionally to a specific MCP tool call.
  
  In the MCP protocol, elicitation is a server-to-client capability: the
  server sends `elicitation/create`, and the client replies with an
  elicitation result. RMCP models it that way as well.
  
  In practice an elicitation is often triggered by an MCP tool call, but
  not always.
  
  ### What changed
  - add `mcpServer/elicitation/request` to the v2 app-server API
  - translate core `codex/event/elicitation_request` events into the new
  v2 server request
  - map client responses back into `Op::ResolveElicitation` so the MCP
  server can continue
  - update app-server docs and generated protocol schema
  - add an end-to-end app-server test that covers the full round trip
  through a real RMCP elicitation flow
  - The new test exercises a realistic case where an MCP tool call
  triggers an elicitation, the app-server emits
  mcpServer/elicitation/request, the client accepts it, and the tool call
  resumes and completes successfully.
  
  ### app-server API flow
  - Client starts a thread with `thread/start`.
  - Client starts a turn with `turn/start`.
  - App-server sends `item/started` for the `mcpToolCall`.
  - While that tool call is in progress, app-server sends
  `mcpServer/elicitation/request`.
  - Client responds to that request with `{ action: "accept" | "decline" |
  "cancel" }`.
  - App-server sends `serverRequest/resolved`.
  - App-server sends `item/completed` for the mcpToolCall.
  - App-server sends `turn/completed`.
  - If the turn is interrupted while the elicitation is pending,
  app-server still sends `serverRequest/resolved` before the turn
  finishes.

  Owen Lin · 2026-03-05 07:20:20 -08:00
  926b2f19e8
• Add thread metadata update endpoint to app server (#13280)

  ## Summary
  - add the v2 `thread/metadata/update` API, including
  protocol/schema/TypeScript exports and app-server docs
  - patch stored thread `gitInfo` in sqlite without resuming the thread,
  with validation plus support for explicit `null` clears
  - repair missing sqlite thread rows from rollout data before patching,
  and make those repairs safe by inserting only when absent and updating
  only git columns so newer metadata is not clobbered
  - keep sqlite authoritative for mutable thread git metadata by
  preserving existing sqlite git fields during reconcile/backfill and only
  using rollout `SessionMeta` git fields to fill gaps
  - add regression coverage for the endpoint, repair paths, concurrent
  sqlite writes, clearing git fields, and rollout/backfill reconciliation
  - fix the login server shutdown race so cancelling before the waiter
  starts still terminates `block_until_done()` correctly
  
  ## Testing
  - `cargo test -p codex-state
  apply_rollout_items_preserves_existing_git_branch_and_fills_missing_git_fields`
  - `cargo test -p codex-state
  update_thread_git_info_preserves_newer_non_git_metadata`
  - `cargo test -p codex-core
  backfill_sessions_preserves_existing_git_branch_and_fills_missing_git_fields`
  - `cargo test -p codex-app-server thread_metadata_update`
  - `cargo test`
  - currently fails in existing `codex-core` grep-files tests with
  `unsupported call: grep_files`:
      - `suite::grep_files::grep_files_tool_collects_matches`
      - `suite::grep_files::grep_files_tool_reports_empty_results`

  joeytrasatti-openai · 2026-03-03 15:56:11 -08:00
  935754baa3