168 Commits

• 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
• Cache cloud requirements (#11305)

  We're loading these from the web on every startup. This puts them in a
  local file with a 1hr TTL.
  
  We sign the downloaded requirements with a key compiled into the Codex
  CLI to prevent unsophisticated tampering (determined circumvention is
  outside of our threat model: after all, one could just compile Codex
  without any of these checks).
  
  If any of the following are true, we ignore the local cache and re-fetch
  from Cloud:
  * The signature is invalid for the payload (== requirements, sign time,
  ttl, user identity)
  * The identity does not match the auth'd user's identity
  * The TTL has expired
  * We cannot parse requirements.toml from the payload

  gt-oai · 2026-02-11 14:06:41 +00:00
  886d9377d3
• feat: support multiple rate limits (#11260)

  Added multi-limit support end-to-end by carrying limit_name in
  rate-limit snapshots and handling multiple buckets instead of only
  codex.
  Extended /usage client parsing to consume additional_rate_limits
  Updated TUI /status and in-memory state to store/render per-limit
  snapshots
  Extended app-server rate-limit read response: kept rate_limits and added
  rate_limits_by_name.
  Adjusted usage-limit error messaging for non-default codex limit buckets

  xl-openai · 2026-02-10 20:09:31 -08:00
  fdd0cd1de9
• chore: persist turn_id in rollout session and make turn_id uuid based (#11246)

  Problem:
  1. turn id is constructed in-memory;
  2. on resuming threads, turn_id might not be unique;
  3. client cannot no the boundary of a turn from rollout files easily.
  
  This PR does three things:
  1. persist `task_started` and `task_complete` events;
  1. persist `turn_id` in rollout turn events;
  5. generate turn_id as unique uuids instead of incrementing it in
  memory.
  
  This helps us resolve the issue of clients wanting to have unique turn
  ids for resuming a thread, and knowing the boundry of each turn in
  rollout files.
  
  example debug logs
  ```
  2026-02-11T00:32:10.746876Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=8 turn=Turn { id: "019c4a07-d809-74c3-bc4b-fd9618487b4b", items: [UserMessage { id: "item-24", content: [Text { text: "hi", text_elements: [] }] }, AgentMessage { id: "item-25", text: "Hi. I’m in the workspace with your current changes loaded and ready. Send the next task and I’ll execute it end-to-end." }], status: Completed, error: None }
  2026-02-11T00:32:10.746888Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=9 turn=Turn { id: "019c4a18-1004-76c0-a0fb-a77610f6a9b8", items: [UserMessage { id: "item-26", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-27", text: "Hello. Ready for the next change in `codex-rs`; I can continue from the current in-progress diff or start a new task." }], status: Completed, error: None }
  2026-02-11T00:32:10.746899Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=10 turn=Turn { id: "019c4a19-41f0-7db0-ad78-74f1503baeb8", items: [UserMessage { id: "item-28", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-29", text: "Hello. Send the specific change you want in `codex-rs`, and I’ll implement it and run the required checks." }], status: Completed, error: None }
  ```
  
  backward compatibility:
  if you try to resume an old session without task_started and
  task_complete event populated, the following happens:
  - If you resume and do nothing: those reconstructed historical IDs can
  differ next time you resume.
  - If you resume and send a new turn: the new turn gets a fresh UUID from
  live submission flow and is persisted, so that new turn’s ID is stable
  on later resumes.
  I think this behavior is fine, because we only care about deterministic
  turn id once a turn is triggered.

  Celia Chen · 2026-02-11 03:56:01 +00:00
  641d5268fa
• fix: reduce usage of open_if_present (#11344)
  jif-oai · 2026-02-10 19:25:07 +00:00
  847a6092e6
• 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
• feat: retain NetworkProxy, when appropriate (#11207)

  As of this PR, `SessionServices` retains a
  `Option<StartedNetworkProxy>`, if appropriate.
  
  Now the `network` field on `Config` is `Option<NetworkProxySpec>`
  instead of `Option<NetworkProxy>`.
  
  Over in `Session::new()`, we invoke `NetworkProxySpec::start_proxy()` to
  create the `StartedNetworkProxy`, which is a new struct that retains the
  `NetworkProxy` as well as the `NetworkProxyHandle`. (Note that `Drop` is
  implemented for `NetworkProxyHandle` to ensure the proxies are shutdown
  when it is dropped.)
  
  The `NetworkProxy` from the `StartedNetworkProxy` is threaded through to
  the appropriate places.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/11207).
  * #11285
  * __->__ #11207

  Michael Bolin · 2026-02-10 02:09:23 -08:00
  44ebf4588f
• [apps] Add thread_id param to optionally load thread config for apps feature check. (#11279)

  - [x] Add thread_id param to optionally load thread config for apps
  feature check

  Matthew Zeng · 2026-02-09 23:10:26 -08:00
  005e040f97
• fix(app-server): for external auth, replace id_token with chatgpt_acc… (#11240)

  …ount_id and chatgpt_plan_type
  
  ### Summary
  Following up on external auth mode which was introduced here:
  https://github.com/openai/codex/pull/10012
  
  Turns out some clients have a differently shaped ID token and don't have
  a chosen workspace (aka chatgpt_account_id) encoded in their ID token.
  So, let's replace `id_token` param with `chatgpt_account_id` and
  `chatgpt_plan_type` (optional) when initializing the external ChatGPT
  auth mode (`account/login/start` with `chatgptAuthTokens`).
  
  The client was able to test end-to-end with a Codex build from this
  branch and verified it worked!

  Owen Lin · 2026-02-09 20:48:58 -08:00
  53741013ab
• feat: extend skills/list to support additional roots. (#10835)

  Add an optional perCwdExtraUserRoots

  xl-openai · 2026-02-09 13:30:38 -08:00
  a33ee46e3b
• feat: do not close unified exec processes across turns (#10799)

  With this PR we do not close the unified exec processes (i.e. background
  terminals) at the end of a turn unless:
  * The user interrupt the turn
  * The user decide to clean the processes through `app-server` or
  `/clean`
  
  I made sure that `codex exec` correctly kill all the processes

  jif-oai · 2026-02-09 10:27:46 +00:00
  6cf61725d0
• feat: include NetworkConfig through ExecParams (#11105)

  This PR adds the following field to `Config`:
  
  ```rust
  pub network: Option<NetworkProxy>,
  ```
  
  Though for the moment, it will always be initialized as `None` (this
  will be addressed in a subsequent PR).
  
  This PR does the work to thread `network` through to `execute_exec_env()`, `process_exec_tool_call()`, and `UnifiedExecRuntime.run()` to ensure it is available whenever we span a process.

  Michael Bolin · 2026-02-09 03:32:17 +00:00
  383b45279e
• [apps] Improve app loading. (#10994)

  There are two concepts of apps that we load in the harness:
  
  - Directory apps, which is all the apps that the user can install.
  - Accessible apps, which is what the user actually installed and can be
  $ inserted and be used by the model. These are extracted from the tools
  that are loaded through the gateway MCP.
  
  Previously we wait for both sets of apps before returning the full apps
  list. Which causes many issues because accessible apps won't be
  available to the UI or the model if directory apps aren't loaded or
  failed to load.
  
  In this PR we are separating them so that accessible apps can be loaded
  separately and are instantly available to be shown in the UI and to be
  provided in model context. We also added an app-server event so that
  clients can subscribe to also get accessible apps without being blocked
  on the full app list.
  
  - [x] Separate accessible apps and directory apps loading.
  - [x] `app/list` request will also emit `app/list/updated` notifications
  that app-server clients can subscribe. Which allows clients to get
  accessible apps list to render in the $ menu without being blocked by
  directory apps.
  - [x] Cache both accessible and directory apps with 1 hour TTL to avoid
  reloading them when creating new threads.
  - [x] TUI improvements to redraw $ menu and /apps menu when app list is
  updated.

  Matthew Zeng · 2026-02-08 15:24:56 -08:00
  45b7763c3f
• Defer persistence of rollout file (#11028)

  - Defer rollout persistence for fresh threads (`InitialHistory::New`):
  keep rollout events in memory and only materialize rollout file + state
  DB row on first `EventMsg::UserMessage`.
  - Keep precomputed rollout path available before materialization.
  - Change `thread/start` to build thread response from live config
  snapshot and optional precomputed path.
  - Improve pre-materialization behavior in app-server/TUI: clearer
  invalid-request errors for file-backed ops and a friendlier `/fork` “not
  ready yet” UX.
  - Update tests to match deferred semantics across
  start/read/archive/unarchive/fork/resume/review flows.
  - Improved resilience of user_shell test, which should be unrelated to
  this change but must be affected by timing changes
  
  For Reviewers:
  * The primary change is in recorder.rs
  * Most of the other changes were to fix up broken assumptions in
  existing tests
  
  Testing:
  * Manually tested CLI
  * Exercised app server paths by manually running IDE Extension with
  rebuilt CLI binary
  * Only user-visible change is that `/fork` in TUI generates visible
  error if used prior to first turn

  Eric Traut · 2026-02-07 23:05:03 -08:00
  b3de6c7f2b
• app-server: treat null mode developer instructions as built-in defaults (#10983)

  ## Summary
  - make `turn/start` normalize
  `collaborationMode.settings.developer_instructions: null` to the
  built-in instructions for the selected mode
  - prevent app-server clients from accidentally clearing mode-switch
  developer instructions by sending `null`
  - document this behavior in the v2 protocol and app-server docs
  
  ## What changed
  - `codex-rs/app-server/src/codex_message_processor.rs`
    - added a small `normalize_turn_start_collaboration_mode` helper
    - in `turn_start`, apply normalization before `OverrideTurnContext`
  - `codex-rs/app-server/tests/suite/v2/turn_start.rs`
  - extended `turn_start_accepts_collaboration_mode_override_v2` to assert
  the outgoing request includes default-mode instruction text when the
  client sends `developer_instructions: null`
  - `codex-rs/app-server-protocol/src/protocol/v2.rs`
  - clarified `TurnStartParams.collaboration_mode` docs:
  `settings.developer_instructions: null` means use built-in mode
  instructions
  - regenerated schema fixture:
  - `codex-rs/app-server-protocol/schema/typescript/v2/TurnStartParams.ts`
  - docs:
    - `codex-rs/app-server/README.md`
    - `codex-rs/docs/codex_mcp_interface.md`

  Charley Cunningham · 2026-02-07 12:59:41 -08:00
  e6662d6387
• feat(app-server): turn/steer API (#10821)

  This PR adds a dedicated `turn/steer` API for appending user input to an
  in-flight turn.
  
  ## Motivation
  Currently, steering in the app is implemented by just calling
  `turn/start` while a turn is running. This has some really weird quirks:
  - Client gets back a new `turn.id`, even though streamed
  events/approvals remained tied to the original active turn ID.
  - All the various turn-level override params on `turn/start` do not
  apply to the "steer", and would only apply to the next real turn.
  - There can also be a race condition where the client thinks the turn is
  active but the server has already completed it, so there might be bugs
  if the client has baked in some client-specific behavior thinking it's a
  steer when in fact the server kicked off a new turn. This is
  particularly possible when running a client against a remote app-server.
  
  Having a dedicated `turn/steer` API eliminates all those quirks.
  
  `turn/steer` behavior:
  - Requires an active turn on threadId. Returns a JSON-RPC error if there
  is no active turn.
  - If expectedTurnId is provided, it must match the active turn (more
  useful when connecting to a remote app-server).
  - Does not emit `turn/started`.
  - Does not accept turn overrides (`cwd`, `model`, `sandbox`, etc.) or
  `outputSchema` to accurately reflect that these are not applied when
  steering.

  Owen Lin · 2026-02-06 00:35:04 +00:00
  0d8b2b74c4
• Add stage field for experimental flags. (#10793)

  - [x] Add stage field for experimental flags.

  Matthew Zeng · 2026-02-05 23:31:04 +00:00
  729b016515
• Sync app-server requirements API with refreshed cloud loader (#10815)

  configRequirements/read now returns updated cloud requirements after
  login.

  xl-openai · 2026-02-05 14:43:31 -08:00
  43a7290f11
• 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
• [app-server] Add a method to list experimental features. (#10721)

  - [x] Add a method to list experimental features.

  Matthew Zeng · 2026-02-05 20:04:01 +00:00
  7e81f63698
• fix(auth): isolate chatgptAuthTokens concept to auth manager and app-server (#10423)

  So that the rest of the codebase (like TUI) don't need to be concerned
  whether ChatGPT auth was handled by Codex itself or passed in via
  app-server's external auth mode.

  Owen Lin · 2026-02-05 10:46:06 -08:00
  3582b74d01
• Leverage state DB metadata for thread summaries (#10621)

  Summary:
  - read conversation summaries and cwd info from the state DB when
  possible so we no longer rely on rollout files for metadata and avoid
  extra I/O
  - persist CLI version in thread metadata, surface it through summary
  builders, and add the necessary DB migration hooks
  - simplify thread listing by using enriched state DB data directly
  rather than reading rollout heads
  
  Testing:
  - Not run (not requested)

  jif-oai · 2026-02-05 16:39:11 +00:00
  9ee746afd6
• Reload cloud requirements after user login (#10725)

  Reload cloud requirements after user login so it could take effect
  immediately.

  xl-openai · 2026-02-05 00:27:16 -08:00
  1e1146cd29
• feat(linux-sandbox): add bwrap support (#9938)

  ## Summary
  This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
  curent Linux sandbox path relies on in-process restrictions (including
  Landlock). Bubblewrap gives us a more uniform filesystem isolation
  model, especially explicit writable roots with the option to make some
  directories read-only and granular network controls.
  
  This is behind a feature flag so we can validate behavior safely before
  making it the default.
  
  - Added temporary rollout flag:
    - `features.use_linux_sandbox_bwrap`
  - Preserved existing default path when the flag is off.
  - In Bubblewrap mode:
  - Added internal retry without /proc when /proc mount is not permitted
  by the host/container.

  viyatb-oai · 2026-02-04 11:13:17 -08:00
  ae4de43ccc
• Add thread/compact v2 (#10445)

  - add `thread/compact` as a trigger-only v2 RPC that submits
  `Op::Compact` and returns `{}` immediately.
  - add v2 compaction e2e coverage for success and invalid/unknown thread
  ids, and update protocol schemas/docs.

  Ahmed Ibrahim · 2026-02-03 18:15:55 -08:00
  38a47700b5
• feat: add APIs to list and download public remote skills (#10448)

  Add API to list / download from remote public skills

  xl-openai · 2026-02-03 14:09:37 -08:00
  f38d181795
• Inject CODEX_THREAD_ID into the terminal environment (#10096)

  Inject CODEX_THREAD_ID (when applicable) into the terminal environment
  so that the agent (and skills) can refer to the current thread / session
  ID.
  
  Discussion:
  https://openai.slack.com/archives/C095U48JNL9/p1769542492067109

  Max Johnson · 2026-02-03 11:31:12 -08:00
  66b196a725
• feat: experimental flags (#10231)

  ## Problem being solved
  - We need a single, reliable way to mark app-server API surface as
  experimental so that:
    1. the runtime can reject experimental usage unless the client opts in
  2. generated TS/JSON schemas can exclude experimental methods/fields for
  stable clients.
  
  Right now that’s easy to drift or miss when done ad-hoc.
  
  ## How to declare experimental methods and fields
  - **Experimental method**: add `#[experimental("method/name")]` to the
  `ClientRequest` variant in `client_request_definitions!`.
  - **Experimental field**: on the params struct, derive `ExperimentalApi`
  and annotate the field with `#[experimental("method/name.field")]` + set
  `inspect_params: true` for the method variant so
  `ClientRequest::experimental_reason()` inspects params for experimental
  fields.
  
  ## How the macro solves it
  - The new derive macro lives in
  `codex-rs/codex-experimental-api-macros/src/lib.rs` and is used via
  `#[derive(ExperimentalApi)]` plus `#[experimental("reason")]`
  attributes.
  - **Structs**:
  - Generates `ExperimentalApi::experimental_reason(&self)` that checks
  only annotated fields.
    - The “presence” check is type-aware:
      - `Option<T>`: `is_some_and(...)` recursively checks inner.
      - `Vec`/`HashMap`/`BTreeMap`: must be non-empty.
      - `bool`: must be `true`.
      - Other types: considered present (returns `true`).
  - Registers each experimental field in an `inventory` with `(type_name,
  serialized field name, reason)` and exposes `EXPERIMENTAL_FIELDS` for
  that type. Field names are converted from `snake_case` to `camelCase`
  for schema/TS filtering.
  - **Enums**:
  - Generates an exhaustive `match` returning `Some(reason)` for annotated
  variants and `None` otherwise (no wildcard arm).
  - **Wiring**:
  - Runtime gating uses `ExperimentalApi::experimental_reason()` in
  `codex-rs/app-server/src/message_processor.rs` to reject requests unless
  `InitializeParams.capabilities.experimental_api == true`.
  - Schema/TS export filters use the inventory list and
  `EXPERIMENTAL_CLIENT_METHODS` from `client_request_definitions!` to
  strip experimental methods/fields when `experimental_api` is false.

  jif-oai · 2026-02-02 11:06:50 +00:00
  3cc9122ee2
• Bump thread updated_at on unarchive to refresh sidebar ordering (#10280)

  ## Summary
  - Touch restored rollout files on `thread/unarchive` so `updatedAt`
  reflects the unarchive time.
  - Add a regression test to ensure unarchiving bumps `updated_at` from an
  old mtime.
  
  ## Notes
  This fixes the UX issue where unarchived old threads don’t reappear near
  the top of recent threads.

  Charley Cunningham · 2026-02-01 12:53:47 -08:00
  d3514bbdd2
• chore(config) Rename config setting to personality (#10314)

  ## Summary
  Let's make the setting name consistent with the SlashCommand!
  
  ## Testing
  - [x] Updated tests

  Dylan Hurd · 2026-01-31 19:38:06 -08:00
  a33fa4bfe5
• 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
• chore: rename ChatGpt -> Chatgpt in type names (#10244)

  When using ChatGPT in names of types, we should be consistent, so this
  renames some types with `ChatGpt` in the name to `Chatgpt`. From
  https://rust-lang.github.io/api-guidelines/naming.html:
  
  > In `UpperCamelCase`, acronyms and contractions of compound words count
  as one word: use `Uuid` rather than `UUID`, `Usize` rather than `USize`
  or `Stdin` rather than `StdIn`. In `snake_case`, acronyms and
  contractions are lower-cased: `is_xid_start`.
  
  This PR updates existing uses of `ChatGpt` and changes them to
  `Chatgpt`. Though in all cases where it could affect the wire format, I
  visually inspected that we don't change anything there. That said, this
  _will_ change the codegen because it will affect the spelling of type
  names.
  
  For example, this renames `AuthMode::ChatGPT` to `AuthMode::Chatgpt` in
  `app-server-protocol`, but the wire format is still `"chatgpt"`.
  
  This PR also updates a number of types in `codex-rs/core/src/auth.rs`.

  Michael Bolin · 2026-01-30 11:18:39 -08:00
  e6d913af2d
• feat: refactor CodexAuth so invalid state cannot be represented (#10208)

  Previously, `CodexAuth` was defined as follows:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L39-L46
  
  But if you looked at its constructors, we had creation for
  `AuthMode::ApiKey` where `storage` was built using a nonsensical path
  (`PathBuf::new()`) and `auth_dot_json` was `None`:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L212-L220
  
  By comparison, when `AuthMode::ChatGPT` was used, `api_key` was always
  `None`:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L665-L671
  
  https://github.com/openai/codex/pull/10012 took things further because
  it introduced a new `ChatgptAuthTokens` variant to `AuthMode`, which is
  important in when invoking `account/login/start` via the app server, but
  most logic _internal_ to the app server should just reason about two
  `AuthMode` variants: `ApiKey` and `ChatGPT`.
  
  This PR tries to clean things up as follows:
  
  - `LoginAccountParams` and `AuthMode` in `codex-rs/app-server-protocol/`
  both continue to have the `ChatgptAuthTokens` variant, though it is used
  exclusively for the on-the-wire messaging.
  - `codex-rs/core/src/auth.rs` now has its own `AuthMode` enum, which
  only has two variants: `ApiKey` and `ChatGPT`.
  - `CodexAuth` has been changed from a struct to an enum. It is a
  disjoint union where each variant (`ApiKey`, `ChatGpt`, and
  `ChatGptAuthTokens`) have only the associated fields that make sense for
  that variant.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10208).
  * #10224
  * __->__ #10208

  Michael Bolin · 2026-01-30 09:33:23 -08:00
  377ab0c77c
• Conversation naming (#8991)

  Session renaming:
  - `/rename my_session`
  - `/rename` without arg and passing an argument in `customViewPrompt`
  - AppExitInfo shows resume hint using the session name if set instead of
  uuid, defaults to uuid if not set
  - Names are stored in `CODEX_HOME/sessions.jsonl`
  
  Session resuming:
  - codex resume <name> lookup for `CODEX_HOME/sessions.jsonl` first entry
  matching the name and resumes the session
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  pap-openai · 2026-01-30 10:40:09 +00:00
  1ef5455eb6
• 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: async backfill (#10089)
  jif-oai · 2026-01-29 09:57:50 +00:00
  714dc8d8bd
• [connectors] Support connectors part 2 - slash command and tui (#9728)

  - [x] Support `/apps` slash command to browse the apps in tui.
  - [x] Support inserting apps to prompt using `$`.
  - [x] Lots of simplification/renaming from connectors to apps.

  Matthew Zeng · 2026-01-28 19:51:58 -08:00
  b9cd089d1f
• feat: sqlite 1 (#10004)

  Add a `.sqlite` database to be used to store rollout metatdata (and
  later logs)
  This PR is phase 1:
  * Add the database and the required infrastructure
  * Add a backfill of the database
  * Persist the newly created rollout both in files and in the DB
  * When we need to get metadata or a rollout, consider the `JSONL` as the
  source of truth but compare the results with the DB and show any errors

  jif-oai · 2026-01-28 15:29:14 +01:00
  3878c3dc7c
• [skills] Auto install MCP dependencies when running skils with dependency specs. (#9982)

  Auto install MCP dependencies when running skils with dependency specs.

  Matthew Zeng · 2026-01-27 19:02:45 -08:00
  3bb8e69dd3
• remove sandbox globals. (#9797)

  Threads sandbox updates through OverrideTurnContext for active turn
  Passes computed sandbox type into safety/exec

  iceweasel-oai · 2026-01-27 11:04:23 -08:00
  c40ad65bd8
• Add MCP server scopes config and use it as fallback for OAuth login (#9647)

  ### Motivation
  - Allow MCP OAuth flows to request scopes defined in `config.toml`
  instead of requiring users to always pass `--scopes` on the CLI.
  CLI/remote parameters should still override config values.
  
  ### Description
  - Add optional `scopes: Option<Vec<String>>` to `McpServerConfig` and
  `RawMcpServerConfig`, and propagate it through deserialization and the
  built config types.
  - Serialize `scopes` into the MCP server TOML via
  `serialize_mcp_server_table` in `core/src/config/edit.rs` and include
  `scopes` in the generated config schema (`core/config.schema.json`).
  - CLI: update `codex-rs/cli/src/mcp_cmd.rs` `run_login` to fall back to
  `server.scopes` when the `--scopes` flag is empty, with explicit CLI
  scopes still taking precedence.
  - App server: update
  `codex-rs/app-server/src/codex_message_processor.rs`
  `mcp_server_oauth_login` to use `params.scopes.or_else(||
  server.scopes.clone())` so the RPC path also respects configured scopes.
  - Update many test fixtures to initialize the new `scopes` field (set to
  `None`) so test code builds with the new struct field.
  
  ### Testing
  - Ran config tooling and formatters: `just write-config-schema`
  (succeeded), `just fmt` (succeeded), and `just fix -p codex-core`, `just
  fix -p codex-cli`, `just fix -p codex-app-server` (succeeded where
  applicable).
  - Ran unit tests for the CLI: `cargo test -p codex-cli` (passed).
  - Ran unit tests for core: `cargo test -p codex-core` (ran; many tests
  passed but several failed, including model refresh/403-related tests,
  shell snapshot/timeouts, and several `unified_exec` expectations).
  - Ran app-server tests: `cargo test -p codex-app-server` (ran; many
  integration-suite tests failed due to mocked/remote HTTP 401/403
  responses and wiremock expectations).
  
  If you want, I can split the tests into smaller focused runs or help
  debug the failing integration tests (they appear to be unrelated to the
  config change and stem from external HTTP/mocking behaviors encountered
  during the test runs).
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_69718f505914832ea1f334b3ba064553)

  blevy-oai · 2026-01-26 14:13:04 -08:00
  bdc4742bfc
• [app-server] feat: add filtering on thread list (#9897)
  jif-oai · 2026-01-26 21:54:19 +00:00
  247fb2de64
• Add thread/unarchive to restore archived rollouts (#9843)

  ## Summary
  - Adds a new `thread/unarchive` RPC to move archived thread rollouts
  back into the active `sessions/` tree.
  
  ## What changed
  - **Protocol**
    - Adds `thread/unarchive` request/response types and wiring.
  - **Server**
    - Implements `thread_unarchive` in the app server.
    - Validates the archived rollout path and thread ID.
  - Restores the rollout to `sessions/YYYY/MM/DD/...` based on the rollout
  filename timestamp.
  - **Core**
  - Adds `find_archived_thread_path_by_id_str` helper for archived
  rollouts.
  - **Docs**
    - Documents the new RPC and usage example.
  - **Tests**
    - Adds an end-to-end server test that:
      1) starts a thread,
      2) archives it,
      3) unarchives it,
      4) asserts the file is restored to `sessions/`.
  
  ## How to use
  ```json
  { "method": "thread/unarchive", "id": 24, "params": { "threadId": "<thread-id>" } }
  ```
  
  ## Author Codex Session
  
  `codex resume 019bf158-54b6-7960-a696-9d85df7e1bc1` (soon I'll make this
  kind of session UUID forkable by anyone with the right
  `session_object_storage_url` line in their config, but for now just
  pasting it here for my reference)

  Charley Cunningham · 2026-01-26 11:24:36 -08:00
  62266b13f8
• feat: dynamic tools injection (#9539)

  ## Summary
  Add dynamic tool injection to thread startup in API v2, wire dynamic
  tool calls through the app server to clients, and plumb responses back
  into the model tool pipeline.
  
  ### Flow (high level)
  - Thread start injects `dynamic_tools` into the model tool list for that
  thread (validation is done here).
  - When the model emits a tool call for one of those names, core raises a
  `DynamicToolCallRequest` event.
  - The app server forwards it to the client as `item/tool/call`, waits
  for the client’s response, then submits a `DynamicToolResponse` back to
  core.
  - Core turns that into a `function_call_output` in the next model
  request so the model can continue.
  
  ### What changed
  - Added dynamic tool specs to v2 thread start params and protocol types;
  introduced `item/tool/call` (request/response) for dynamic tool
  execution.
  - Core now registers dynamic tool specs at request time and routes those
  calls via a new dynamic tool handler.
  - App server validates tool names/schemas, forwards dynamic tool call
  requests to clients, and publishes tool outputs back into the session.
  - Integration tests

  jif-oai · 2026-01-26 10:06:44 +00:00
  d594693d1a
• 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
• feat(app-server) Expose personality (#9674)

  ### Motivation
  Exposes a per-thread / per-turn `personality` override in the v2
  app-server API so clients can influence model communication style at
  thread/turn start. Ensures the override is passed into the session
  configuration resolution so it becomes effective for subsequent turns
  and headless runners.
  
  ### Testing
  - [x] Add an integration-style test
  `turn_start_accepts_personality_override_v2` in
  `codex-rs/app-server/tests/suite/v2/turn_start.rs` that verifies a
  `/personality` override results in a developer update message containing
  `<personality_spec>` in the outbound model request.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6971d646b1c08322a689a54d2649f3fe)

  Dylan Hurd · 2026-01-22 18:00:20 -08:00
  2b1ee24e11
• [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(app-server): support archived threads in thread/list (#9571)
  Owen Lin · 2026-01-22 12:22:36 -08:00
  733cb68496
• feat(app-server): thread/read API (#9569)
  Owen Lin · 2026-01-22 12:22:01 -08:00
  80240b3b67
• feat(core) update Personality on turn (#9644)

  ## Summary
  Support updating Personality mid-Thread via UserTurn/OverwriteTurn. This
  is explicitly unused by the clients so far, to simplify PRs - app-server
  and tui implementations will be follow-ups.
  
  ## Testing
  - [x] added integration tests

  Dylan Hurd · 2026-01-22 12:04:23 -08:00
  8b3521ee77