235 Commits

• [3/3] app-server: configure environment connection timeout (#29025)

  ## Why
  
  Remote environments registered through `environment/add` currently use
  the fixed 10-second WebSocket connection timeout. Slow-starting
  executors need a caller-selected connection window, but this should not
  add retry policy or couple exec-server behavior to Core’s
  `deferred_executor` feature.
  
  Make the timeout an optional part of the existing experimental request.
  Existing clients continue using the current default, while callers that
  know an executor may take longer can request a larger window explicitly.
  
  Depends on #28683.
  
  ## What changed
  
  - Add optional `connectTimeoutMs` to `EnvironmentAddParams` and document
  it in the app-server README.
  - Pass the optional timeout through `EnvironmentRequestProcessor` into
  one `EnvironmentManager::upsert_environment()` path; the manager applies
  the existing default when it is omitted.
  - Preserve the existing single-attempt lifecycle. The configured value
  controls WebSocket connection and handshake time for both initial
  connection and later reconnects; initialization retains its separate
  timeout.
  - Add an app-server integration test that sends the real JSON-RPC
  request and verifies a stalled handshake observes the requested timeout.
  
  ## Test plan
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-exec-server`
  - `just test -p codex-app-server
  environment_add_applies_connect_timeout`
  
  ## Rollout
  
  This is additive and does not enable `deferred_executor`. Callers should
  send a non-default timeout only after a compatible app-server is
  deployed; omitted or `null` values retain the existing 10-second
  default.

  sayan-oai · 2026-06-19 05:27:45 +00:00
  f886e33e5a
• Always use AVAS for realtime WebRTC calls (#28856)

  ## Summary
  
  - Remove the realtime `architecture` selector from core protocol,
  app-server protocol, config parsing, generated schemas, and callers.
  - Always create WebRTC realtime calls with the AVAS query params:
  `intent=quicksilver&architecture=avas`.
  - Keep direct websocket realtime behavior on the existing config/default
  path, while WebRTC starts without an explicit version now default to
  realtime v1 because AVAS requires v1.
  
  ## Notes
  
  - WebRTC realtime now means AVAS. If a caller explicitly asks to start
  WebRTC with realtime v2, Codex rejects that request because the AVAS
  WebRTC path only supports realtime v1. Websocket realtime is separate
  and can still use realtime v2.
  - The old `[realtime] architecture = "realtimeapi" | "avas"` config knob
  is removed. Local configs that still set it will need to delete that
  line.
  - Some app-server tests that were only trying to exercise realtime v2
  protocol behavior now use websocket transport, because WebRTC is
  intentionally locked to AVAS/v1. Separate WebRTC tests cover the AVAS
  query params, v1 startup, SDP flow, and sideband join.
  
  ## Validation
  
  - Merged fresh `origin/main` at `83e6a786a2`.
  - `just fmt`
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `git diff --check`
  - `just test -p codex-api -p codex-core -p codex-app-server-protocol -p
  codex-app-server realtime` (176 passed)
  - `just test -p codex-protocol -p codex-config` (413 passed)

  Peter Bakkum · 2026-06-18 19:11:21 -05:00
  8e7c213f8f
• core: load AGENTS.md from foreign environments (#28958)

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

  Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00
  dce673905a
• Add app-server current-time impl (varlatency 3/n) (#28835)

  ## What
  
  Server should request:
  
  ```
  {
    "id": 42,
    "method": "currentTime/read",
    "params": {
      "threadId": "11111111-1111-1111-1111-aaaaafdc2c11"
    }
  }
  ```
  
  Client should respond with something like:
  
  ```rust
  {
    "id": 42,
    "result": {
      "currentTimeAt": 1781717655
    }
  }
  ```
  
  ## Why
  
  Sessions configured with `clock_source = "external"` need a
  thread-specific external time source before inference. The system clock
  remains the default production provider.
  
  ## Validation
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server --test all
  current_time_read_round_trip_adds_reminder_to_model_input`
  - `cargo test -p codex-app-server
  first_attestation_capable_connection_for_thread_only_uses_thread_subscribers`
  - `cargo test -p codex-analytics`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  
  Stacked on #28824.

  rka-oai · 2026-06-18 13:12:11 -07:00
  f4602b7516
• Support openai/form extended form elicitations (#27500)

  # Summary
  Allow App Server clients to opt into `openai/form` MCP elicitations.

  Gabriel Peal · 2026-06-18 11:54:49 -07:00
  21a599fa56
• [codex] control automatic realtime handoff delivery (#27986)

  ## What
  
  Built on the realtime speech-control plumbing merged in #27917.
  
  - Add optional `codexResponseHandoffPrefix` to `thread/realtime/start`.
  - Apply that prefix only to automatic V1 commentary sent through
  `conversation.handoff.append`; final answers remain unprefixed.
  - Add opt-in `clientManagedHandoffs`. When true, core suppresses
  automatic response handoffs and completion output so delivery is
  controlled by explicit client append APIs.
  - Preserve existing automatic behavior by default.
  `codexResponsesAsItems: true` continues to select item routing when
  client-managed mode is disabled.
  
  ## Why
  
  Voice clients need two delivery policies: automatic background context
  with silent commentary instructions and fully client-owned handoffs.
  Phase-aware prefixing keeps routine commentary silent without
  suppressing the final answer, while client-managed mode lets an app
  decide exactly which updates to append.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-app-server-protocol
  serialize_thread_realtime_start`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core --test all
  conversation_handoff_persists_across_item_done_until_turn_complete`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-app-server --test all
  webrtc_v1_client_managed_handoffs_disable_automatic_output`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-app-server --test all
  webrtc_v1_final_automatic_handoff_omits_silent_prefix`
  - `cargo build -p codex-cli --bin codex`
  - Local Codex Apps compatibility check: 43 focused webview tests passed,
  and a live voice session routed through the source-built app-server.
  
  The explicit `RUST_MIN_STACK` avoids a macOS Tokio test-worker stack
  overflow seen with the default test environment.

  jiayuhuang-openai · 2026-06-18 02:22:29 +00:00
  683bd170dc
• [codex] Restore thread recency with compatible migration history (#28671)

  ## Summary
  
  - Revert #28655, restoring the thread `recencyAt` behavior introduced by
  #27910.
  - Move `threads_recency_at` to migration 0039 so it no longer collides
  with `external_agent_config_imports` at version 0038.
  - Repair databases that already applied the recency migration as version
  38 by moving the matching migration-history row to version 39 before
  SQLx validation. The current version-38 migration can then apply
  normally.
  
  ## Validation
  
  - `just test -p codex-state
  migrations::tests::repairs_recency_migration_that_was_applied_as_version_38`
  - `just test -p codex-state -p codex-rollout -p codex-thread-store -p
  codex-app-server-protocol -p codex-tui`: 3,439 passed; six TUI tests
  could not open the machine's existing read-only incident database at
  `~/.codex/sqlite/state_5.sqlite`.
  - `just fix -p codex-state`
  - `just fmt`
  - Verified that state migration versions are unique.

  Jeremy Rose · 2026-06-17 18:52:18 +00:00
  7dc7096ae1
• Scope command approvals by execution environment (#28738)

  ## Why
  
  Command approval cache keys included the command and working directory,
  but not the execution environment. An approval for `/workspace` locally
  could therefore be reused for the same command and path on an executor.
  
  ## What changed
  
  - Include the selected environment ID in shell and unified-exec approval
  cache keys.
  - Carry that ID through the normal command approval request so clients
  can show which environment is being approved.
  - Expose the environment through app-server as a required nullable
  `environmentId` and show it in the inline TUI approval prompt.
  - Keep older recorded approval events compatible when the environment is
  absent.
  
  For example, `echo ok` in local `/workspace` and `echo ok` in executor
  `/workspace` now produce different approval keys and separate prompts.
  
  ## Scope
  
  This PR does not change network approvals, Guardian review actions, MCP
  elicitation, full-screen TUI rendering, or environment-ID validation.
  Remote `shell_command` execution itself remains in #28722; this PR only
  makes its approval key environment-aware.

  jif · 2026-06-17 19:52:43 +02:00
  1391d786bc
• Revert thread recencyAt for sidebar ordering (#28655)

  ## Why
  
  Revert #27910 to remove the newly introduced thread `recencyAt`
  persistence and API behavior from `main`.
  
  ## What changed
  
  This reverts commit `fac3158c2a783095768076489815f361fa9b0db4`,
  including the state migration, thread-store propagation, app-server API
  surface, generated schemas, and related tests.
  
  ## Validation
  
  Not run before opening; relying on CI for the initial fast signal.

  pakrym-oai · 2026-06-16 21:39:30 -07:00
  cb15c64760
• Add thread recencyAt for sidebar ordering (#27910)

  ## Summary
  
  Add a server-owned `recencyAt` timestamp and `recency_at` thread-list
  sort key for product recency ordering while preserving the existing
  meaning of `updatedAt` as the latest persisted thread mutation.
  
  This is the server-side alternative to #27697. Rather than narrowing
  `updatedAt`, clients can sort the sidebar by `recency_at` and continue
  treating `updatedAt` as mutation time.
  
  Paired Codex Apps PR:
  [openai/openai#1024599](https://github.com/openai/openai/pull/1024599)
  
  ## Contract
  
  - `recencyAt` initializes when a thread is created.
  - A turn start advances `recencyAt` monotonically.
  - Commentary, agent output, tool results, token/accounting updates, turn
  completion, archive, unarchive, resume, and generic metadata writes do
  not advance it.
  - `updatedAt` retains its existing behavior and continues to advance for
  persisted thread mutations.
  - Current servers populate `recencyAt`; the response field is optional
  in generated TypeScript so clients connected to older servers can fall
  back to `updatedAt`.
  - Filesystem-only fallback uses existing updated/mtime ordering when
  SQLite is unavailable.
  
  ## Persistence and compatibility
  
  Migration 0038 adds second- and millisecond-precision recency columns,
  backfills them from the existing updated timestamp, creates list
  indexes, and includes an insert trigger so older binaries writing to a
  migrated database seed recency without causing later mutations to
  advance it.
  
  Generic metadata upserts preserve existing recency values. Turn-start
  updates use a dedicated monotonic touch, and process-local allocation
  keeps millisecond cursor values unique. State DB list, search, read,
  filtered-list repair, rollout fallback propagation, and app-server
  conversions all carry the new field.
  
  ## API
  
  `Thread` responses include:
  
  ```ts
  recencyAt?: number
  ```
  
  `thread/list` and `thread/search` accept:
  
  ```json
  { "sortKey": "recency_at" }
  ```
  
  Generated TypeScript and JSON schemas are included.
  
  ## Validation
  
  - `just test -p codex-state` — 146 passed
  - `just test -p codex-rollout` — 69 passed
  - `just test -p codex-thread-store` — 81 passed
  - `just test -p codex-app-server-protocol` — 231 passed
  - Focused app-server list ordering, response mapping, archive/unarchive,
  and resume lifecycle tests passed
  - Scoped `just fix` for state, rollout, thread-store,
  app-server-protocol, and app-server
  - `just fmt`
  - `git diff --check`
  - Independent correctness, simplicity, elegance, security, and
  test-quality reviews; actionable ordering, lifecycle, query-projection,
  and timestamp-uniqueness findings were addressed

  Jeremy Rose · 2026-06-16 17:06:22 -07:00
  fac3158c2a
• [codex] expose Bedrock credential source in account/read (#27751)

  ## Why
  
  `account/read` currently reports only `type: "amazonBedrock"`, so
  clients cannot distinguish a Codex-managed Bedrock API key from
  credentials supplied by AWS. The app UI needs that distinction to render
  the appropriate account state without duplicating provider-auth logic.
  
  Credential-source selection belongs to the Bedrock model provider
  because it already owns the precedence between managed Bedrock auth and
  the external AWS credential path. This builds on #27443 and #27689.
  
  ## What changed
  
  - Added `AmazonBedrockCredentialSource` with `codexManaged` and
  `awsManaged` values.
  - Included the selected credential source in
  `ProviderAccount::AmazonBedrock` and the app-server `Account` response.
  - Made `AmazonBedrockModelProvider::account_state()` classify the source
  from its managed-auth state.
  - Regenerated the app-server JSON and TypeScript schemas.
  - Updated app-server account documentation and downstream TUI matches.
  
  `codexManaged` means the provider found a managed Bedrock API key.
  `awsManaged` identifies the provider's external AWS credential path; it
  does not assert that the AWS credential chain has been validated.
  
  ## Testing
  
  - Added model-provider coverage for Codex-managed precedence and
  AWS-managed fallback.
  - Added app-server protocol serialization coverage for both wire values.
  - Added app-server integration coverage for both `account/read`
  responses.
  - `just test -p codex-protocol -p codex-model-provider -p
  codex-app-server-protocol` (497 tests passed).
  
  After rebasing onto #27711, the `codex-app-server` test target compiled
  past the image-generation `PathUri` migration. Local linking was then
  interrupted by disk exhaustion (`No space left on device`).

  Celia Chen · 2026-06-16 07:14:53 +00:00
  12aaeb7bf8
• [codex] Record external agent import results (#28396)

  ## Summary
  - restore `externalAgentConfig/import/progress` notifications while
  keeping `externalAgentConfig/import/completed` as the must-deliver event
  - persist completed external-agent config imports in state DB by
  `importId`, including concrete success/failure details for config,
  AGENTS.md, skills, plugins, MCP servers, subagents, hooks, commands, and
  sessions
  - add `externalAgentConfig/import/readHistories` so clients can recover
  persisted import results after missing the live completion notification
  - include `errorType` on import failures in protocol
  responses/notifications and persisted DB JSON so future code can
  classify failures without another wire/storage shape change
  
  ## Validation
  - `git diff --check`
  - `just test -p codex-state external_agent_config_imports`
  - `just test -p codex-app-server-protocol`
  - `CODEX_SQLITE_HOME=/private/tmp/codex-app-server-sqlite-read-details
  just test -p codex-app-server
  external_agent_config_import_sends_completion_notification_for_sync_only_import`
  
  Also ran earlier broader checks before publishing:
  - `just test -p codex-state`
  -
  `CODEX_SQLITE_HOME=/private/tmp/codex-app-server-external-agent-test-sqlite
  just test -p codex-app-server external_agent_config`
  - `just test -p codex-external-agent-migration`

  charlesgong-openai · 2026-06-15 23:17:24 -07:00
  314fa3d25b
• Use ApiPathString in app-server filesystem permission paths (#28367)

  ## Why
  
  Clients running an app-server on one OS and an exec-server on another OS
  need to be able to pass sandbox config to app-server that refers to
  resources on the executor's foreign OS.
  
  ## What
  
  `AbsolutePathBuf` can't represent these paths and we don't want users to
  be exposed to `PathUri` yet, so this moves the public app-server API to
  be expressed in terms of `ApiPathString`.
  
  Stacked on #28165.
  
  - change app-server v2 filesystem permission paths, including legacy
  read/write roots, to `ApiPathString`
  - localize API paths through `PathUri` when converting into the current
  native core permission types
  - make path-bearing permission conversions fallible and surface
  localization failures instead of silently treating malformed grants as
  ordinary denials
  - propagate conversion failures through app-server and TUI approval
  handling
  - regenerate the app-server JSON and TypeScript schemas
  - leave migration TODOs on native-path conversions so they can be
  removed once core permission paths use `PathUri`

  Adam Perry @ OpenAI · 2026-06-15 19:25:54 -07:00
  ecfe174d5f
• Add a toggle for realtime startup context (#28405)

  ## Summary
  - Add `includeStartupContext` to realtime start requests so callers can
  explicitly skip Codex startup context while keeping the backend prompt
  - Thread the new flag through protocol types, request processing, and
  realtime session config
  - Update app-server docs and coverage for the new default and opt-out
  behavior
  
  ## Testing
  - Added protocol serialization coverage for `includeStartupContext`
  - Added realtime integration coverage for starting a session with
  startup context disabled

  guinness-oai · 2026-06-15 17:14:22 -07:00
  d5b4b98370
• Add realtime speech append control (#27917)

  ## Why
  
  Realtime voice harness tuning needs app-side control over what backend
  Codex text is spoken. Backend orchestrator text is written for a reading
  UI, so automatically speaking every preamble, progress update, or final
  assistant message can make the realtime voice model too chatty.
  
  For experimentation, clients need two simple controls: keep app/client
  text-item injection on the existing item-create path, and add an
  explicit speakable path that app code can call only when it wants
  realtime to speak. Automatic Codex output also needs an opt-in way to
  switch from the protocol's default speakable path to regular realtime
  items, with a caller-provided prefix so prompt wording can be tuned
  outside core.
  
  The default remains unchanged: if a client omits the new start fields
  and never calls `appendSpeech`, automatic backend output continues down
  the existing speakable path for the selected realtime protocol.
  
  ## What Changed
  
  - Adds experimental `thread/realtime/appendSpeech` for app-provided
  speakable text.
  - Keeps existing `thread/realtime/appendText` as the item-create API for
  app-provided realtime text items.
  - Adds `codexResponsesAsItems` / `codex_responses_as_items` on
  `thread/realtime/start` to send automatic Codex responses with
  `conversation.item.create` instead of the protocol's default speakable
  output path.
  - Adds `codexResponseItemPrefix` / `codex_response_item_prefix` so
  clients can prepend experiment instructions to those automatic Codex
  response items.
  - Keeps literal `conversation.handoff.append` routing scoped to the v1
  speakable path; v2 default speech uses its item/function-output plus
  `response.create` behavior.
  - Removes the earlier public silent-context API and hardcoded
  silent-context prefix.
  - Updates realtime tests to cover default automatic speakable behavior,
  opt-in automatic item-create behavior, and explicit `appendSpeech`
  behavior.
  
  ## Validation
  
  - `cargo check -p codex-core -p codex-app-server -p codex-api`
  - `just test -p codex-app-server realtime_conversation`
  - `just test -p codex-core realtime_conversation` (50/51 passed in the
  filtered parallel run; the lone failure passed when rerun in isolation)
  - `just test -p codex-core
  conversation_mirrors_assistant_message_text_to_realtime_handoff`
  - `just test -p codex-api
  e2e_connect_and_exchange_events_against_mock_ws_server`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`
  - `cargo build -p codex-cli`

  guinness-oai · 2026-06-15 16:15:58 -07:00
  1d8ff89aa3
• feat(app-server): expose rate-limit reset credits (#28143)

  ## Why
  
  Codex users can earn personal rate-limit reset credits, but app-server
  clients do not currently have an API for reading or redeeming them. This
  adds the backend and protocol foundation used by the `/usage` TUI flow
  in #28154.
  
  ## What changed
  
  - Extend `account/rateLimits/read` with a nullable
  `rateLimitResetCredits` summary sourced from the existing usage
  response.
  - Add backend-client and app-server support for consuming a reset with a
  caller-generated idempotency key. A UUID is recommended, and clients
  reuse the same key when retrying the same logical reset.
  - Return only the consume `outcome`; clients refetch
  `account/rateLimits/read` for updated window state.
  - Document the response field and each consume outcome, and regenerate
  the JSON and TypeScript schema fixtures.
  - Clarify in `AGENTS.md` that new app-server string enum values use
  camelCase on the wire.
  - Update the existing TUI response fixture for the expanded protocol
  shape.
  - Add coverage for authentication, response mapping, backend failures,
  consume outcomes, and request timeout behavior.
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` — 231 passed.
  - `just test -p codex-backend-client` — 14 passed.
  - Focused `codex-app-server` reset-credit tests — 5 passed.
  - Focused `codex-tui` protocol response fixture test — passed.
  - `just fix -p codex-backend-client -p codex-app-server-protocol -p
  codex-app-server` — passed.
  - `just fmt` — passed.

  jay · 2026-06-15 21:54:01 +00:00
  bef99f861b
• feat(app-server): filter threads by parent (#26662)

  ## Why
  
  Clients that display or coordinate spawned subagents need an
  authoritative snapshot of a thread's immediate spawned children when
  they connect to app-server or recover after missing live events.
  `thread/list` cannot query by parent, so clients must otherwise scan
  unrelated threads or reconstruct relationships from rollout history and
  transient events.
  
  The direct spawn relationship already exists in persisted
  `thread_spawn_edges` state. Review and Guardian threads do not
  participate in that lifecycle and are intentionally outside this
  filter's scope.
  
  ## What changed
  
  This adds an experimental `parentThreadId` filter to `thread/list`.
  Parent-filtered requests return direct spawned children from persisted
  state while preserving the existing response shape, explicit filters,
  sorting, and timestamp-only cursor behavior. The lookup does not read
  rollout transcripts or recursively return descendants.
  
  Supersedes #25112 with the narrower `thread/list` filter approach.
  
  ## How it works
  
  1. An experimental client passes a valid thread ID as `parentThreadId`.
  2. App-server routes the list through the existing thread-store and
  state-database boundaries.
  3. SQLite selects threads whose IDs have a direct persisted spawn edge
  from that parent.
  4. Omitted provider and source filters include all values; explicit
  filters keep ordinary `thread/list` semantics.
  5. Grandchildren, Review threads, and Guardian threads are excluded.
  
  ## Verification
  
  State (144 tests), rollout (69 tests), and focused app-server
  thread-list (31 tests) suites passed. Scoped Clippy checks and
  repository formatting also passed. Coverage includes direct spawned
  children, omitted grandchildren, pagination, malformed IDs, mixed source
  kinds, explicit filters, and operation without rollout files.

  Brent Traut · 2026-06-14 00:14:26 -07:00
  dfd03ea01b
• [codex] Gate plugin MCP servers by auth route (#27459)

  ## Context
  
  Some plugins expose both Apps and MCP servers. This PR moves auth-aware
  surface projection into `core-plugins::PluginsManager`, so callers get a
  consistent effective plugin view. Later PRs narrow the conflict rule and
  update listing/install paths.
  
  The high level goal of this PR is to set up the plumbing to
  conditionally filter App/MCP in the plugin manager layer. We start by
  removing MCP servers when using SIWC/Codex-backend auth, and removing
  Apps when using API-key-style auth.
  
  This PR is now stacked on #27652, which contains only the constructor
  plumbing for seeding `PluginsManager` with the current auth mode.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - API-key/non-ChatGPT routes hide plugin Apps and keep plugin MCPs.
  - ChatGPT/SIWC with Apps enabled keeps plugin Apps and suppresses MCPs
  for dual-surface plugins.
  - MCP-only plugins stay available for ChatGPT/SIWC sessions.
  - Cached plugin load outcomes are re-projected when auth mode changes.
  
  ## Validation
  
  ```bash
  cargo test -p codex-core-plugins plugin_auth_projection
  cargo test -p codex-core list_tool_suggest_discoverable_plugins
  git diff --check
  ```

  felixxia-oai · 2026-06-12 19:42:11 -07:00
  5d7db08b61
• realtime: add AVAS architecture override (#27720)

  ## Summary
  
  Adds a `RealtimeConversationArchitecture` option for realtime
  conversation startup, with `realtimeapi` as the default and `avas` as an
  opt-in architecture.
  
  The AVAS path is limited to realtime v1 conversational WebRTC starts,
  and WebRTC call creation appends `intent=quicksilver&architecture=avas`
  to `/v1/realtime/calls`. The existing sideband websocket still joins by
  `call_id`.
  
  This also exposes the per-session architecture override through
  app-server v2 `thread/realtime/start` params and updates the config
  schema for `[realtime].architecture`.
  
  ## Validation
  
  - `just fmt`
  - `just write-config-schema`
  - `just test -p codex-api sends_avas_session_call_query_params`
  - `just test -p codex-core -E
  'test(~conversation_webrtc_start_uses_avas_architecture_query)'`
  - `just test -p codex-core -E 'test(realtime_loads_from_config_toml)'`
  - `just test -p codex-app-server-protocol -E
  'test(~serialize_thread_realtime_start) |
  test(generated_ts_optional_nullable_fields_only_in_params)'`
  - `just test -p codex-app-server -E
  'test(realtime_webrtc_start_emits_sdp_notification)'`

  Peter Bakkum · 2026-06-12 18:11:13 +00:00
  6652e82dd0
• feat(app-server): persist remote-control desired state (#27445)

  ## Why
  
  Remote-control runtime enablement and persisted enrollment preference
  were represented by separate flags. That made startup rehydration, RPC
  persistence, and new-enrollment seeding race with one another, and it
  did not cleanly distinguish runtime-only CLI or daemon starts from
  durable app-server RPC changes.
  
  ## What Changed
  
  - Replace the parallel enablement, seed, and rehydration flags with one
  transport-owned `RemoteControlDesiredState`.
  - Add nullable enrollment-scoped persistence and preserve existing
  preferences during enrollment upserts.
  - Rehydrate plain startup only after auth and client scope resolve,
  without overwriting a concurrent RPC transition.
  - Make ordinary `remoteControl/enable` and `remoteControl/disable`
  durable while retaining `ephemeral: true` for runtime-only callers.
  - Have the daemon explicitly request ephemeral enablement and regenerate
  the app-server schemas.
  
  ## Verification
  
  - Covered migration and `NULL`/`0`/`1` persistence round trips.
  - Covered plain-start rehydration and runtime-only versus durable
  enrollment seeding.
  - Covered durable enable, durable disable, and ephemeral enable through
  app-server RPC.
  - Covered the daemon's exact `{ "ephemeral": true }` request payload.
  
  Related issue: N/A (internal remote-control persistence architecture
  change).

  Anton Panasenko · 2026-06-11 21:28:52 -07:00
  d61dfeb23a
• feat: add Bedrock API key as a managed auth mode (#27443)

  ## Why
  
  Codex needs to manage Amazon Bedrock API key credentials through the
  existing auth lifecycle instead of introducing a separate auth manager
  or provider-specific credential file. Treating Bedrock API key login as
  a primary auth mode gives it the same persistence, keyring, reload, and
  logout behavior as the existing OpenAI API key and ChatGPT modes.
  
  The credential is valid only for the `amazon-bedrock` model provider.
  OpenAI-compatible providers must reject this auth mode rather than
  treating the Bedrock key as an OpenAI bearer token.
  
  ## What changed
  
  - Added `bedrockApiKey` as an app-server `AuthMode` and
  `CodexAuth::BedrockApiKey` as a primary `AuthManager` mode.
  - Added `BedrockApiKeyAuth`, containing the API key and AWS region, to
  the existing `AuthDotJson` payload stored in `$CODEX_HOME/auth.json` or
  the configured keyring backend.
  - Added `login_with_bedrock_api_key(...)`, parallel to
  `login_with_api_key(...)`, which replaces the current stored login with
  Bedrock credentials.
  - Reused generic auth reload and logout behavior instead of adding a
  Bedrock-specific auth manager or logout path.
  - Updated login restrictions, status reporting, diagnostics, telemetry
  classification, generated app-server schemas, and auth fixtures for the
  new mode.
  - Added explicit errors when Bedrock API key auth is selected with an
  OpenAI-compatible model provider.
  
  This PR establishes managed storage and auth-mode behavior. Routing the
  managed key and region into Amazon Bedrock requests will be in follow-up
  PRs.

  Celia Chen · 2026-06-10 20:42:38 -07:00
  06afd63f4a
• Add app-server thread/delete API (#25018)

  ## Why
  
  Clients can archive and unarchive threads today, but there is no
  app-server API for permanently removing a thread. Deletion also needs to
  cover the full session tree: deleting a main thread should remove
  spawned subagent threads and the related local metadata instead of
  leaving orphaned rollout files, goals, or subagent state behind.
  
  ## What
  
  - Adds the v2 `thread/delete` request and `thread/deleted` notification,
  with the response shape kept consistent with `thread/archive`.
  - Implements local hard delete for active and archived rollout files.
  - Deletes the requested thread's state DB row as the commit point, then
  best-effort cleans associated state including spawned descendants,
  goals, spawn edges, logs, dynamic tools, and agent job assignments.
  - Updates app-server API docs and generated protocol schema/TypeScript
  fixtures.

  Eric Traut · 2026-06-10 11:22:12 -07:00
  a19d43a40a
• Add app-server background terminal process APIs (#26041)

  ## Summary
  
  Codex Apps needs app-server as the source of truth for chat-started
  background terminals instead of guessing from local process trees.
  
  This PR adds experimental v2 APIs to list and terminate background
  terminals for a loaded thread using app-server process ids, so clients
  can manage background terminals without local PID discovery.
  
  ## Changes
  
  - `thread/backgroundTerminals/list` returns paginated background
  terminal records with `itemId`, app-server `processId`, `command`,
  `cwd`, nullable `osPid`, nullable `cpuPercent`, and nullable `rssKb`.
  - `thread/backgroundTerminals/terminate` terminates one running
  background terminal by app-server `processId` and returns whether a
  process was terminated.
  - Background terminal list and terminate operations use unified-exec
  process manager state as their source of truth.

  Eric Traut · 2026-06-10 11:18:09 -07:00
  a1a8807e9d
• Add per-session realtime model and version overrides (#24999)

  ## Why
  
  Clients need to select a realtime session configuration for an
  individual start without rewriting persisted configuration or restarting
  the app-server process.
  
  ## What Changed
  
  - Add optional `model` and `version` fields to `thread/realtime/start`
  - Forward those optional values through the realtime start operation and
  apply them only for that session
  - Preserve existing configured/default behavior when the new fields are
  omitted
  - Update generated protocol schema and app-server documentation
  
  ## Validation
  
  - Added/updated protocol serialization coverage for the new optional
  request fields
  - Added focused core coverage for a session override taking precedence
  over configured realtime selection
  - Added focused app-server coverage that a request override reaches the
  realtime WebSocket handshake

  guinness-oai · 2026-06-09 17:54:32 -07:00
  4a3eac2144
• [codex-rs] support v2 personal access tokens (#25731)

  ## Summary
  
  - add v2 personal access token support for `codex login
  --with-access-token` and `CODEX_ACCESS_TOKEN`
  - classify opaque `at-` tokens separately from legacy Agent Identity
  JWTs
  - hydrate required ChatGPT account metadata through AuthAPI
  `/v1/user-auth-credential/whoami`
  - use PATs directly as bearer tokens while preserving existing ChatGPT
  account surfaces
  - expose PAT-backed auth as the explicit `personalAccessToken`
  app-server auth mode
  
  ## Implementation
  
  PAT auth is intentionally small and stateless. Loading a PAT performs
  one AuthAPI metadata request, stores the hydrated metadata in the
  in-memory auth object, and redacts the secret from debug output. Legacy
  Agent Identity JWT handling remains unchanged. The shared access-token
  classifier lives in a private neutral module because it dispatches
  between both credential types.
  
  PAT hydration fails closed when AuthAPI omits any required metadata,
  including email. Hydrated metadata is intentionally not persisted:
  startup performs a live `whoami` preflight so revoked tokens or changed
  account metadata are not accepted from a stale cache.
  
  ## Workspace restriction scope
  
  This change intentionally does **not** apply
  `forced_chatgpt_workspace_id` to PAT authentication. The setting is a
  client-side config guardrail, not an authorization boundary, and PAT
  does not currently require workspace-ID parity. The PAT login and
  `CODEX_ACCESS_TOKEN` paths therefore validate through AuthAPI without
  threading workspace-restriction state through access-token loading.
  Existing workspace checks for non-PAT auth remain on their established
  paths.
  
  ## App-server compatibility
  
  The public app-server `AuthMode` is shared across v1 and v2, and
  PAT-backed auth reports `personalAccessToken` through both APIs.
  Following human review, this intentionally removes the temporary v1
  compatibility mapping that reported PATs as `chatgpt`; the deprecated v1
  API is kept in parity with v2 rather than maintaining a separate closed
  enum. Clients with exhaustive auth-mode handling in either API version
  must add the new case and should generally treat it as ChatGPT-backed
  unless they need PAT-specific behavior.
  
  The v1 auth-status response still omits the raw PAT when `includeToken`
  is requested because that response cannot carry the account metadata
  needed to reuse the credential safely. Persisted PAT auth also omits the
  new enum value so older Codex builds can deserialize `auth.json` and
  infer PAT auth from the credential field after a rollback.
  
  ## Validation
  
  Latest review-fix validation:
  
  - `CARGO_INCREMENTAL=0 just test -p codex-login` (126 passed)
  - `CARGO_INCREMENTAL=0 just test -p codex-cli` (263 passed)
  - `CARGO_INCREMENTAL=0 just test -p codex-cli
  stored_auth_validation_handles_personal_access_token`
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server-protocol` (226
  passed)
  - `CARGO_INCREMENTAL=0 just test -p codex-models-manager
  refresh_available_models_uses_remote_only_catalog_for_chatgpt_auth`
  - `CARGO_INCREMENTAL=0 just test -p codex-tui
  existing_non_oauth_chatgpt_login_counts_as_signed_in`
  - `CARGO_INCREMENTAL=0 just fix -p codex-login -p
  codex-app-server-protocol -p codex-models-manager -p codex-tui -p
  codex-cli`
  - `just fmt`
  - `git diff --check`
  
  The broader `codex-tui` suite previously compiled and ran 2,834 tests.
  Three unrelated environment-sensitive guardian/IDE-socket tests failed
  after retries; the PAT-relevant TUI coverage passed.

  cooper-oai · 2026-06-05 17:36:18 -07:00
  df7818c7d1
• feat(app-server): add remote control pairing status RPC (#26450)

  ## What
  
  Exposes the pairing status transport as experimental app-server v2 RPC
  `remoteControl/pairing/status`.
  
  - Adds request/response protocol types for exactly one lookup key:
  `pairingCode` or `manualPairingCode`, returning `{ claimed }`.
  - Registers the RPC with `global_shared_read("remote-control-pairing")`.
  - Wires the method through `MessageProcessor` and
  `RemoteControlRequestProcessor`.
  - Validates missing/conflicting pairing-code params as invalid requests.
  - Documents the RPC in `app-server/README.md`.
  - Adds processor, protocol export, and JSON-RPC integration coverage for
  both code paths.
  
  ## Why
  
  This is the app-server surface the desktop app can poll while the
  QR/manual pairing modal is active.
  
  Depends on https://github.com/openai/codex/pull/26449
  Related backend change: https://github.com/openai/openai/pull/990244
  
  ## Verification
  
  - `cargo test --manifest-path app-server-protocol/Cargo.toml
  remote_control`
  - `cargo test --manifest-path app-server/Cargo.toml remote_control`
  - `cargo fmt --all --check`
  - `git diff --check`

  hefuc-oai · 2026-06-05 10:33:56 -07:00
  0177231ca0
• feat(app-server): expose account token usage [1 of 2] (#25344)

  ## Why
  
  Token activity is useful account-level context, but terminal clients
  need a supported app-server path to fetch it without reaching into
  ChatGPT backend details directly. The API should also live under the
  broader account usage umbrella so future usage surfaces can be added
  without proliferating user-facing concepts.
  
  ## What Changed
  
  - Add `codex-backend-client` support for the ChatGPT profile token-usage
  payload.
  - Add the v2 `account/usage/read` app-server RPC.
  - Map lifetime usage, peak daily usage, streak, longest task duration,
  and daily buckets into app-server protocol types.
  - Gate the request on Codex-backend auth, which supports ChatGPT auth
  tokens and AgentIdentity.
  - Regenerate the app-server JSON and TypeScript schema fixtures.
  
  ## Token Count Source
  
  `account/usage/read` returns the token-usage aggregate supplied by the
  ChatGPT profile backend. App-server maps that backend-owned aggregate
  into protocol fields; it does not recompute cached-token treatment,
  usage multipliers, or raw input/output totals locally.
  
  ## Stack
  
  1. feat(app-server): expose account token usage [1 of 2] (this PR)
  2. [#25345](https://github.com/openai/codex/pull/25345) feat(tui): add
  token activity command [2 of 2]
  
  ## How to Test
  
  1. Start an app-server client from this branch while authenticated with
  ChatGPT or AgentIdentity.
  2. Call `account/usage/read`.
  3. Confirm the response includes `summary` and `dailyUsageBuckets`.
  4. Also verify a session without Codex-backend auth receives the
  existing auth error path.
  
  Targeted tests:
  - `just test -p codex-backend-client -p codex-app-server-protocol -p
  codex-app-server`
  - `just write-app-server-schema`

  Felipe Coury · 2026-06-05 14:43:44 +00:00
  5e62c735b2
• [codex] Forward turn moderation metadata through app-server (#25710)

  ## Why
  First-party backends can supply turn-scoped moderation metadata that
  app-server clients need for client-side presentation. Exposing this as
  an experimental typed notification lets opted-in clients consume it
  without interpreting raw Responses API events.
  
  ## What changed
  - forward `response.metadata.openai_chatgpt_moderation_metadata` from
  Responses API SSE and WebSocket streams as turn-scoped moderation
  metadata
  - emit the experimental app-server v2 `turn/moderationMetadata`
  notification with `{ threadId, turnId, metadata }`
  - add app-server integration coverage for the typed moderation metadata
  notification
  
  ## Testing
  - `just test -p codex-core
  build_ws_client_metadata_includes_window_lineage_and_turn_metadata`
  - `just test -p codex-core` (fails locally: 46 failures and 1 timeout,
  primarily missing `test_stdio_server` and shell snapshot timeouts)
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  turn_moderation_metadata_emits_typed_notification_v2`
  - `just test -p codex-app-server` (fails locally: 792 passed, 10 failed,
  and 5 timed out; failures are in existing environment-sensitive tests,
  primarily because nested macOS `sandbox-exec` is not permitted)
  - `just write-app-server-schema --experimental --schema-root
  /tmp/codex-app-server-schema-experimental`

  carlc-oai · 2026-06-05 02:41:06 -07:00
  55aa071b17
• feat(app-server): add remote control client management RPCs (#25785)

  ## Why
  
  Remote-control clients need to list and revoke controller-device grants
  without enabling or enrolling the local relay. These are signed-in
  account-management operations, so coupling them to websocket, pairing,
  enrollment, or persisted relay state would prevent clients from managing
  stale grants from the picker.
  
  Related enhancement request: N/A. This adds the Codex app-server surface
  for the planned upstream environment-scoped revoke endpoint.
  
  ## What Changed
  
  - Added experimental app-server v2 RPCs:
    - `remoteControl/client/list`
    - `remoteControl/client/revoke`
  - Added picker-oriented protocol types and standard generated schema
  fixtures. The list response intentionally omits backend account id,
  enrollment status, and location fields.
  - Added `app-server-transport/src/transport/remote_control/clients.rs`
  for environment-scoped GET and DELETE requests. It builds escaped URL
  path segments, forwards optional pagination query fields, sends ChatGPT
  auth plus `chatgpt-account-id`, converts RFC3339 `last_seen_at` values
  to Unix seconds, accepts `204 No Content` revoke responses, and retries
  once after a `401`.
  - Extracted shared ChatGPT auth loading and recovery into
  `app-server-transport/src/transport/remote_control/auth.rs` so
  websocket, pairing, and client management use the same account-auth
  boundary.
  - Retained the configured remote-control base URL on
  `RemoteControlHandle` and resolve management URLs lazily, preserving
  deferred validation while relay startup is disabled.
  - Registered list as `global_shared_read("remote-control-clients")` and
  revoke as `global("remote-control-clients")`.
  
  ## Verification
  
  - Added transport coverage proving list and revoke work while relay
  state is disabled, IDs are escaped, picker-only fields are returned,
  timestamps are converted, revoke accepts `204`, auth headers are
  forwarded, `401` retries exactly once, `403` is not retried, and
  malformed list payloads retain decode context.
  - Added an app-server integration test proving both JSON-RPC methods
  work before relay enablement and successful revoke returns `{}`.
  - Regenerated and validated experimental and standard app-server schema
  fixtures.

  Anton Panasenko · 2026-06-02 17:01:02 -07:00
  98a62a62ce
• feat(remote-control): add pairing start (#25675)

  ## Why
  
  Remote control enrollment authorizes a desktop server, but app-server v2
  did not expose the follow-up pairing operation needed to mint a
  short-lived controller pairing artifact from that enrolled server.
  Clients need a narrow RPC that starts pairing without exposing the
  backend `serverId` or conflating pairing with websocket connection
  state.
  
  Issue: N/A; internal remote-control pairing API change.
  
  ## What Changed
  
  Added experimental app-server v2 `remoteControl/pairing/start` with
  `manualCode` input and `pairingCode`, nullable `manualPairingCode`,
  `environmentId`, and Unix-seconds `expiresAt` output. The method
  serializes under its own `global("remote-control-pairing")` scope and is
  documented in `app-server/README.md`.
  
  Extended the remote-control transport with private `/server/pair`
  request/response types and normalized `pair_url` handling. Pairing uses
  the current enrolled server bearer, refreshes that bearer when needed,
  keeps backend `server_id` private, validates returned `server_id` and
  `environment_id` against the current enrollment, and preserves backend
  status/header/body context for failures and malformed responses.
  
  Wired the request through `RemoteControlRequestProcessor` and
  `MessageProcessor`, mapping unavailable/disabled pairing to
  `invalid_request` and backend failures to internal errors.
  
  ## Verification
  
  - `just test -p codex-app-server-transport`
  - `just test -p codex-app-server
  remote_control_pairing_start_returns_pairing_artifacts`

  Anton Panasenko · 2026-06-02 01:05:50 +00:00
  0002316687
• store and expose parent_thread_id on Threads (#25113)

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

  Owen Lin · 2026-06-01 04:33:20 +00:00
  cf0911076f
• Add runtime extra skill roots API (#24977)

  ## Summary
  - Add v2 `skills/extraRoots/set` to replace app-server process-local
  standalone skill roots. The setting is not persisted, accepts missing
  roots, and `extraRoots: []` clears the runtime set.
  - Wire runtime roots into core skill discovery for `skills/list` and
  turn loads, clear skill caches on set, and register the roots with the
  skills watcher so later filesystem changes emit `skills/changed`.
  - Update app-server docs, generated JSON/TypeScript schemas, and
  coverage for serialization, missing roots, empty clears, and restart
  behavior.
  
  ## Testing
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-skills`
  - `cargo test -p codex-app-server
  skills_extra_roots_set_updates_process_runtime_roots`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core-skills`
  - `just fix -p codex-app-server`

  xl-openai · 2026-05-28 21:14:34 -07:00
  f0a839ea0c
• fix(app-server): fix optional bool annotations (#24099)

  `#[serde(default)]` wasn't sufficient for our generated TS types to
  reflect that clients didn't have to set them. We also need
  `skip_serializing_if = "std::ops::Not::not"`. This is already a rule in
  our agents.md file.

  Owen Lin · 2026-05-22 16:52:53 +00:00
  cff960896c
• [codex] Add rollout-backed thread content search (#23519)

  ## Summary
  - add experimental `thread/search` for local rollout-backed thread
  search using `rg` over JSONL rollouts
  - return search-specific result rows with optional previews instead of
  storing preview data on `StoredThread` or ordinary `Thread` responses
  - keep `thread/list` separate from full-content search and document the
  new app-server surface
  
  ## Testing
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server
  thread_search_returns_content_and_title_matches -- --nocapture`

  Francis Chalissery · 2026-05-21 11:52:24 -07:00
  ac0bff27e7
• Make goals feature on by default and no longer experimental (#23732)

  ## Why
  
  The `goals` feature is ready to be available without requiring users to
  opt into experimental features. Keeping it behind the beta flag leaves
  persisted thread goals and automatic goal continuation disabled by
  default.
  
  This PR also marks the goal-related app server APIs and events as no
  longer experimental.
  
  ## What changed
  
  - Mark `goals` as `Stage::Stable`.
  - Enable `goals` by default in `codex-rs/features/src/lib.rs`.

  Eric Traut · 2026-05-20 15:07:35 -07:00
  0e9d222178
• Add thread/settings/update app-server API (#23502)

  ## Why
  
  App-server clients need a way to update a thread's next-turn settings
  without starting a turn, adding transcript content, or waiting for turn
  lifecycle events. This gives settings UI a direct path for durable
  thread settings while clients observe the eventual effective state
  through a notification.
  
  This is a simplified rework of PR
  https://github.com/openai/codex/pull/22509. In particular, it changes
  the `thread/settings/update` api to return immediately rather than
  waiting and returning the effective (updated) thread settings. This
  makes the new api consistent with `turn/start` and greatly reduces the
  complexity of the implementation relative to the earlier attempt.
  
  ## What Changed
  
  - Adds experimental `thread/settings/update` with partial-update request
  fields and an empty acknowledgment response.
  - Adds experimental `thread/settings/updated`, carrying full effective
  `ThreadSettings` and scoped by `threadId` to subscribed clients for the
  affected thread.
  - Shares durable settings validation with `turn/start`, including
  `sandboxPolicy` plus `permissions` rejection and `serviceTier: null`
  clearing.
  - Emits the same settings notification when `turn/start` overrides
  change the stored effective thread settings.
  - Regenerates app-server protocol schema fixtures and updates
  `app-server/README.md`.

  Eric Traut · 2026-05-20 11:03:20 -07:00
  771a4e74ac
• feat: add permission profile list api (#23412)

  ## Why
  
  Clients need a typed permission-profile catalog instead of
  reconstructing that state from config internals.
  
  ## What changed
  
  - Added `permissionProfile/list` to the app-server v2 protocol with
  cursor pagination and optional `cwd`.
  - The list response includes built-in permission profiles plus
  config-defined `[permissions.<id>]` profiles from the effective config
  for the request context.
  - Permission profiles keep optional `description` metadata for display
  purposes.
  - App-server docs and schema fixtures are updated for the new RPC.

  viyatb-oai · 2026-05-20 02:42:56 +00:00
  c3faea0b09
• app-server: use profile ids in v2 permission params (#23360)

  ## Why
  
  The v2 app-server permission profile fields are experimental, but the
  previous migration kept a legacy object payload for profile selection.
  That made clients aware of server-owned `activePermissionProfile`
  metadata such as `extends`, and it kept a
  `legacy_additional_writable_roots` path even though
  `runtimeWorkspaceRoots` now owns runtime workspace-root selection.
  
  This PR makes the client contract match the intended model: clients
  select a permission profile by id, and the server resolves and reports
  active profile provenance in response payloads.
  
  Follow-up to #22611.
  
  ## What Changed
  
  - Changed `thread/start`, `thread/resume`, `thread/fork`, and
  `turn/start` permission profile selection to plain profile id strings.
  - Changed `command/exec.permissionProfile` to a plain profile id string
  for the same client/server ownership split.
  - Removed `PermissionProfileSelectionParams` and the legacy `{ type:
  "profile", modifications: [...] }` compatibility deserializer.
  - Updated app-server, TUI, and `codex exec` call sites to send only ids,
  while keeping `activePermissionProfile` as server response metadata.
  - Updated app-server docs and schema fixtures for the revised
  `command/exec.permissionProfile` shape.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-app-server`
  - `cargo test -p codex-exec`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-tui`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23360).
  * #23368
  * __->__ #23360

  Michael Bolin · 2026-05-18 17:28:50 -07:00
  3fd79b7986
• feat(app-server): add optional thread_id to experimentalFeature/list (#23335)

  ## Why
  
  `experimentalFeature/list` reports effective feature enablement, but
  currently does not resolve it against a working directory where
  project-local config.toml files can exist and toggle on/off features
  when merged into the effective config after resolving the various config
  layers. That means we effectively (and incorrectly) ignore features set
  in project-local config.
  
  To address that, this PR exposes an optional `thread_id` param which
  allows us to load the thread's `cwd.
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server experimental_feature_list`

  Owen Lin · 2026-05-18 12:12:14 -07:00
  139365a4bb
• [codex] Add installed-plugin mention API (#22448)

  ## Summary
  - add app-server `plugin/installed` for mention-oriented plugin loading
  - return installed plugins plus explicitly requested install-suggestion
  rows
  - keep remote handling on installed-state data instead of the broad
  catalog listing path
  
  ## Why
  The `@` mention surface only needs plugins that are usable now, plus a
  small product-approved set of install suggestions. It does not need the
  full catalog-shaped `plugin/list` payload that the Plugins page uses.
  
  ## Validation
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-app-server --test all plugin_installed_`
  
  ## Notes
  - The package-wide `cargo test -p codex-app-server` run still hits an
  existing unrelated stack overflow in
  `in_process::tests::in_process_start_clamps_zero_channel_capacity`.
  - Companion webview PR: https://github.com/openai/openai/pull/915672

  xli-oai · 2026-05-18 03:11:54 -07:00
  da14dd2add
• app-server-protocol: remove PermissionProfile from API (#22924)

  ## Why
  
  The app server API should expose permission profile identity, not the
  lower-level runtime permission model. `PermissionProfile` is the
  compiled sandbox/network representation that the server uses internally;
  exposing it through app-server-protocol forces clients to understand
  details that should remain implementation-level.
  
  The API boundary should prefer `ActivePermissionProfile`: a stable
  profile id, plus future parent-profile metadata, that clients can pass
  back when they want to select the same active permissions. This also
  avoids schema generation collisions between the app-server v2 API type
  space and the core protocol model.
  
  Incidentally, while PR makes a number of changes to `command/exec`, note
  that we are hoping to deprecate this API in favor of `process/spawn`, so
  we don't need to be too finicky about these changes.
  
  ## What Changed
  
  - Removed `PermissionProfile` from the app-server-protocol API surface,
  including generated schema and TypeScript exports.
  - Changed `CommandExecParams.permissionProfile` to
  `ActivePermissionProfile`.
  - Resolve command exec profile ids through `ConfigManager` for the
  command cwd, matching turn override selection semantics.
  - Updated downstream TUI tests/helpers to use core permission types
  directly instead of app-server-protocol `PermissionProfile` shims.

  Michael Bolin · 2026-05-15 17:10:15 -07:00
  9025550709
• feat(app-server): update remote control APIs for better UX (#22877)

  ## Why
  To help improve `codex remote-control` CLI UX which I plan to do in a
  followup, this PR adds `server-name` to the various remote control APIs:
  - `remoteControl/enable`
  - `remoteControl/disable`
  - `remoteControl/status/changed`
  
  Also, add a `remoteControl/status/read` API. This will be helpful in the
  Codex App.

  Owen Lin · 2026-05-15 14:33:24 -07:00
  6a331a66eb
• app-server: stop returning thread permission profiles (#22792)

  ## Why
  
  The app-server thread lifecycle API should no longer expose the full
  `PermissionProfile` value. After the permissions-profile migration,
  clients should round-trip only the active profile identity through
  `activePermissionProfile` and `permissions` when that identity is known.
  
  The full profile is server-side config. Treating a response-derived
  legacy sandbox projection as a new local profile can lose named-profile
  restrictions and accidentally widen permissions on the next turn. The
  legacy `sandbox` response field remains only as the
  compatibility/display fallback.
  
  ## What Changed
  
  - Removed `permissionProfile` from `ThreadStartResponse`,
  `ThreadResumeResponse`, and `ThreadForkResponse`.
  - Stopped populating that field in app-server thread start/resume/fork
  responses.
  - Updated embedded exec/TUI response mapping to derive display
  permission state from local config or the legacy sandbox fallback
  instead of a response profile value.
  - Added a TUI turn override shape that distinguishes preserving server
  permissions, selecting an active profile id, and sending a legacy
  sandbox for an explicit local override.
  - Preserved remote app-server permissions across turns by sending
  `permissions` only when an `activePermissionProfile` id is known, and
  otherwise sending no sandbox override unless the user selected a local
  override.
  - Kept embedded `thread/resume` hydration server-authored when
  `activePermissionProfile` is absent, which matches the live-thread
  attach path where the server ignores requested overrides.
  - Updated the app-server README to remove the obsolete lifecycle
  response `permissionProfile` reference. The remaining
  `permissionProfile` README references are request-side permission
  overrides.
  - Regenerated app-server JSON schema and TypeScript fixtures.
  - Kept the generated typed response enum exempt from
  `large_enum_variant`, matching the existing payload enum exemption after
  the lifecycle response variants shrank.
  
  ## How To Review
  
  Start with `codex-rs/app-server-protocol/src/protocol/v2/thread.rs` to
  confirm the response shape, then check the response construction in
  `codex-rs/app-server/src/request_processors`. The generated schema and
  TypeScript fixture changes are mechanical follow-through from the
  protocol removal.
  
  The TUI behavior is the delicate part: review
  `codex-rs/tui/src/app_server_session.rs` for response hydration and
  turn-start override projection, then
  `codex-rs/tui/src/app/thread_routing.rs` for the decision about whether
  the next turn should preserve the server snapshot, send an active
  profile id, or send a legacy sandbox for an explicit local override.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol
  thread_lifecycle_responses_default_missing_optional_fields`
  - `cargo test -p codex-exec
  session_configured_from_thread_response_uses_permission_profile_from_config`
  - `cargo test -p codex-tui --lib thread_response`
  - `cargo test -p codex-tui turn_permissions_`
  - `cargo test -p codex-tui
  resume_response_restores_turns_from_thread_items`
  - `cargo test -p codex-analytics
  track_response_only_enqueues_analytics_relevant_responses`
  - `just fix -p codex-analytics`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-tui`
  - `just argument-comment-lint`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22792).
  * #22795
  * __->__ #22792

  Michael Bolin · 2026-05-15 12:45:48 -07:00
  83bbb4f326
• app-server: use permission ids and runtime workspace roots (#22611)

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

  Michael Bolin · 2026-05-14 23:00:05 -07:00
  8a5306ff88
• Unqueue plugin list and read requests (#22703)

  ## Summary
  - remove the app-server `plugin-read` serialization queue from
  `plugin/list` and `plugin/read`
  - allow plugin read/list requests to start immediately instead of
  waiting behind other plugin read/list requests
  
  ## Test plan
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`

  xli-oai · 2026-05-14 15:07:20 -07:00
  8c7a176b55
• enable/disable remote control at runtime, not via features (#22578)

  ## Why
  reapplies https://github.com/openai/codex/pull/22386 which was
  previously reverted
  
  Also, introduce `remoteControl/enable` and `remoteControl/disable`
  app-server APIs to toggle on/off remote control at runtime for a given
  running app-server instance.
  
  ## What Changed
  
  - Adds experimental v2 RPCs:
    - `remoteControl/enable`
    - `remoteControl/disable`
  - Adds `RemoteControlRequestProcessor` and routes the new RPCs through
  it instead of `ConfigRequestProcessor`.
  - Adds named `RemoteControlHandle::enable`, `disable`, and `status`
  methods.
  - Makes `remoteControl/enable` return an error when sqlite state DB is
  unavailable, while keeping enrollment/websocket failures as async status
  updates.
  - Adds `AppServerRuntimeOptions.remote_control_enabled` and hidden
  `--remote-control` flags for `codex app-server` and `codex-app-server`.
  - Updates managed daemon startup to use `codex app-server
  --remote-control --listen unix://`.
  - Marks `Feature::RemoteControl` as removed and ignores
  `[features].remote_control`.
  - Updates app-server README entries for the new remote-control methods.

  Owen Lin · 2026-05-14 01:07:46 +00:00
  4e368aa2e9
• [codex] isolate plugin/list from config serialization queue (#22437)

  ## Summary
  - move `plugin/list` from the shared `config` read queue onto a
  dedicated `plugin-list` shared-read queue
  - move `plugin/read` onto that same dedicated shared-read queue as well
  - keep the existing scheduler behavior unchanged
  - allow plugin list/read operations to proceed independently of
  config-family writes, accepting temporary stale or transient read errors
  during concurrent mutations
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`

  xli-oai · 2026-05-13 11:05:57 +00:00
  7fbd342fb3
• feat: Add plugin share checkout (#22435)

  Adds plugin/share/checkout to turn a shared remote plugin into a local
  working copy under ~/plugins/<name>.
  
  Registers the copy in the managed personal marketplace and records the
  remote-to-local mapping for later share/save flows.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-05-13 00:50:29 -07:00
  2a67c46de4
• [codex] support executor registry remote environments (#21323)

  ## Summary
  
  Support registry-backed remote executors end to end so downstream
  services can resolve an executor id into an exec-server URL and make
  that environment available to Codex without relying on the legacy cloud
  environments flow.
  
  ## What changed
  
  - switch remote executor registration to the executor registry bootstrap
  contract
  - allow named remote environments to be inserted into
  `EnvironmentManager` at runtime
  - add the experimental app-server RPC `environment/add` so initialized
  experimental clients can register those remote environments for later
  `thread/start` and `turn/start` selection
  
  ## Validation
  
  Ran focused validation locally:
  - `cargo test -p codex-exec-server environment_manager_`
  - `cargo test -p codex-exec-server
  register_executor_posts_with_bearer_token_header`
  - `cargo test -p codex-app-server-protocol`

  Michael Zeng · 2026-05-08 16:30:07 -07:00
  8f4020846e
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343