287 Commits

• Allow runtime enablement for remote plugins (#24707)

  experimentalFeature/enablement/set now accepts remote_plugin as a
  supported runtime feature key

  xl-openai · 2026-05-26 22:22:34 -07:00
  1de8c43467
• Use thread config for TUI MCP inventory (#24532)

  ## Summary
  `/mcp` in the TUI should reflect the current loaded thread, including
  project-local MCP servers from that thread config. Before this change,
  `mcpServerStatus/list` only read the latest global MCP config, so the
  active chat could miss project-local servers.
  
  This adds optional `threadId` to `mcpServerStatus/list`. When present,
  app-server resolves the loaded thread and lists MCP status from the
  refreshed effective config for that thread; when omitted, existing
  global config behavior stays unchanged.
  
  The TUI now sends the active chat thread id for `/mcp` and `/mcp
  verbose`, carries that origin through the async inventory result, and
  ignores stale completions if the user has switched threads before the
  fetch returns. The app-server schemas were regenerated.
  
  ## Follow-up
  Once this app-server API change lands, the desktop app should make the
  same `threadId` plumbing so its MCP inventory also uses the current
  thread config.
  
  Fixes #23874

  Eric Traut · 2026-05-26 07:44:04 -07:00
  0f91e869bd
• app-server: drop legacy profile config surface (#24067)

  ## Why
  
  Legacy `[profiles.<name>]` config tables and the legacy `profile`
  selector are being retired in favor of profile files selected with
  `--profile <name>`. After #23886 removed the CLI-side legacy profile
  plumbing, the app-server config surface still exposed those fields and
  still carried conversion code for the old protocol shape.
  
  ## What changed
  
  - Remove `profile`, `profiles`, and `ProfileV2` from the app-server
  config protocol/schema output so `config/read` no longer returns legacy
  profile config.
  - Drop the old v1 `UserSavedConfig` profile conversion path from
  `config`.
  - Reject new app-server config writes under `profiles.*` with the same
  migration direction used for `profile`, while still allowing callers to
  clear existing legacy profile tables.
  - Refresh app-server config coverage and the experimental API README
  example around the remaining `Config` nesting path.
  
  ## Verification
  
  - Added config-manager coverage that `config/read` omits legacy profile
  config, `profiles.*` writes are rejected, and existing legacy profile
  tables can still be cleared.
  - Updated the v2 config RPC test to cover the rejected `profiles.*`
  batch-write path.

  jif-oai · 2026-05-22 19:41:39 +02:00
  162a6e746b
• Prefer just test over cargo test in docs (#23910)

  `cargo test` for the core and other crates fails on a fresh macOS
  checkout without the right stack size variable. This change encourages
  using the just test command that sets the environment up correctly.
  
  As a bonus, this should encourage agents to get more benefit out of
  nextest's parallel execution.

  anp-oai · 2026-05-22 16:58:14 +00:00
  d53e68954a
• feat: support managed permission profiles in requirements.toml (#23433)

  ## Why
  
  Cloud-managed `requirements.toml` should be able to define the managed
  permission profiles a client may select and constrain that selectable
  set without requiring local user config to recreate the profile catalog.
  
  This keeps requirements focused on restrictions. The selected default
  remains a config or session choice, while requirements contribute the
  managed profile bodies and `allowed_permissions` allowlist that the
  config-loading boundary validates before a resolved runtime
  `PermissionProfile` is installed.
  
  ## What changed
  
  - Add `requirements.toml` support for a managed permission-profile
  catalog plus its allowlist:
  
  ```toml
  allowed_permissions = ["review", "build"]
  
  [permissions.review]
  extends = ":read-only"
  
  [permissions.build]
  extends = ":workspace"
  ```
  
  - Merge requirements-defined profile bodies into the effective
  permission catalog and reject profile ids that collide with
  config-defined profiles.
  - Validate that every `allowed_permissions` entry resolves to a built-in
  or catalog profile before selection uses it.
  - Preserve allowed configured named-profile selections. When a
  configured named profile is disallowed, fall back to the first allowed
  requirements profile with a startup warning.
  - Keep built-in selections and the stock trust-based `:read-only` /
  `:workspace` fallback path intact when no permission profile is
  explicitly selected.
  - Centralize the managed catalog and allowlist selection path in
  `EffectivePermissionSelection` so the requirements boundary is visible
  in config loading.
  - Surface `allowedPermissions` through `configRequirements/read`, and
  update the generated app-server schema fixtures plus the app-server
  README.
  
  ## Validation
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core system_requirements_`
  - `cargo test -p codex-core system_allowed_permissions_`
  - `cargo test -p codex-app-server-protocol`
  - `just write-app-server-schema`
  
  ## Related work
  
  - Uses merged permission-profile inheritance support from #22270 and
  #23705.
  - Kept separate from the in-flight permission profile listing API in
  #23412.

  viyatb-oai · 2026-05-20 17:33:01 -07:00
  713a5b1b00
• [codex] Add plugin id to MCP tool call items (#23737)

  Add owning plugin id to MCP tool call items so we can better filter them
  at plugin level.
  
  ## Summary
  - add optional `plugin_id` to MCP tool-call items and legacy begin/end
  events
  - propagate plugin metadata into emitted core items and app-server v2
  `ThreadItem::McpToolCall`
  - preserve plugin ids through app-server replay/redaction paths and
  regenerate v2 schema fixtures
  
  ## Testing
  - `just write-app-server-schema`
  - `just fmt`
  - `just fix -p codex-core`
  - `cargo test -p codex-protocol -p codex-app-server-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core mcp_tool_call_item_includes_plugin_id --lib`
  - `cargo check -p codex-tui --tests`
  - `cargo check -p codex-app-server --tests`
  - `git diff --check`
  
  ## Notes
  - `just fix -p codex-core` completed with two non-fatal
  `too_many_arguments` warnings on the touched MCP notification helpers.
  - A broader `cargo test -p codex-core` run passed core unit tests, then
  hit shell/sandbox/snapshot failures in the integration target.
  - A broader app-server downstream run hit the existing
  `in_process::tests::in_process_start_clamps_zero_channel_capacity` stack
  overflow; `cargo test -p codex-exec` also hit the existing sandbox
  expectation mismatch in
  `thread_lifecycle_params_include_legacy_sandbox_when_no_active_profile`.

  Matthew Zeng · 2026-05-20 17:02:10 -07:00
  0a4179bb19
• Honor client-resolved service tier defaults (#23537)

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

  Shijie Rao · 2026-05-20 15:57:50 -07:00
  370b13afc9
• 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
• Add CUA requirements subsection for locked computer use (#23555)

  Adds a new top-level section for "CUA" requirements that can allow for
  disablement of specific features as needed for enterprises.

  adams-oai · 2026-05-19 15:41:44 -07:00
  d86352d520
• [1 of 7] Add thread settings to UserInput (#23080)

  **Stack position:** [1 of 7]
  
  ## Summary
  
  The first three PRs in this stack are a cleanup pass before the actual
  thread settings API work.
  
  Today, core has several overlapping "user input" ops: `UserInput`,
  `UserInputWithTurnContext`, and `UserTurn`. They differ mostly in how
  much next-turn state they carry, which makes the later queued thread
  settings update harder to reason about and review.
  
  This PR starts that cleanup by adding the shared
  `ThreadSettingsOverrides` payload and allowing `Op::UserInput` to carry
  it. Existing variants remain in place here, so this layer is mostly a
  behavior-preserving API shape change plus mechanical constructor
  updates.
  
  ## End State After PR3
  
  By the end of PR3, `Op::UserInput` is the only "user input" core op. It
  can carry optional thread settings overrides for callers that need to
  update stored defaults with a turn, while callers without updates use
  empty settings. `Op::UserInputWithTurnContext` and `Op::UserTurn` are
  deleted.
  
  ## End State After PR5
  
  By the end of PR5, core will have only two ops for this area:
  
  - `Op::UserInput` for user-input-bearing submissions.
  - `Op::ThreadSettings` for settings-only updates.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080) (this PR)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 18:48:35 -07:00
  84d941d07f
• Remove ToolSearch feature toggle (#23389)

  ## Summary
  - mark `ToolSearch` as removed and ignore stale config writes for its
  legacy key
  - make search tool exposure depend only on model capability, not a
  feature toggle
  - remove app-server enablement support and prune now-obsolete test
  coverage/setup
  
  ## Verification
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core search_tool_requires_model_capability`
  - `cargo test -p codex-app-server experimental_feature_enablement_set_`
  
  ## Notes
  - This keeps the legacy config key as a no-op for compatibility while
  removing the ability to toggle the behavior off cleanly.
  - No developer-facing docs update outside the touched app-server README
  was needed.

  sayan-oai · 2026-05-19 01:24:39 +00:00
  daa11820b0
• 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
• goal: pause continuation loops on usage limits and blockers (#23094)

  Addresses #22833, #22245, #23067
  
  ## Why
  `/goal` can keep synthesizing turns even when the next turn cannot make
  meaningful progress. Hard usage exhaustion can replay failing turns, and
  repeated permission or external-resource blockers can keep burning
  tokens while waiting for user or system intervention.
  
  ## What changed
  - Add resumable `blocked` and `usageLimited` goal states. As with
  `paused`, goal continuation stops with these states.
  - Move to `usageLimited` after usage-limit failures.
  - Allow the built-in `update_goal` tool to set `blocked` only under
  explicit repeated-impasse guidance. Updated goal continuation prompt to
  specify that agent should use `blocked` only when it has made at least
  three attempts to get past an impasse.
  
  Most of the files touched by this PR are because of the small app server
  protocol update.
  
  ## Validation
  
  I manually reproduced a number of situations where an agent can run into
  a true impasse and verified that it properly enters `blocked` state. I
  then resumed and verified that it once again entered `blocked` state
  several turns later if the impasse still exists.
  
  I also manually reproduced the usage-limit condition by creating a
  simulated responses API endpoint that returns 429 errors with the
  appropriate error message. Verified that the goal runtime properly moves
  the goal into `usageLimited` state and TUI UI updates appropriately.
  Verified that `/goal resume` resumes (and immediately goes back into
  `ussageLImited` state if appropriate).
  
  
  ## Follow-up PRs
  
  Small changes will be needed to the GUI clients to properly handle the
  two new states.

  Eric Traut · 2026-05-18 11:28:53 -07:00
  0d344aca9b
• [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
• [codex] Add opaque desktop config namespace (#22584)

  ## Summary
  - reserve an explicit opaque `desktop` namespace in `ConfigToml`
  - expose `desktop` directly in the app-server v2 `config/read` response
  - keep `config/value/write` and `config/batchWrite` as the only mutation
  seam for paths like `desktop.someKey`
  - regenerate the config/app-server schema outputs and document the new
  contract
  
  ## Why
  The desktop settings work wants one durable, user-editable home for
  app-owned preferences in `~/.codex/config.toml`, without forcing Rust to
  model every individual desktop setting key.
  
  This PR is only the enabling Rust/app-server layer. It gives the
  Electron app a first-class config namespace it can read and write
  through the existing config APIs, while leaving the actual desktop
  migration to the app PR.
  
  ## Behavior and design notes
  - **Opaque but explicit:** `desktop` is first-class at the typed config
  root, while its children remain app-owned and open-ended.
  - **Strict validation still works:** arbitrary nested `desktop.*` keys
  are accepted instead of being rejected as unknown config.
  - **Existing config APIs stay the seam:** `config/read` returns the bag,
  and dotted writes such as `desktop.someKey` continue to flow through
  `config/value/write` / `config/batchWrite` rather than a bespoke RPC.
  - **No new consumer behavior:** Core/TUI do not start depending on
  desktop preferences. This only preserves and exposes the namespace for
  callers that intentionally use it.
  - **Same persistence machinery:** hand-edited `config.toml` keeps using
  the existing TOML edit/write path; this PR does not introduce a second
  serializer or side channel.
  - **TOML-friendly values:** the namespace is intended for ordinary
  JSON-shaped setting values that map cleanly into TOML: strings, numbers,
  booleans, arrays, and nested object/table values. This PR does not add
  special handling for TOML-only edge cases such as datetimes.
  
  ## Layering semantics
  Reads keep using the ordinary effective config pipeline, so `desktop`
  participates in the same layered `config/read` behavior as the rest of
  `ConfigToml`. Writes still target user config through the existing
  config service.
  
  ## Why this is the shape
  The alternative would be teaching Rust about each desktop setting as it
  is added. That would make ordinary app preferences into a cross-repo
  change, which is exactly the coupling we want to avoid.
  
  This keeps the contract small:
  1. Rust owns one opaque `desktop` namespace in `config.toml`.
  2. The desktop app owns the schema and meaning of individual keys inside
  it.
  3. The existing config APIs remain the transport and mutation surface.
  
  That is the piece the desktop settings PR needs in order to move forward
  cleanly.
  
  ## Verification
  - `cargo test -p codex-config strict_config_accepts_opaque_desktop_keys`
  - `cargo test -p codex-core
  desktop_toml_round_trips_opaque_nested_values`
  - `cargo test -p codex-core config_schema_matches_fixture`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server --test all desktop_settings`

  guinness-oai · 2026-05-15 02:34:21 +00:00
  4f2918dd7f
• 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
• Use root repo hooks in linked worktrees (#21969)

  # Why
  
  Linked worktrees currently load their own project hook declarations, so
  the same repo can present different hook definitions depending on which
  checkout is active. https://github.com/openai/codex/pull/21762 tried to
  share trust by giving matching worktree hooks a shared synthetic key,
  but review pointed out that divergent worktree hook definitions would
  then fight over one `trusted_hash`.
  
  Instead of introducing a second trust model, this makes linked worktrees
  use the root checkout as the single source of truth for project hook
  declarations. Worktree-local project config can still diverge for
  unrelated settings, but project hooks now keep one real source path and
  one trust state per repo.
  
  # What
  
  - Teach project config loading to remember the matching root-checkout
  `.codex/` folder for actual linked-worktree project layers.
  - Keep ordinary project config sourced from the worktree, but replace
  project hook declarations with the root checkout's matching layer before
  hook discovery runs, including linked-worktree layers with `.codex/` but
  no local `config.toml`.
  - Make hook discovery use that authoritative hook folder for both
  `hooks.json` and TOML hook source paths, so linked worktrees produce the
  same hook key and trust state as the root checkout.
  - Cover the linked-worktree path plus regressions for missing worktree
  `config.toml` and nested non-worktree project roots.

  Abhinav · 2026-05-13 06:58:58 +00:00
  934a40c7d9
• Add allow_managed_hooks_only hook requirement (#20319)

  ## Why
  
  Enterprise-managed hook policy needs a narrow way to require Codex to
  ignore user-controlled lifecycle hooks without adopting the broader
  trust-precedence model from earlier hook work. This keeps the policy
  anchored in `requirements.toml`, so admins can opt into managed hooks
  only while normal `config.toml` files cannot enable the restriction
  themselves.
  
  ## What changed
  
  - Added `allow_managed_hooks_only` to the requirements data flow and
  preserved explicit `false` values.
  - Also adds it to /debug-config
  - Marked MDM, system, and legacy managed config layers as managed for
  hook discovery.
  - Updated hook discovery so `allow_managed_hooks_only = true`:
    - keeps managed requirements hooks and managed config-layer hooks,
  - skips user/project/session `hooks.json` and `[hooks]` entries with
  concise startup warnings,
    - skips current unmanaged plugin hooks,
  - ignores any `allow_managed_hooks_only` key placed in ordinary
  `config.toml` layers.

  Andrei Eternal · 2026-05-12 19:05:25 -07:00
  913aad4d3c
• Restore app-server websocket listener with auth guard (#22404)

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

  Eric Traut · 2026-05-12 18:40:53 -07:00
  51bfb5f3b1
• Fix goal update and add /goal edit command in TUI (#21954)

  ## Why
  
  Users have requested the ability to edit a goal's objective after a goal
  has been created. This PR exposes a new `/goal edit` command in the TUI
  to address this request.
  
  In the process of implementing this, I also noticed an existing bug in
  the goal runtime. When a goal's objective is updated through the
  `thread/goal/set` app server API, the goal runtime didn't emit a new
  steering prompt to tell the agent about the new objective. This PR also
  fixes this hole.
  
  ## What Changed
  
  - Adds `/goal edit` in the TUI, opening an edit box prefilled with the
  current goal objective.
  - Keeps active and paused goals in their current state, resets completed
  goals to active, keeps budget-limited goals budget-limited, and
  preserves the existing token budget.
  - Changes the existing `thread/goal/set` behavior so editing an
  objective preserves goal accounting instead of resetting it. The older
  reset-on-new-objective behavior was left over from before
  `thread/goal/clear`; clients that need to reset accounting can now clear
  the existing goal and create a new one.
  - Reuses the existing goal set API path; this does not add or change
  app-server protocol surface area.
  - Adds a dedicated goal runtime steering prompt when an externally
  persisted goal mutation changes the objective, so active turns receive
  the updated objective.
  
  ## Validation
  
  - Make sure `/goal edit` returns an error if no goal currently exists
  - Make sure `/goal edit` displays an edit box that can be optionally
  canceled with no side effects
  - Make sure that an edited goal results in a steer so the agent starts
  pursuing the new objective
  - Make sure the new objective is reflected in the goal if you use
  `/goal` to display the goal summary
  - Make sure that `/goal edit` doesn't reset the token budget, time/token
  accounting on the updated goal

  Eric Traut · 2026-05-11 10:49:19 -07:00
  1e65b3e0af
• app-server: remove TCP websocket listener (#21843)

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

  Ruslan Nigmatullin · 2026-05-11 10:17:26 -07:00
  a124ddb854
• [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
• Remove skills list extra roots (#21485)

  ## Summary
  - Remove `perCwdExtraUserRoots` / `SkillsListExtraRootsForCwd` from the
  `skills/list` app-server API.
  - Drop Rust app-server and `codex-core-skills` extra-root plumbing so
  skill scans are keyed by the normal cwd/user/plugin roots only.
  - Regenerate app-server schemas and update docs/tests that only existed
  for the removed extra-roots behavior.
  
  ## Validation
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-skills`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core-skills`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`
  
  ## Notes
  - `cargo test -p codex-app-server --test all skills_list` ran the edited
  skills-list cases, but the full filtered run ended on existing
  `skills_changed_notification_is_emitted_after_skill_change` timeout
  after a websocket `401`.
  - `cargo test -p codex-tui --lib` compiled the changed TUI callers, then
  failed two unrelated status permission tests because local
  `/etc/codex/requirements.toml` forbids `DangerFullAccess`.
  - Source-truth check found the OpenAI monorepo still has
  generated/app-server-kit mirror references to the removed field; those
  should be cleaned up when generated app-server types are synced or in a
  companion OpenAI cleanup.

  xli-oai · 2026-05-07 20:56:42 -07:00
  314229fd72
• feat(app-server, threadstore): Thread pagination APIs and ThreadStore contract (#21566)

  ## Why
  The goal of this PR is to align on app-server and `ThreadStore` API
  updates for paginating through large threads.
  
  
  #### app-server
  ##### `thread/turns/list`
  - Updates `thread/turns/list` to support `itemsView?: "notLoaded" |
  "summary" | "full" | null`, defaulting to `summary`.
  - Implements the current `thread/turns/list` behavior over the existing
  persisted rollout-history fallback:
    - `notLoaded` returns turn envelopes with empty `items`.
  - `summary` returns the first user message and final assistant message
  when available.
    - `full` preserves the existing full item behavior.
  
  Note that this method still uses the naive approach of loading the
  entire rollout file, and returns just the filtered slice of the data.
  Real pagination will come later by leveraging SQLite.
  
  ##### `thread/turns/items/list`
  - Adds the experimental `thread/turns/items/list` protocol, schema,
  dispatcher, and processor stub. The app-server currently returns
  JSON-RPC `-32601` with `thread/turns/items/list is not supported yet`.
  
  #### ThreadStore
  - Adds the experimental `thread/turns/items/list` protocol, schema,
  dispatcher, and processor stub. The app-server currently returns
  JSON-RPC `-32601` with `thread/turns/items/list is not supported yet`.
  - Adds `ThreadStore` contract types and stubbed methods for listing
  thread turns and listing items within a turn.
  - Adds a typed `StoredTurnStatus` and `StoredTurnError` to avoid baking
  app-server API enums or lossy string status values into the store-facing
  turn contract.
  - Adds a typed `StoredTurnStatus` and `StoredTurnError` to avoid baking
  app-server API enums or lossy string status values into the store-facing
  turn contract.
  
  This also sketches the storage abstraction we expect to need once turns
  are indexed/stored. In particular, `notLoaded` is useful only if
  ThreadStore can eventually list turn metadata without loading every
  persisted item for each turn.
  
  ## Validation
  
  - Added/updated protocol serialization coverage for the new request and
  response shapes.
  - Added app-server integration coverage for `thread/turns/list` default
  summary behavior and all three `itemsView` modes.
  - Added app-server integration coverage that `thread/turns/items/list`
  returns the expected unsupported JSON-RPC error when experimental APIs
  are enabled.
  - Added thread-store coverage that the default trait methods return
  `ThreadStoreError::Unsupported`.
  
  No developers.openai.com documentation update is needed for this
  internal experimental app-server API surface.

  Owen Lin · 2026-05-07 15:44:43 -07:00
  0d0835dd53
• device-key: clean up unused crate (#21487)
  Ruslan Nigmatullin · 2026-05-07 09:01:44 -07:00
  e64a8979b0
• Show plugin hooks in plugin details (#21447)

  Supersedes the abandoned #19859, rebuilt on latest `main`.
  
  # Why
  
  PR #19705 adds discovery for hooks bundled with plugins, but `/plugins`
  still only shows skills, apps, and MCP servers. This follow-up makes
  bundled hooks visible in the same plugin detail view so users can
  inspect the full plugin surface in one place.
  
  We also need `PluginHookSummary` to populate Plugin Hooks in the app;
  `hooks/list` is not enough there because plugin detail needs to show
  hooks for disabled plugins too.
  
  # What
  
  - extend `plugin/read` with `PluginHookSummary` entries for bundled
  hooks
  - summarize plugin hooks while loading plugin details
  - render a `Hooks` row in the `/plugins` detail popup
  
  <img width="3456" height="848" alt="CleanShot 2026-04-27 at 11 45 34@2x"
  src="https://github.com/user-attachments/assets/fe3a38d6-a260-4351-8513-fb04c93d725b"
  />

  Abhinav · 2026-05-07 00:21:14 -07:00
  40e282849c
• feat(app-server): move v2 sessionId onto Thread (#21336)

  ## Why
  
  `session_id` and `thread_id` are separate identities after #20437, but
  app-server only surfaced `sessionId` on the `thread/start`,
  `thread/resume`, and `thread/fork` response envelopes. Other
  thread-bearing surfaces such as `thread/list`, `thread/read`,
  `thread/started`, `thread/rollback`, `thread/metadata/update`, and
  `thread/unarchive` either lacked the grouping key or forced clients to
  special-case those three responses.
  
  Making `sessionId` part of the reusable `Thread` payload gives every v2
  API surface one place to expose session-tree identity.
  
  ## Mental model
    1. thread.sessionId lives on `Thread`
  2. It is a view/runtime identity for the current live session tree, not
  durable stored lineage metadata
  3. When app-server has a live loaded thread, it copies the real value
  from core’s session_configured.session_id
  4. When it only has stored/unloaded data, it falls back to
  thread.sessionId = thread.id
  
  ## What changed
  
  - Added `sessionId` to the v2
  [`Thread`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server-protocol/src/protocol/v2/thread_data.rs#L105-L109).
  - Removed the duplicate top-level `sessionId` fields from
  `thread/start`, `thread/resume`, and `thread/fork`; clients should now
  read `response.thread.sessionId`.
  - Populated `thread.sessionId` when building live thread responses,
  replaying loaded threads, and returning stored-thread summaries so the
  field is present across start, resume, fork, list, read, rollback,
  metadata-update, unarchive, and `thread/started` paths. See
  [`load_thread_from_resume_source_or_send_internal`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/src/request_processors/thread_processor.rs#L2824-L2918)
  and
  [`thread_from_stored_thread`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/src/request_processors/thread_processor.rs#L3671-L3719).
  - Preserved the stored-thread fallback: if a thread has not been loaded
  into a live session tree yet, `thread.sessionId` falls back to
  `thread.id`; once the thread is live again, the field reports the active
  session tree root.
  - Regenerated the JSON/TypeScript schemas and updated the app-server
  README examples to show
  [`thread.sessionId`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/README.md#L306-L310)
  on the thread object.

  jif-oai · 2026-05-06 15:23:25 +02:00
  5ecff05196
• feat: return session ID from thread/fork (#21332)

  ## Why
  
  `thread/start` and `thread/resume` already return `sessionId`, but
  `thread/fork` only returned the new thread. That left clients to infer
  the forked thread's session identity from `thread.id`, which kept the
  new `session_id` / `thread_id` split implicit at one lifecycle boundary.
  Follow-up to #20437.
  
  ## What changed
  
  - Add `sessionId` to `ThreadForkResponse`.
  - Populate it from the forked session configuration.
  - Regenerate the v2 JSON/TypeScript schema fixtures and update the
  app-server docs/example.
  - Extend the fork integration test to assert the returned `sessionId`.
  
  ## Verification
  
  - Added coverage in `thread_fork_creates_new_thread_and_emits_started`
  for the new response field.

  jif-oai · 2026-05-06 12:04:27 +02:00
  06e5dfa4dd
• app-server: align dynamic tool identifiers with Responses API (#20724)

  ## Why
  
  Codex currently accepts dynamic tool names and namespaces that the
  upstream Responses function-tool path does not actually support. In
  practice, that means app-server can register a dynamic tool successfully
  and only discover later that the LLM-facing tool contract will reject or
  mishandle it.
  
  This PR tightens the app-server-side dynamic tool contract to match the
  Responses API before we stack dynamic tool hook support on top of it.
  
  ## What changed
  
  - validate dynamic tool `name` against the Responses function-tool
  identifier contract: `^[a-zA-Z0-9_-]+$`, length `1..128`
  - validate dynamic tool `namespace` the same way, with the Responses
  namespace length limit `1..64`
  - reject namespaces that collide with the always-reserved Responses
  runtime namespaces such as `functions`, `multi_tool_use`, `file_search`,
  `web`, `browser`, `image_gen`, `computer`, `container`, `terminal`,
  `python`, `python_user_visible`, `api_tool`, `tool_search`, and
  `submodel_delegator`
  - escape invalid identifiers in error messages so control characters do
  not spill raw into logs or client-visible error text
  - document the tightened dynamic tool identifier contract in
  `codex-rs/app-server/README.md`
  - add both unit coverage for the validator and an app-server integration
  test that rejects a `thread/start` request with Responses-incompatible
  dynamic tool identifiers
  
  ## Verification
  
  - `cargo test -p codex-app-server validate_dynamic_tools_`
  - `cargo test -p codex-app-server --test all
  thread_start_rejects_dynamic_tools_not_supported_by_responses`

  Andrei Eternal · 2026-05-05 21:05:00 -07:00
  8ef31894dc
• add turn items view to app-server turns (#21063)

  ## Why
  
  `Turn.items` currently overloads an empty array to mean either that no
  items exist or that the server intentionally did not load them for this
  response. That ambiguity blocks future lazy-loading work where clients
  need to distinguish unloaded, summary, and fully hydrated turn payloads.
  
  ## What changed
  
  - add a new `TurnItemsView` enum with `notLoaded`, `summary`, and `full`
  variants
  - add required `itemsView` metadata to app-server `Turn` payloads
  - mark reconstructed persisted history as `full` and live shell-style
  turn payloads as `notLoaded`
  - keep current `thread/turns/list` behavior unchanged and document that
  it still returns `full` turns today
  - regenerate the JSON and TypeScript protocol fixtures
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server thread_read_can_include_turns`
  - `cargo test -p codex-app-server
  thread_turns_list_can_page_backward_and_forward`
  - `cargo test -p codex-app-server
  thread_resume_rejects_history_when_thread_is_running`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fmt`

  rhan-oai · 2026-05-05 19:17:16 +00:00
  9e0c191c13
• hook trust metadata and enforcement (#20321)

  # Why
  
  We want shared hook trust that both the app and the TUI can build on,
  but the metadata is only useful if runtime behavior agrees with it. This
  PR adds a single backend trust model for hooks so unmanaged hooks cannot
  run until the current definition has been reviewed, while managed hooks
  remain runnable and non-configurable.
  
  # What
  
  - persist `trusted_hash` alongside hook state in `config.toml`
  - expose `currentHash` and derived `trustStatus` through `hooks/list`
  - derive trust from normalized hook definitions so equivalent hooks from
  `config.toml` and `hooks.json` share the same trust identity
  - gate unmanaged hooks on trust before they enter the runnable handler
  set
  
  # Reviewer Notes
  
  - key file to review is `codex-rs/hooks/src/engine/discovery.rs`
  - the only **core** change is schema related

  Abhinav · 2026-05-05 19:13:55 +00:00
  0452dca986
• [codex] Add unsandboxed process exec API (#19040)

  ## Why
  
  App-server clients sometimes need argv-based local process execution
  while sandbox policy is controlled outside Codex. Those environments can
  reject sandbox-disabling paths before a command ever starts, even when
  the caller intentionally wants unsandboxed execution.
  
  This PR adds a distinct `process/*` API for that use case instead of
  extending `command/exec` with another sandbox-disabling shape. Keeping
  the new surface separate also makes the future removal of `command/exec`
  simpler: clients that need explicit process lifecycle control can move
  to the newer handle-based API without depending on `command/exec`
  business logic.
  
  ## What changed
  
  - Added v2 process lifecycle methods: `process/spawn`,
  `process/writeStdin`, `process/resizePty`, and `process/kill`.
  - Added process notifications: `process/outputDelta` for streamed
  stdout/stderr chunks and `process/exited` for final exit status and
  buffered output.
  - Made `process/spawn` intentionally unsandboxed and omitted
  sandbox-selection fields such as `sandboxPolicy` and
  `permissionProfile`.
  - Added client-supplied, connection-scoped `processHandle` values for
  follow-up control requests and notification routing.
  - Supported cwd, environment overrides, PTY mode and size, stdin
  streaming, stdout/stderr streaming, per-stream output caps, and timeout
  controls.
  - Killed active process sessions when the originating app-server
  connection closes.
  - Wired the implementation through the modular `request_processors/`
  app-server layout, with process-handle request serialization for
  follow-up control calls.
  - Updated generated JSON/TypeScript schema fixtures and documented the
  new API in `codex-rs/app-server/README.md`.
  - Added v2 app-server integration coverage in
  `codex-rs/app-server/tests/suite/v2/process_exec.rs` for spawn
  acknowledgement before exit, buffered output caps, and process
  termination.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  Ruslan Nigmatullin · 2026-05-04 16:43:58 -07:00
  4950e7d8a6
• feat(app-server): always return limited thread history (#20682)

  ## Why
  
  Whenever we return a thread's history (turns and items) over app-server,
  always return the limited form as specified by the rollout policy
  `EventPersistenceMode::Limited`, even if the thread was previously
  started with `EventPersistenceMode::Extended`.
  
  We're finding it is quite unscalable to be returning the extended
  history, so let's apply the same filtering logic of the rollout policy
  when we load and return the thread's history.
  
  ## What Changed
  
  - Reuse the rollout persistence policy when reconstructing app-server
  `ThreadItem` history so only `EventPersistenceMode::Limited` rollout
  items are replayed into API turns.
  - Route `thread/read`, `thread/resume`, `thread/fork`,
  `thread/turns/list`, and rollback responses through the same filtered
  app-server history projection.
  - Keep live active turns intact when composing a response for a
  currently running thread.
  - Update command execution coverage so persisted extended command events
  are excluded from returned history for `thread/read`, `thread/fork`, and
  `thread/turns/list`.
  
  ## Test Plan
  
  - `cargo test -p codex-app-server limited`
  - `cargo test -p codex-app-server thread_shell_command`
  - `cargo test -p codex-app-server thread_read`
  - `cargo test -p codex-app-server thread_rollback`
  - `cargo test -p codex-app-server thread_fork`
  - `cargo test -p codex-app-server-protocol`

  Owen Lin · 2026-05-04 10:37:35 -07:00
  541e99cf09
• Add remote plugin skill read API (#20150)

  ## Summary
  
  Adds an app-server `plugin/skill/read` method for remote plugin skill
  markdown. The new method calls the plugin-service skill detail endpoint
  and returns `skill_md_contents`, so clients can preview skills for
  remote plugins before the bundle is installed locally.
  
  ## Why
  
  Uninstalled remote plugin skills do not have local `SKILL.md` files.
  Without an on-demand remote read, the desktop plugin details UI cannot
  render the skill details modal for those skills.
  
  ## Validation
  
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server --test all --
  suite::v2::plugin_read::plugin_skill_read_reads_remote_skill_contents_when_remote_plugin_enabled
  --exact`
  - `just fix -p codex-app-server-protocol -p codex-core-plugins -p
  codex-app-server`

  xli-oai · 2026-05-01 00:16:25 -07:00
  96d2ea9058
• Surface admin-disabled remote plugin status (#20298)

  ## Summary
  
  Remote plugin-service returns plugin availability separately from a
  user's installed/enabled state. This adds `PluginAvailabilityStatus` to
  the app-server protocol, propagates remote catalog `status` into
  `PluginSummary`, and rejects install attempts for remote plugins marked
  `DISABLED_BY_ADMIN` before downloading or caching the bundle.
  
  This is the `openai/codex` half of the change. The companion
  `openai/openai` webview PR is
  https://github.com/openai/openai/pull/873269.
  
  ## Validation
  
  - `cargo run -p codex-app-server-protocol --bin write_schema_fixtures`
  - `cargo test -p codex-app-server --test all
  plugin_list_marks_remote_plugin_disabled_by_admin`
  - `cargo test -p codex-app-server --test all
  plugin_list_includes_remote_marketplaces_when_remote_plugin_enabled`
  - `cargo test -p codex-app-server --test all
  plugin_install_rejects_remote_plugin_disabled_by_admin_before_download`
  - `cargo test -p codex-app-server-protocol schema_fixtures`

  xli-oai · 2026-04-30 20:00:07 -07:00
  bb60b78c46
• fix(app-server): mark thread/turns/list and exclude_turns as experime… (#20499)

  …ntal
  
  We have some bugs to work out and it is not quite ready to consume as a
  public API.

  Owen Lin · 2026-04-30 17:39:08 -07:00
  5affb7f9d5
• Send external import completion for sync imports (#20379)
  alexsong-oai · 2026-04-30 13:03:21 -07:00
  9121132c8f
• Stop emitting item/fileChange/outputDelta output delta notifications (#20471)

  ## Why
  
  `item/fileChange/outputDelta` text output was only the tool's summary or
  error text and not used by client surfaces.
  
  We keep `item/fileChange/outputDelta` in the app-server protocol as a
  deprecated compatibility entry, but the server no longer emits it.
  
  ## What changed
  
  - stop the `apply_patch` runtime from emitting `ExecCommandOutputDelta`
  events
  - simplify `item_event_to_server_notification` so command output deltas
  always map to `item/commandExecution/outputDelta`
  - remove the app-server bookkeeping that tried to detect whether an
  output delta belonged to a file change
  - mark `item/fileChange/outputDelta` as a deprecated legacy protocol
  entry in the v2 types, schema, and README
  - simplify the file-change approval tests so they only wait for
  completion instead of expecting output-delta notifications
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-thread-manager-sample`
  - `cargo test -p codex-app-server-protocol
  protocol::event_mapping::tests::exec_command_output_delta_maps_to_command_execution_output_delta
  -- --exact`
  - `cargo test -p codex-app-server
  turn_start_file_change_approval_accept_for_session_persists_v2 --
  --exact` *(failed before the test assertions because the wiremock
  `/responses` mock received 0 requests in setup)*

  pakrym-oai · 2026-04-30 11:42:07 -07:00
  b52083146c
• realtime: rename provider session ids (#20361)

  ## Summary
  
  Codex is repurposing `session` to mean a thread group, so the realtime
  provider session id should no longer use `session_id` / `sessionId` in
  Codex-facing protocol payloads. This PR renames that provider-specific
  field to `realtime_session_id` / `realtimeSessionId` and intentionally
  breaks clients that still send the old field names.
  
  ## What Changed
  
  - Renamed realtime provider session fields in `ConversationStartParams`,
  `RealtimeConversationStartedEvent`, and `RealtimeEvent::SessionUpdated`.
  - Renamed app-server v2 realtime request and notification fields to
  `realtimeSessionId`.
  - Removed legacy serde aliases for `session_id` / `sessionId`; clients
  must send the new names.
  - Propagated the rename through core realtime startup, app-server
  adapters, codex-api websocket handling, and TUI realtime state.
  - Regenerated app-server protocol schema/TypeScript outputs and updated
  app-server README examples.
  - Kept upstream Realtime API concepts unchanged: provider `session.id`
  parsing and `x-session-id` headers still use the upstream wire names.
  
  ## Testing
  
  - CI is running on the latest pushed commit.
  - Earlier local verification on this PR:
    - `cargo test -p codex-protocol`
  - `CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-core
  realtime_conversation`
    - `cargo test -p codex-app-server-protocol`
  - `CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-app-server
  realtime_conversation`
  - attempted `CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-tui` (local
  linker bus error while linking the test binary)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-30 13:39:48 +03:00
  8a97f3cf03
• Add persisted hook enablement state (#19840)

  ## Why
  
  After `hooks/list` exposes the hook inventory, clients need a way to
  persist user hook preferences, make those changes effective in
  already-open sessions, and distinguish user-controllable hooks from
  managed requirements without adding another bespoke app-server write
  API.
  
  ## What
  
  - Extends `hooks/list` entries with effective `enabled` state.
  - Persists user-level hook state under `hooks.state.<hook-id>` so the
  model can grow beyond a single boolean over time.
  - Uses the existing `config/batchWrite` path for hook state updates
  instead of introducing a dedicated hook write RPC.
  - Refreshes live session hook engines after config writes so
  already-open threads observe updated enablement without a restart.
  
  ## Stack
  
  1. openai/codex#19705
  2. openai/codex#19778
  3. This PR - openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  The generated schema files account for much of the raw diff. The core
  behavior is in:
  
  - `hooks/src/config_rules.rs`, which resolves per-hook user state from
  the config layer stack.
  - `hooks/src/engine/discovery.rs`, which projects effective enablement
  into `hooks/list` from source-derived managedness.
  - `config/src/hook_config.rs`, which defines the new `hooks.state`
  representation.
  - `core/src/session/mod.rs`, which rebuilds live hook state after user
  config reloads.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-30 04:46:32 +00:00
  8f3c06cc97
• permissions: expose active profile metadata (#20095)
  Michael Bolin · 2026-04-29 20:54:59 -07:00
  ac4332c05b
• Reduce the surface of collaboration modes (#20149)

  Collaboration modes were slightly invasive both into ThreadManager
  construction and ModelProvider

  pakrym-oai · 2026-04-29 17:22:41 -07:00
  fedcefe9da
• Import external agent sessions in background (#20284)

  Summary:
  - Return from external agent import before session history import
  finishes
  - Run session import work in the background and emit the existing
  completion notification when it is done
  - Serialize session imports so duplicate requests do not create
  duplicate imported threads
  
  Verification:
  - cargo test -p codex-app-server external_agent_config_
  - cargo test -p codex-external-agent-sessions
  - just fix -p codex-app-server
  - just fix -p codex-external-agent-sessions
  - git diff --check

  stefanstokic-oai · 2026-04-30 00:00:41 +00:00
  c8abcbf925