49 Commits

• 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
• chore(app-server): delete v1 RPC methods and notifications (#13375)

  ## Summary
  This removes the old app-server v1 methods and notifications we no
  longer need, while keeping the small set the main codex app client still
  depends on for now.
  
  The remaining legacy surface is:
  - `initialize`
  - `getConversationSummary`
  - `getAuthStatus`
  - `gitDiffToRemote`
  - `fuzzyFileSearch`
  - `fuzzyFileSearch/sessionStart`
  - `fuzzyFileSearch/sessionUpdate`
  - `fuzzyFileSearch/sessionStop`
  
  And the raw `codex/event/*` notifications emitted from core. These
  notifications will be removed in a followup PR.
  
  ## What changed
  - removed deprecated v1 request variants from the protocol and
  app-server dispatcher
  - removed deprecated typed notifications: `authStatusChange`,
  `loginChatGptComplete`, and `sessionConfigured`
  - updated the app-server test client to use v2 flows instead of deleted
  v1 flows
  - deleted legacy-only app-server test suites and added focused coverage
  for `getConversationSummary`
  - regenerated app-server schema fixtures and updated the MCP interface
  docs to match the remaining compatibility surface
  
  ## Testing
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`

  Owen Lin · 2026-03-03 13:18:25 -08:00
  167158f93c
• app-server: source /feedback logs from sqlite at trace level (#12969)

  ## Summary
  - write app-server SQLite logs at TRACE level when SQLite is enabled
  - source app-server `/feedback` log attachments from SQLite for the
  requested thread when available
  - flush buffered SQLite log writes before `/feedback` queries them so
  newly emitted events are not lost behind the async inserter
  - include same-process threadless SQLite rows in those `/feedback` logs
  so the attachment matches the process-wide feedback buffer more closely
  - keep the existing in-memory ring buffer fallback unchanged, including
  when the SQLite query returns no rows
  
  ## Details
  - add a byte-bounded `query_feedback_logs` helper in `codex-state` so
  `/feedback` does not fetch all rows before truncating
  - scope SQLite feedback logs to the requested thread plus threadless
  rows from the same `process_uuid`
  - format exported SQLite feedback lines with the log level prefix to
  better match the in-memory feedback formatter
  - add an explicit `LogDbLayer::flush()` control path and await it in
  app-server before querying SQLite for feedback logs
  - pass optional SQLite log bytes through `codex-feedback` as the
  `codex-logs.log` attachment override
  - leave TUI behavior unchanged apart from the updated `upload_feedback`
  call signature
  - add regression coverage for:
    - newest-within-budget ordering
    - excluding oversized newest rows
    - including same-process threadless rows
    - keeping the newest suffix across mixed thread and threadless rows
    - matching the feedback formatter shape aside from span prefixes
    - falling back to the in-memory snapshot when SQLite returns no logs
    - flushing buffered SQLite rows before querying
  
  ## Follow-up
  - SQLite feedback exports still do not reproduce span prefixes like
  `feedback-thread{thread_id=...}:`; there is a `TODO(ccunningham)` in
  `codex-rs/state/src/log_db.rs` for that follow-up.
  
  ## Testing
  - `cd codex-rs && cargo test -p codex-state`
  - `cd codex-rs && cargo test -p codex-app-server`
  - `cd codex-rs && just fmt`

  Charley Cunningham · 2026-03-03 11:17:06 -08:00
  c4bd0aa3b9
• feat(app-server): add tracing to all app-server APIs (#13285)

  ### Overview
  This PR adds the first piece of tracing for app-server JSON-RPC
  requests.
  
  There are two main changes:
  - JSON-RPC requests can now take an optional W3C trace context at the
  top level via a `trace` field (`traceparent` / `tracestate`).
  - app-server now creates a dedicated request span for every inbound
  JSON-RPC request in `MessageProcessor`, and uses the request-level trace
  context as the parent when present.
  
  For compatibility with existing flows, app-server still falls back to
  the TRACEPARENT env var when there is no request-level traceparent.
  
  This PR is intentionally scoped to the app-server boundary. In a
  followup, we'll actually propagate trace context through the async
  handoff into core execution spans like run_turn, which will make
  app-server traces much more useful.
  
  ### Spans
  A few details on the app-server span shape:
  - each inbound request gets its own server span
  - span/resource names are based on the JSON-RPC method (`initialize`,
  `thread/start`, `turn/start`, etc.)
  - spans record transport (stdio vs websocket), request id, connection
  id, and client name/version when available
  - `initialize` stores client metadata in session state so later requests
  on the same connection can reuse it

  Owen Lin · 2026-03-02 16:01:41 -08:00
  d473e8d56d
• feat: add search term to thread list (#12578)

  Add `searchTerm` to `thread/list` that will search for a match in the
  titles (the condition being `searchTerm` $$\in$$ `title`)

  jif-oai · 2026-02-25 09:59:41 +00:00
  f46b767b7e
• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• app-server: harden disconnect cleanup paths (#12218)

  Hardens codex-rs/app-server connection lifecycle and outbound routing
  for websocket clients. Fixes some FUD I was having
  
  - Added per-connection disconnect signaling (CancellationToken) for
  websocket transports.
  - Split websocket handling into independent inbound/outbound tasks
  coordinated by cancellation.
  - Changed outbound routing so websocket connections use non-blocking
  try_send; slow/full websocket writers are disconnected instead of
  stalling broadcast delivery.
  - Kept stdio behavior blocking-on-send (no forced disconnect) so local
  stdio clients are not dropped when queues are temporarily full.
  - Simplified outbound router flow by removing deferred
  pending_closed_connections handling.
  - Added guards to drop incoming response/notification/error messages
  from unknown connections.
  - Fixed listener teardown race in thread listener tasks using a
  listener_generation check so stale tasks do not clear newer listeners.
  
  Fixes
  https://linear.app/openai/issue/CODEX-4966/multiclient-handle-slow-notification-consumers
  
    ## Tests
  
    Added/updated transport tests covering:
  
    - broadcast does not block on a slow/full websocket connection
    - stdio connection waits instead of disconnecting on full queue
  
  I (maxj) have tested manually and will retest before landing

  Max Johnson · 2026-02-20 20:35:16 +00:00
  6b1091fc92
• app-server: add JSON tracing logs (#12287)

  - add `LOG_FORMAT=json` support for app-server tracing logs via
  `tracing_subscriber`'s built-in JSON formatter
  - keep the default human-readable format unchanged and keep `RUST_LOG`
  filtering behavior
  - document the env var and update lockfile

  Max Johnson · 2026-02-20 10:10:51 -08:00
  41f15bf07b
• Reapply "Add app-server transport layer with websocket support" (#11370)

  Reapply "Add app-server transport layer with websocket support" with
  additional fixes from https://github.com/openai/codex/pull/11313/changes
  to avoid deadlocking.
  
  This reverts commit 47356ff83c.
  
  ## Summary
  
  To avoid deadlocking when queues are full, we maintain separate tokio
  tasks dedicated to incoming vs outgoing event handling
  - split the app-server main loop into two tasks in
  `run_main_with_transport`
     - inbound handling (`transport_event_rx`)
     - outbound handling (`outgoing_rx` + `thread_created_rx`)
  - separate incoming and outgoing websocket tasks
  
  ## Validation
  
  Integration tests, testing thoroughly e2e in codex app w/ >10 concurrent
  requests
  
  <img width="1365" height="979" alt="Screenshot 2026-02-10 at 2 54 22 PM"
  src="https://github.com/user-attachments/assets/47ca2c13-f322-4e5c-bedd-25859cbdc45f"
  />
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Max Johnson · 2026-02-11 18:13:39 +00:00
  7053aa5457
• feat: split codex-common into smaller utils crates (#11422)

  We are removing feature-gated shared crates from the `codex-rs`
  workspace. `codex-common` grouped several unrelated utilities behind
  `[features]`, which made dependency boundaries harder to reason about
  and worked against the ongoing effort to eliminate feature flags from
  workspace crates.
  
  Splitting these utilities into dedicated crates under `utils/` aligns
  this area with existing workspace structure and keeps each dependency
  explicit at the crate boundary.
  
  ## What changed
  
  - Removed `codex-rs/common` (`codex-common`) from workspace members and
  workspace dependencies.
  - Added six new utility crates under `codex-rs/utils/`:
    - `codex-utils-cli`
    - `codex-utils-elapsed`
    - `codex-utils-sandbox-summary`
    - `codex-utils-approval-presets`
    - `codex-utils-oss`
    - `codex-utils-fuzzy-match`
  - Migrated the corresponding modules out of `codex-common` into these
  crates (with tests), and added matching `BUILD.bazel` targets.
  - Updated direct consumers to use the new crates instead of
  `codex-common`:
    - `codex-rs/cli`
    - `codex-rs/tui`
    - `codex-rs/exec`
    - `codex-rs/app-server`
    - `codex-rs/mcp-server`
    - `codex-rs/chatgpt`
    - `codex-rs/cloud-tasks`
  - Updated workspace lockfile entries to reflect the new dependency graph
  and removal of `codex-common`.

  Michael Bolin · 2026-02-11 12:59:24 +00:00
  8b7f8af343
• Revert "Add app-server transport layer with websocket support (#10693)" (#11323)

  Suspected cause of deadlocking bug

  Max Johnson · 2026-02-10 17:37:49 +00:00
  47356ff83c
• app-server: print help message to console when starting websockets server (#10943)

  Follow-up to https://github.com/openai/codex/pull/10693
  
  <img width="596" height="77" alt="image"
  src="https://github.com/user-attachments/assets/9140df70-01d1-4c5a-85ee-ca15a09a0e77"
  />

  Javi · 2026-02-07 00:18:42 +00:00
  87ce50f118
• Add app-server transport layer with websocket support (#10693)

  - Adds --listen <URL> to codex app-server with two listen modes:
        - stdio:// (default, existing behavior)
        - ws://IP:PORT (new websocket transport)
    - Refactors message routing to be connection-aware:
  - Tracks per-connection session state (initialize/experimental
  capability)
        - Routes responses/errors to the originating connection
  - Broadcasts server notifications/requests to initialized connections
  - Updates initialization semantics to be per connection (not
  process-global), and updates app-server docs accordingly.
  - Adds websocket accept/read/write handling (JSON-RPC per text frame,
  ping/pong handling, connection lifecycle events).
  
  Testing
  
  - Unit tests for transport URL parsing and targeted response/error
  routing.
    - New websocket integration test validating:
        - per-connection initialization requirements
        - no cross-connection response leakage
        - same request IDs on different connections route independently.

  Max Johnson · 2026-02-05 20:56:34 +00:00
  8473096efb
• feat: replace custom mcp-types crate with equivalents from rmcp (#10349)

  We started working with MCP in Codex before
  https://crates.io/crates/rmcp was mature, so we had our own crate for
  MCP types that was generated from the MCP schema:
  
  
  https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
  
  Now that `rmcp` is more mature, it makes more sense to use their MCP
  types in Rust, as they handle details (like the `_meta` field) that our
  custom version ignored. Though one advantage that our custom types had
  is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
  whereas the types in `rmcp` do not. As such, part of the work of this PR
  is leveraging the adapters between `rmcp` types and the serializable
  types that are API for us (app server and MCP) introduced in #10356.
  
  Note this PR results in a number of changes to
  `codex-rs/app-server-protocol/schema`, which merit special attention
  during review. We must ensure that these changes are still
  backwards-compatible, which is possible because we have:
  
  ```diff
  - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
  + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
  ```
  
  so `ContentBlock` has been replaced with the more general `JsonValue`.
  Note that `ContentBlock` was defined as:
  
  ```typescript
  export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
  ```
  
  so the deletion of those individual variants should not be a cause of
  great concern.
  
  Similarly, we have the following change in
  `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
  
  ```
  - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
  + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
  ```
  
  so:
  
  - `annotations?: ToolAnnotations` ➡️ `JsonValue`
  - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
  - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
  
  and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
  * #10357
  * __->__ #10349
  * #10356

  Michael Bolin · 2026-02-02 17:41:55 -08:00
  66447d5d2c
• Wire up cloud reqs in exec, app-server (#10241)

  We're fetching cloud requirements in TUI in
  https://github.com/openai/codex/pull/10167.
  
  This adds the same fetching in exec and app-server binaries also.

  gt-oai · 2026-01-30 23:53:41 +00:00
  a046481ad9
• feat(app-server): support external auth mode (#10012)

  This enables a new use case where `codex app-server` is embedded into a
  parent application that will directly own the user's ChatGPT auth
  lifecycle, which means it owns the user’s auth tokens and refreshes it
  when necessary. The parent application would just want a way to pass in
  the auth tokens for codex to use directly.
  
  The idea is that we are introducing a new "auth mode" currently only
  exposed via app server: **`chatgptAuthTokens`** which consist of the
  `id_token` (stores account metadata) and `access_token` (the bearer
  token used directly for backend API calls). These auth tokens are only
  stored in-memory. This new mode is in addition to the existing `apiKey`
  and `chatgpt` auth modes.
  
  This PR reuses the shape of our existing app-server account APIs as much
  as possible:
  - Update `account/login/start` with a new `chatgptAuthTokens` variant,
  which will allow the client to pass in the tokens and have codex
  app-server use them directly. Upon success, the server emits
  `account/login/completed` and `account/updated` notifications.
  - A new server->client request called
  `account/chatgptAuthTokens/refresh` which the server can use whenever
  the access token previously passed in has expired and it needs a new one
  from the parent application.
  
  I leveraged the core 401 retry loop which typically triggers auth token
  refreshes automatically, but made it pluggable:
  - **chatgpt** mode refreshes internally, as usual.
  - **chatgptAuthTokens** mode calls the client via
  `account/chatgptAuthTokens/refresh`, the client responds with updated
  tokens, codex updates its in-memory auth, then retries. This RPC has a
  10s timeout and handles JSON-RPC errors from the client.
  
  Also some additional things:
  - chatgpt logins are blocked while external auth is active (have to log
  out first. typically clients will pick one OR the other, not support
  both)
  - `account/logout` clears external auth in memory
  - Ensures that if `forced_chatgpt_workspace_id` is set via the user's
  config, we respect it in both:
  - `account/login/start` with `chatgptAuthTokens` (returns a JSON-RPC
  error back to the client)
  - `account/chatgptAuthTokens/refresh` (fails the turn, and on next
  request app-server will send another `account/chatgptAuthTokens/refresh`
  request to the client).

  Owen Lin · 2026-01-29 23:46:04 +00:00
  81a17bb2c1
• feat(core) RequestRule (#9489)

  ## Summary
  Instead of trying to derive the prefix_rule for a command mechanically,
  let's let the model decide for us.
  
  ## Testing
  - [x] tested locally

  Dylan Hurd · 2026-01-28 08:43:17 +00:00
  996e09ca24
• feat: ephemeral threads (#9765)

  Add ephemeral threads capabilities. Only exposed through the
  `app-server` v2
  
  The idea is to disable the rollout recorder for those threads.

  jif-oai · 2026-01-24 14:57:40 +00:00
  83775f4df1
• [connectors] Support connectors part 1 - App server & MCP (#9667)

  In order to make Codex work with connectors, we add a built-in gateway
  MCP that acts as a transparent proxy between the client and the
  connectors. The gateway MCP collects actions that are accessible to the
  user and sends them down to the user, when a connector action is chosen
  to be called, the client invokes the action through the gateway MCP as
  well.
  
   - [x] Add the system built-in gateway MCP to list and run connectors.
   - [x] Add the app server methods and protocol

  Matthew Zeng · 2026-01-22 16:48:43 -08:00
  a2c829a808
• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• feat: change ConfigLayerName into a disjoint union rather than a simple enum (#8095)

  This attempts to tighten up the types related to "config layers."
  Currently, `ConfigLayerEntry` is defined as follows:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/state.rs#L19-L25
  
  but the `source` field is a bit of a lie, as:
  
  - for `ConfigLayerName::Mdm`, it is
  `"com.openai.codex/config_toml_base64"`
  - for `ConfigLayerName::SessionFlags`, it is `"--config"`
  - for `ConfigLayerName::User`, it is `"config.toml"` (just the file
  name, not the path to the `config.toml` on disk that was read)
  - for `ConfigLayerName::System`, it seems like it is usually
  `/etc/codex/managed_config.toml` in practice, though on Windows, it is
  `%CODEX_HOME%/managed_config.toml`:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/layer_io.rs#L84-L101
  
  All that is to say, in three out of the four `ConfigLayerName`, `source`
  is a `PathBuf` that is not an absolute path (or even a true path).
  
  This PR tries to uplevel things by eliminating `source` from
  `ConfigLayerEntry` and turning `ConfigLayerName` into a disjoint union
  named `ConfigLayerSource` that has the appropriate metadata for each
  variant, favoring the use of `AbsolutePathBuf` where appropriate:
  
  ```rust
  pub enum ConfigLayerSource {
      /// Managed preferences layer delivered by MDM (macOS only).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      Mdm { domain: String, key: String },
      /// Managed config layer from a file (usually `managed_config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      System { file: AbsolutePathBuf },
      /// Session-layer overrides supplied via `-c`/`--config`.
      SessionFlags,
      /// User config layer from a file (usually `config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      User { file: AbsolutePathBuf },
  }
  ```

  Michael Bolin · 2025-12-17 08:13:59 -08:00
  de3fa03e1c
• [codex] add otel tracing (#7844)
  Anton Panasenko · 2025-12-12 17:07:17 -08:00
  ad7b9d63c3
• fix: added test helpers for platform-specific paths (#7954)

  This addresses post-merge feedback from
  https://github.com/openai/codex/pull/7856.

  Michael Bolin · 2025-12-13 00:14:12 +00:00
  b1905d3754
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• feat: clean config loading and config api (#7924)

  Check the README of the `config_loader` for details

  jif-oai · 2025-12-12 12:01:24 -08:00
  92098d36e8
• [app-server] Make sure that config writes preserve comments & order or configs (#7789)

  Make sure that config writes preserve comments and order of configs by
  utilizing the ConfigEditsBuilder in core.
  
  Tested by running a real example and made sure that nothing in the
  config file changes other than the configs to edit.

  Celia Chen · 2025-12-10 19:14:27 +00:00
  8a71f8b634
• feat: support mcp in-session login (#7751)

  ### Summary
  * Added `mcpServer/oauthLogin` in app server for supporting in session
  MCP server login
  * Added `McpServerOauthLoginParams` and `McpServerOauthLoginResponse` to
  support above method with response returning the auth URL for consumer
  to open browser or display accordingly.
  * Added `McpServerOauthLoginCompletedNotification` which the app server
  would emit on MCP server login success or failure (i.e. timeout).
  * Refactored rmcp-client oath_login to have the ability on starting a
  auth server which the codex_message_processor uses for in-session auth.

  Shijie Rao · 2025-12-09 17:43:53 -08:00
  893f5261eb
• feat: support list mcp servers in app server (#7505)

  ### Summary
  Added `mcp/servers/list` which is equivalent to `/mcp` slash command in
  CLI for response. This will be used in VSCE MCP settings to show log in
  status, available tools etc.

  Shijie Rao · 2025-12-03 09:51:46 -08:00
  4785344c9c
• feat[app-serve]: config management (#7241)
  jif-oai · 2025-11-25 09:29:38 +00:00
  523b40a129
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874
• Migrate coverage to shell_command (#7042)
  pakrym-oai · 2025-11-21 03:44:00 +00:00
  767b66f407
• fix(app-server) remove www warning (#7046)

  ### Summary
  After #7022, we no longer need this warning. We should also clean up the
  schema for the notification, but this is a quick fix to just stop the
  behavior in the VSCE
  
  ## Testing
  - [x] Ran locally

  Dylan Hurd · 2025-11-20 19:18:39 -08:00
  3f73e2c892
• chore(app-server) world-writable windows notification (#6880)

  ## Summary
  On app-server startup, detect whether the experimental sandbox is
  enabled, and send a notification .
  
  **Note**
  New conversations will not respect the feature because we [ignore cli
  overrides in
  NewConversation](https://github.com/openai/codex/blob/a75321a64c990275ed4368bf26a5334c9ddfa0a7/codex-rs/app-server/src/codex_message_processor.rs#L1237-L1252).
  However, this should be okay, since we don't actually use config for
  this, we use a [global
  variable](https://github.com/openai/codex/blob/87cce88f4865685a863e143e0fad4cf5ea542e62/codex-rs/core/src/safety.rs#L105-L110).
  We should carefully unwind this setup at some point.
  
  
  ## Testing
  - [ ] In progress: testing locally
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Dylan Hurd · 2025-11-19 11:19:34 +00:00
  44c747837a
• [App server] add mcp tool call item started/completed events (#6642)

  this PR does two things:
  1. refactor `apply_bespoke_event_handling` into a separate file as it's
  getting kind of long;
  2. add mcp tool call `item/started` and `item/completed` events. To roll
  out app server events asap we didn't properly migrate mcp core events to
  use TurnItem for mcp tool calls - this will be a follow-up PR.
  
  real events generated in log:
  ```
  {
    "method": "codex/event/mcp_tool_call_end",
    "params": {
      "conversationId": "019a8021-26af-7c20-83db-21ca81e44d68",
      "id": "0",
      "msg": {
        "call_id": "call_7EjRQkD9HnfyMWf7tGrT9FKA",
        "duration": {
          "nanos": 92708,
          "secs": 0
        },
        "invocation": {
          "arguments": {
            "server": ""
          },
          "server": "codex",
          "tool": "list_mcp_resources"
        },
        "result": {
          "Ok": {
            "content": [
              {
                "text": "{\"resources\":[]}",
                "type": "text"
              }
            ],
            "isError": false
          }
        },
        "type": "mcp_tool_call_end"
      }
    }
  }
  
  {
    "method": "item/completed",
    "params": {
      "item": {
        "arguments": {
          "server": ""
        },
        "error": null,
        "id": "call_7EjRQkD9HnfyMWf7tGrT9FKA",
        "result": {
          "content": [
            {
              "text": "{\"resources\":[]}",
              "type": "text"
            }
          ],
          "structuredContent": null
        },
        "server": "codex",
        "status": "completed",
        "tool": "list_mcp_resources",
        "type": "mcpToolCall"
      }
    }
  }
  ```

  Celia Chen · 2025-11-14 08:08:43 -08:00
  526777c9b4
• Add feedback upload request handling (#5682)
  Ahmed Ibrahim · 2025-10-27 05:53:39 +00:00
  f178805252
• Fixed flaky unit test (#5654)

  This PR fixes a test that is sporadically failing in CI.
  
  The problem is that two unit tests (the older `login_and_cancel_chatgpt`
  and a recently added
  `login_chatgpt_includes_forced_workspace_query_param`) exercise code
  paths that start the login server. The server binds to a hard-coded
  localhost port number, so attempts to start more than one server at the
  same time will fail. If these two tests happen to run concurrently, one
  of them will fail.
  
  To fix this, I've added a simple mutex. We can use this same mutex for
  future tests that use the same pattern.

  Eric Traut · 2025-10-24 16:31:24 -07:00
  0533bd2e7c
• [otel] init otel for app-server (#5469)
  Anton Panasenko · 2025-10-21 12:34:27 -07:00
  682d05512f
• [app-server] read rate limits API (#5302)

  Adds a `GET account/rateLimits/read` API to app-server. This calls the
  codex backend to fetch the user's current rate limits.
  
  This would be helpful in checking rate limits without having to send a
  message.
  
  For calling the codex backend usage API, I generated the types and
  manually copied the relevant ones into `codex-backend-openapi-types`.
  It'll be nice to extend our internal openapi generator to support Rust
  so we don't have to run these manual steps.
  
  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.

  Owen Lin · 2025-10-20 14:11:54 -07:00
  5c680c6587
• fix: remove mcp-types from app server protocol (#4537)

  We continue the separation between `codex app-server` and `codex
  mcp-server`.
  
  In particular, we introduce a new crate, `codex-app-server-protocol`,
  and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it
  `codex-rs/app-server-protocol/src/protocol.rs`.
  
  Because `ConversationId` was defined in `mcp_protocol.rs`, we move it
  into its own file, `codex-rs/protocol/src/conversation_id.rs`, and
  because it is referenced in a ton of places, we have to touch a lot of
  files as part of this PR.
  
  We also decide to get away from proper JSON-RPC 2.0 semantics, so we
  also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which
  is basically the same `JSONRPCMessage` type defined in `mcp-types`
  except with all of the `"jsonrpc": "2.0"` removed.
  
  Getting rid of `"jsonrpc": "2.0"` makes our serialization logic
  considerably simpler, as we can lean heavier on serde to serialize
  directly into the wire format that we use now.

  Michael Bolin · 2025-10-01 02:16:26 +00:00
  5881c0d6d4
• fix: separate codex mcp into codex mcp-server and codex app-server (#4471)

  This is a very large PR with some non-backwards-compatible changes.
  
  Historically, `codex mcp` (or `codex mcp serve`) started a JSON-RPC-ish
  server that had two overlapping responsibilities:
  
  - Running an MCP server, providing some basic tool calls.
  - Running the app server used to power experiences such as the VS Code
  extension.
  
  This PR aims to separate these into distinct concepts:
  
  - `codex mcp-server` for the MCP server
  - `codex app-server` for the "application server"
  
  Note `codex mcp` still exists because it already has its own subcommands
  for MCP management (`list`, `add`, etc.)
  
  The MCP logic continues to live in `codex-rs/mcp-server` whereas the
  refactored app server logic is in the new `codex-rs/app-server` folder.
  Note that most of the existing integration tests in
  `codex-rs/mcp-server/tests/suite` were actually for the app server, so
  all the tests have been moved with the exception of
  `codex-rs/mcp-server/tests/suite/mod.rs`.
  
  Because this is already a large diff, I tried not to change more than I
  had to, so `codex-rs/app-server/tests/common/mcp_process.rs` still uses
  the name `McpProcess` for now, but I will do some mechanical renamings
  to things like `AppServer` in subsequent PRs.
  
  While `mcp-server` and `app-server` share some overlapping functionality
  (like reading streams of JSONL and dispatching based on message types)
  and some differences (completely different message types), I ended up
  doing a bit of copypasta between the two crates, as both have somewhat
  similar `message_processor.rs` and `outgoing_message.rs` files for now,
  though I expect them to diverge more in the near future.
  
  One material change is that of the initialize handshake for `codex
  app-server`, as we no longer use the MCP types for that handshake.
  Instead, we update `codex-rs/protocol/src/mcp_protocol.rs` to add an
  `Initialize` variant to `ClientRequest`, which takes the `ClientInfo`
  object we need to update the `USER_AGENT_SUFFIX` in
  `codex-rs/app-server/src/message_processor.rs`.
  
  One other material change is in
  `codex-rs/app-server/src/codex_message_processor.rs` where I eliminated
  a use of the `send_event_as_notification()` method I am generally trying
  to deprecate (because it blindly maps an `EventMsg` into a
  `JSONNotification`) in favor of `send_server_notification()`, which
  takes a `ServerNotification`, as that is intended to be a custom enum of
  all notification types supported by the app server. So to make this
  update, I had to introduce a new variant of `ServerNotification`,
  `SessionConfigured`, which is a non-backwards compatible change with the
  old `codex mcp`, and clients will have to be updated after the next
  release that contains this PR. Note that
  `codex-rs/app-server/tests/suite/list_resume.rs` also had to be update
  to reflect this change.
  
  I introduced `codex-rs/utils/json-to-toml/src/lib.rs` as a small utility
  crate to avoid some of the copying between `mcp-server` and
  `app-server`.

  Michael Bolin · 2025-09-30 07:06:18 +00:00
  d9dbf48828