543 Commits

• [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
• Preserve image detail in app-server inputs (#20693)

  ## Summary
  
  - Add optional image detail to user image inputs across core, app-server
  v2, thread history/event mapping, and the generated app-server
  schemas/types.
  - Preserve requested detail when serializing Responses image inputs:
  omitted detail stays on the existing `high` default, while explicit
  `original` keeps local images on the original-resolution path.
  - Support `high`/`original` consistently for tool image outputs,
  including MCP `codex/imageDetail`, code-mode image helpers, and
  `view_image`.

  Curtis 'Fjord' Hawthorne · 2026-05-15 15:04:04 -07:00
  8543e39885
• 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
• [codex] Use compaction_trigger item for remote compaction v2 (#22809)

  ## Why
  
  Remote compaction v2 was still using `context_compaction` as both the
  request trigger and the compacted output shape. The Responses API now
  has the landed contract for this flow: Codex sends a dedicated `{
  "type": "compaction_trigger" }` input item, and the backend returns the
  standard `compaction` output item with encrypted content.
  
  This aligns the v2 path with that wire contract while preserving the
  existing local compacted-history post-processing behavior.
  
  ## What changed
  
  - Add `ResponseItem::CompactionTrigger` and regenerate the app-server
  protocol schema fixtures.
  - Send `compaction_trigger` from `remote_compaction_v2` instead of a
  payload-less `context_compaction`.
  - Collect exactly one backend `compaction` output item, then reuse the
  existing compacted-history rebuilding path.
  - Treat the trigger item as a transient request marker rather than model
  output or persisted rollout/memory content.
  
  ## Verification
  
  - `cargo test -p codex-protocol compaction_trigger`
  - `cargo test -p codex-core remote_compact_v2`
  - `cargo test -p codex-core compact_remote_v2`
  - `cargo test -p codex-core
  responses_websocket_sends_response_processed_after_remote_compaction_v2`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol schema_fixtures`

  jif-oai · 2026-05-15 11:40:35 +02:00
  0322ac3df8
• 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
• permissions: support workspace roots in profiles (#22610)

  ## Why
  
  This is the configuration/model half of the alternative permissions
  migration we discussed as a comparison point for
  [#22401](https://github.com/openai/codex/pull/22401) and
  [#22402](https://github.com/openai/codex/pull/22402).
  
  The old `workspace-write` model mixes three concerns that we want to
  keep separate:
  - reusable profile rules that should stay immutable once selected
  - user/runtime workspace roots from `cwd`, `--add-dir`, and legacy
  workspace-write config
  - internal Codex writable roots such as memories, which should not be
  shown as user workspace roots
  
  This PR gives permission profiles first-class `workspace_roots` so users
  can opt multiple repositories into the same `:workspace_roots` rules
  without using broad absolute-path write grants. It also starts
  separating the raw selected profile from the effective runtime profile
  by making `Permissions` expose explicit accessors instead of public
  mutable fields.
  
  A representative `config.toml` looks like this:
  
  ```toml
  default_permissions = "dev"
  
  [permissions.dev.workspace_roots]
  "~/code/openai" = true
  "~/code/developers-website" = true
  
  [permissions.dev.filesystem.":workspace_roots"]
  "." = "write"
  ".codex" = "read"
  ".git" = "read"
  ".vscode" = "read"
  ```
  
  If Codex starts in `~/code/codex` with that profile selected, the
  effective workspace-root set becomes:
  - `~/code/codex` from the runtime `cwd`
  - `~/code/openai` from the profile
  - `~/code/developers-website` from the profile
  
  The `:workspace_roots` rules are materialized across each root, so
  `.git`, `.codex`, and `.vscode` stay scoped the same way everywhere.
  Runtime additions such as `--add-dir` can still layer on later stack
  entries without mutating the selected profile.
  
  ## Stack Shape
  
  This PR intentionally stops before the profile-identity cleanup in
  [#22683](https://github.com/openai/codex/pull/22683) so the base review
  stays focused on config loading, workspace-root materialization, and
  compatibility with legacy `workspace-write`.
  
  The representation in this PR is therefore transitional: `Permissions`
  carries enough state to distinguish the raw constrained profile from the
  effective runtime profile, and there are still call sites that must keep
  the active profile identity and constrained profile value in sync. The
  follow-up PR replaces that with a single resolved profile state
  (`ResolvedPermissionProfile` / `PermissionProfileState`) that keeps the
  profile id, immutable `PermissionProfile`, and profile-declared
  workspace roots together. That follow-up removes APIs such as
  `set_constrained_permission_profile_with_active_profile()` where
  separate arguments could drift out of sync.
  
  Downstream PRs then build on this base to switch app-server turn updates
  to profile ids plus runtime workspace roots and to finish the
  user-visible summary behavior. Reviewers should judge this PR as the
  workspace-roots foundation, not as the final in-memory shape of selected
  permission profiles.
  
  ## Review Guide
  
  Suggested review order:
  
  1. Start with `codex-rs/core/src/config/mod.rs`.
  This is the main shape change in the base slice. `Permissions` now
  stores a private raw `Constrained<PermissionProfile>` plus runtime
  `workspace_roots`. Callers use `permission_profile()` when they need the
  raw constrained value and `effective_permission_profile()` when they
  need a materialized runtime profile. As noted above,
  [#22683](https://github.com/openai/codex/pull/22683) replaces this
  transitional shape with a resolved profile state that keeps identity and
  profile data together.
  
  2. Review `codex-rs/config/src/permissions_toml.rs` and
  `codex-rs/core/src/config/permissions.rs`.
  These add `[permissions.<id>.workspace_roots]`, resolve enabled entries
  relative to the policy cwd, and keep `:workspace_roots` deny-read glob
  patterns symbolic until the actual roots are known.
  
  3. Review `codex-rs/protocol/src/permissions.rs` and
  `codex-rs/protocol/src/models.rs`.
  These add the policy/profile materialization helpers that expand exact
  `:workspace_roots` entries and scoped deny-read globs over every
  workspace root. This is also where `ActivePermissionProfileModification`
  is removed from the core model.
  
  4. Review the legacy bridge in
  `Config::load_from_base_config_with_overrides` and
  `Config::set_legacy_sandbox_policy`.
  This is where legacy `workspace-write` roots become runtime workspace
  roots, while Codex internal writable roots stay internal and do not
  appear as user-facing workspace roots.
  
  5. Then skim downstream call sites.
  The interesting pattern is raw-vs-effective access: state/proxy/bwrap
  paths keep the raw constrained profile, while execution, summaries, and
  user-visible status use the effective profile and workspace-root list.
  
  ## What Changed
  
  - added `[permissions.<id>.workspace_roots]` to the config model and
  schema
  - added runtime `workspace_roots` state to `Config`/`Permissions` and
  `ConfigOverrides`
  - made `Permissions` profile fields private and replaced direct mutation
  with accessors/setters
  - added `PermissionProfile` and `FileSystemSandboxPolicy` helpers for
  materializing `:workspace_roots` exact paths and deny-read globs across
  all roots
  - moved legacy additional writable roots into runtime workspace-root
  state instead of active profile modifications
  - removed `ActivePermissionProfileModification` and its app-server
  protocol/schema export
  - updated sandbox/status summary paths so internal writable roots are
  not reported as user workspace roots
  
  ## Verification Strategy
  
  The targeted tests cover the behavior at the layers where regressions
  are most likely:
  - `codex-rs/core/src/config/config_tests.rs` verifies config loading,
  legacy workspace-root seeding, effective profile materialization, and
  memory-root handling.
  - `codex-rs/core/src/config/permissions_tests.rs` verifies profile
  `workspace_roots` parsing and `:workspace_roots` scoped/glob
  compilation.
  - `codex-rs/protocol/src/permissions.rs` unit tests verify exact and
  glob materialization over multiple workspace roots.
  - `codex-rs/tui/src/status/tests.rs` and
  `codex-rs/utils/sandbox-summary/src/sandbox_summary.rs` verify the
  user-facing summaries show effective workspace roots and hide internal
  writes.
  
  I also ran `cargo check --tests` locally after the latest stack refresh
  to catch cross-crate API breakage from the private-field/accessor
  changes.
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22610).
  * #22612
  * #22611
  * #22683
  * __->__ #22610

  Michael Bolin · 2026-05-14 18:25:23 -07:00
  c25d905f61
• 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
• [codex] Support multiple forced ChatGPT workspaces (#18161)

  ## Summary
  
  This change lets `forced_chatgpt_workspace_id` accept multiple workspace
  IDs instead of a single value.
  
  It keeps the existing config key name, adds backward-compatible parsing
  for a single string in `config.toml`, and normalizes the setting into an
  allowed workspace list across login enforcement, app-server config
  surfaces, and local ChatGPT auth helpers.
  
  ## Why
  
  Workspace-restricted deployments may need to allow more than one ChatGPT
  workspace without dropping the guardrail entirely.
  
  ## Server-side impact
  
  Codex's local server and app-server protocol needed changes because they
  previously assumed a single workspace ID. The local login flow now
  matches the auth backend interface by sending the allowed workspace list
  as a single comma-separated `allowed_workspace_id` query parameter.
  
  ## Validation
  
  This was tested with:
  
  - A single workspace config
  - With multi-workspace configs
  - With multiple workspaces in the config
  - The user only being a part of a subset of them
  
  All were successful.
  
  Automated coverage:
  
  - `cargo test -p codex-login`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-tui local_chatgpt_auth`
  - `cargo test --locked -p codex-app-server
  login_account_chatgpt_includes_forced_workspace_allowlist_query_param`

  rreichel3-oai · 2026-05-14 17:11:36 -04:00
  02a7205250
• feat: add layered --profile-v2 config files (#17141)

  ## Why
  
  `--profile-v2 <name>` gives launchers and runtime entry points a named
  profile config without making each profile duplicate the base user
  config. The base `$CODEX_HOME/config.toml` still loads first, then
  `$CODEX_HOME/<name>.config.toml` layers above it and becomes the active
  writable user config for that session.
  
  That keeps shared defaults, plugin/MCP setup, and managed/user
  constraints in one place while letting a named profile override only the
  pieces that need to differ.
  
  ## What Changed
  
  - Added the shared `--profile-v2 <name>` runtime option with validated
  plain names, now represented by `ProfileV2Name`.
  - Extended config layer state so the base user config and selected
  profile config are both `User` layers; APIs expose the active user layer
  and merged effective user config.
  - Threaded profile selection through runtime entry points: `codex`,
  `codex exec`, `codex review`, `codex resume`, `codex fork`, and `codex
  debug prompt-input`.
  - Made user-facing config writes go to the selected profile file when
  active, including TUI/settings persistence, app-server config writes,
  and MCP/app tool approval persistence.
  - Made plugin, marketplace, MCP, hooks, and config reload paths read
  from the merged user config so base and profile layers both participate.
  - Updated app-server config layer schemas to mark profile-backed user
  layers.
  
  ## Limits
  
  `--profile-v2` is still rejected for config-management subcommands such
  as feature, MCP, and marketplace edits. Those paths remain tied to the
  base `config.toml` until they have explicit profile-selection semantics.
  
  Some adjacent background writes may still update base or global state
  rather than the selected profile:
  
  - marketplace auto-upgrade metadata
  - automatic MCP dependency installs from skills
  - remote plugin sync or uninstall config edits
  - personality migration marker/default writes
  
  ## Verification
  
  Added targeted coverage for profile name validation, layer
  ordering/merging, selected-profile writes, app-server config writes,
  session hot reload, plugin config merging, hooks/config fixture updates,
  and MCP/app approval persistence.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-14 15:16:15 +02:00
  deedf3b2c4
• 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
• chore(config) rm tools.view_image (#22501)

  ## Summary
  It appears this config flag has been broken/a noop for quite some time:
  since https://github.com/openai/codex/pull/8850. Let's simplify and get
  rid of this.
  
  ## Testing
  - [x] Updated unit tests

  Dylan Hurd · 2026-05-13 12:35:37 -07:00
  9c691b74d6
• [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
• 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
• feat: Expose plugin versions and gate plugin sharing (#22397)

  - Adds localVersion to plugin summaries and remoteVersion to share
  context, including generated API schemas.
  - Hydrates local and remote plugin versions from manifests and remote
  release metadata.
  - Adds default-on plugin_sharing gate for shared-with-me listing and
  plugin/share/save, with disabled-path errors
      and focused coverage.

  xl-openai · 2026-05-12 17:56:30 -07:00
  d1430fd61e
• feat: Normalize remote plugin summary identities. (#22265)

  Makes plugin summaries use config-style plugin@marketplace IDs while
  exposing backend remote IDs separately as remotePluginId.
  
  Also fix the consistency issue of REMOTE_SHARED_WITH_ME_MARKETPLACE_NAME

  xl-openai · 2026-05-12 00:58:37 -07:00
  5b1a4c2fa7
• Add Windows hook command overrides (#22159)

  # Why
  
  Managed hook configs need a shared cross-platform shape without making
  the existing `command` field polymorphic. The common case is still one
  command string, with Windows needing a different entrypoint only when
  the runtime is actually Windows.
  
  Keeping `command` as the portable/default path and adding an optional
  Windows override keeps the config easier to read, preserves the existing
  scalar shape for non-Windows users, and avoids forcing every caller into
  a `{ unix, windows }` object when only one platform needs special
  handling.
  
  # What
  
  - Add optional `command_windows` / `commandWindows` alongside the
  existing hook `command` field.
  - Resolve `command_windows` only on Windows during hook discovery; other
  platforms continue to use `command` unchanged.
  - Keep trust hashing aligned to the effective command selected for the
  current runtime.
  
  # Docs
  
  The Codex hooks/config reference should document `command_windows` as
  the Windows-only override for command hooks.

  Abhinav · 2026-05-11 22:22:29 +00:00
  9ab7f4e6ac
• feat: Add role-aware plugin share context APIs (#21867)

  Expose discoverability and full share principals in share context, carry
  roles through save/updateTargets, hydrate local shared plugin reads, and
  keep share URLs only under plugin.shareContext.

  xl-openai · 2026-05-08 20:46:39 -07:00
  479491ed89
• [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
• feat: Use installation ID in remote enrollments (#21662)

  * Pass installation ID for storage on enrollments server for
  deduping/grouping multiple appservers per installation
  * Pass installation ID in remoteControl/status/changed events

  David de Regt · 2026-05-08 17:54:01 +00:00
  872b8b15b3
• feat: Update plugin share settings with discoverability (#21637)

  Requires discoverability on plugin/share/updateTargets so the server can
  manage workspace link access consistently, including auto-adding the
  workspace principal for UNLISTED.
  
  Also rejects LISTED on share creation and blocks client-supplied
  workspace principals while preserving response parsing for LISTED.

  xl-openai · 2026-05-07 21:28:18 -07:00
  ae15343243
• 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
• [codex-analytics] plumb protocol-native review timing (#21434)

  ## Why
  
  We want terminal tool review analytics, but the reducer should not stamp
  review timing from its own wall clock.
  
  This PR plumbs review timing through the real protocol and app-server
  seams so downstream analytics can consume the emitter's timestamps
  directly. Guardian reviews keep their enriched `started_at` /
  `completed_at` analytics fields by deriving those legacy second-based
  values from the same protocol-native millisecond lifecycle timestamps,
  rather than sampling a separate analytics clock.
  
  ## What changed
  
  - add `started_at_ms` to user approval request payloads
  - add `started_at_ms` / `completed_at_ms` to guardian review
  notifications
  - preserve Guardian review `started_at` / `completed_at` enrichment from
  the protocol-native timing source
  - stamp typed `ServerResponse` analytics facts with app-server-observed
  `completed_at_ms`
  - thread the new timing fields through core, protocol, app-server, TUI,
  and analytics fixtures
  
  ## Verification
  
  - `cargo test -p codex-app-server outgoing_message --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-app-server-protocol guardian --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-tui guardian --manifest-path codex-rs/Cargo.toml`
  - `cargo test -p codex-analytics analytics_client_tests --manifest-path
  codex-rs/Cargo.toml`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21434).
  * #18748
  * __->__ #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-07 20:31:41 -07:00
  99016ec732
• 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
• Disable empty Cargo test targets (#21584)

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

  Charlie Marsh · 2026-05-07 15:44:17 -07:00
  54ef99a365
• feat: Expose plugin share metadata in shareContext (#21495)

  Extends PluginSummary.shareContext with shareUrl and reader shareTargets

  xl-openai · 2026-05-07 10:07:03 -07:00
  114bac1409
• 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
• Revert state DB injection and agent graph store (#21481)

  ## Why
  
  Reverts #20689 to restore the previous optional state DB plumbing. The
  conflict resolution keeps the newer installation ID and session/thread
  identity changes that landed after #20689, while removing the mandatory
  state DB and agent graph store dependency from ThreadManager
  construction.
  
  ## What changed
  
  - Restored `Option<StateDbHandle>` through app-server, MCP server,
  prompt debug, and test entry points.
  - Removed the `codex-core` dependency on `codex-agent-graph-store` and
  reverted descendant lookup back to the existing state DB path when
  available.
  - Kept newer `installation_id` forwarding by passing it beside the
  optional DB handle.
  - Kept local thread-name updates working when the optional state DB
  handle is absent.
  
  ## Validation
  
  - `git diff --check`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-state -p codex-rollout -p
  codex-app-server-protocol`
  - Attempted `env CARGO_INCREMENTAL=0 cargo test -p codex-core -p
  codex-app-server -p codex-app-server-client -p codex-mcp-server -p
  codex-thread-manager-sample -p codex-tui`; blocked locally by a rustc
  ICE while compiling `v8 v146.4.0` with `rustc 1.93.0 (254b59607
  2026-01-19)` on `aarch64-apple-darwin`.

  pakrym-oai · 2026-05-06 22:48:29 -07:00
  a8488fec5e
• [codex] allow shared config reads in app-server queue (#21340)

  ## Summary
  - add a shared-read serialization mode for global app-server request
  families
  - let consecutive leading shared reads for the same family run together
  while keeping exclusive requests ordered
  - mark only `skills/list`, `config/read` and `plugin/list` as shared
  reads for now
  
  ## Why
  `skills/list` and `plugin/list` are read-only config-family requests,
  but the app-server queue currently treats every config request as
  exclusive. That means one long `skills/list` can make a later
  `plugin/list` wait even though the two requests do not mutate config.
  
  This change keeps the existing queue order but lets adjacent reads
  overlap. If a write is already waiting, later reads still stay behind
  it, so writes do not starve.
  
  ## Scope
  This intentionally keeps the first pass narrow:
  - shared reads: `skills/list`, `plugin/list`
  - still exclusive: `plugin/install`, `marketplace/*`,
  `skills/config/write`, `config/*write`, `config/read`, and the rest of
  the config family
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  
  ## Desktop verification
  I ran the dev desktop app against this branch's built binary with the
  existing UI timing logs enabled. The app did use
  `/Users/xli/code/codex_6/codex-rs/target/debug/codex`.
  
  The new scheduler behavior works, but this narrow change does not remove
  every cold-start delay: in the observed trace, an earlier exclusive
  `config/read` was already queued ahead of the later `skills/list` and
  `plugin/list` requests, so the page-open plugin requests still waited
  behind that earlier exclusive config-family request before they could
  run together.
  
  That means this PR is the scheduler primitive needed for shared reads,
  not the complete end-to-end latency fix by itself.
  
  ## Not run
  - full workspace test suite, because repo policy requires explicit
  approval before running it after touching `app-server-protocol`

  xli-oai · 2026-05-06 21:16:31 -07:00
  05cd5c313e
• Add compact lifecycle hooks (started by vincentkoc - external contrib) (#19905)

  Based on work from Vincent K -
  https://github.com/openai/codex/pull/19060
  
  <img width="1836" height="642" alt="CleanShot 2026-04-29 at 20 47 40@2x"
  src="https://github.com/user-attachments/assets/b647bb89-65fe-40c8-80b0-7a6b7c984634"
  />
  
  ## Why
  
  Compaction rewrites the conversation context that future model turns
  receive, but hooks currently have no deterministic lifecycle point
  around that rewrite. This adds compact lifecycle hooks so users can
  audit manual and automatic compaction, surface hook messages in the UI,
  and run post-compaction follow-up without overloading tool or prompt
  hooks.
  
  ## What Changed
  
  - Added `PreCompact` and `PostCompact` hook events across hook config,
  discovery, dispatch, generated schemas, app-server notifications,
  analytics, and TUI hook rendering.
  - Added trigger matching for compact hooks with the documented `manual`
  and `auto` matcher values.
  - Wired `PreCompact` before both local and remote compaction, and
  `PostCompact` after successful local or remote compaction.
  - Kept compact hook command input to lifecycle metadata: session id,
  Codex turn id, transcript path, cwd, hook event name, model, and
  trigger.
  - Made compact stdout handling consistent with other hooks: plain stdout
  is ignored as debug output, while malformed JSON-looking stdout is
  reported as failed hook output.
  - Added integration coverage for compact hook dispatch, trigger
  matching, post-compact execution, and the audited behavior that
  `decision:"block"` does not block compaction.
  
  ## Out of Scope
  
  - Hook-specific compaction blocking is not implemented;
  `decision:"block"` and exit-code-2 blocking semantics are intentionally
  unsupported for `PreCompact`.
  - Custom compaction instructions are not exposed to compact hooks in
  this PR.
  - Compact summaries, summary character counts, and summary previews are
  not exposed to compact hooks in this PR.
  
  ## Verification
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core
  manual_pre_compact_block_decision_does_not_block_compaction`
  - `cargo test -p codex-app-server hooks_list`
  - `cargo test -p codex-core config_schema_matches_fixture`
  - `cargo test -p codex-tui hooks_browser`
  
  ## Docs
  
  The developer documentation for Codex hooks should be updated alongside
  this feature to document `PreCompact` and `PostCompact`, the
  `manual`/`auto` matcher values, and the compact hook payload fields.
  
  ---------
  
  Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

  Andrei Eternal · 2026-05-06 18:08:31 -07:00
  527d52df03
• feat: Add marketplace source filtering and plugin share context (#21419)

  Adds marketplaceKinds to plugin/list for local, workspace-directory, and
  shared-with-me; omitted params keep default local plus gated global
  behavior, while explicit kinds are exact.
  
  Exposes shareContext on plugin summaries from local share mappings and
  remote workspace/shared responses, including remotePluginId and nullable
  creator metadata.
  
  Adds shared-with-me listing through /ps/plugins/workspace/shared,
  renames the workspace remote namespace to workspace-directory, and keeps
  direct remote read/share/install/update/delete paths gated by plugins
  rather than remote_plugin.

  xl-openai · 2026-05-06 16:12:23 -07:00
  11106016ff
• 2- Use string service tiers in session protocol (#20971)

  ## Summary
  - break service tier session/op/app-server protocol fields from the
  closed enum to string tier ids
  - send the service tier string directly through model requests, prewarm,
  compaction, memories, and TUI/app-server turn starts
  - regenerate app-server protocol JSON/TypeScript schemas, removing the
  standalone ServiceTier TS enum
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-app-server -p codex-tui
  - just write-app-server-schema
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-06 18:00:21 +03:00
  be1d3cff93
• 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
• feat: add session_id (#20437)

  ## Summary
  
  Related to
  https://openai.slack.com/archives/C095U48JNL9/p1777537279707449
  TLDR:
  We update the meaning of session ids and thread ids:
  * thread_id stays as now
  * session_id become a shared id between every thread under a /root
  thread (i.e. every sub-agent share the same session id)
  
  This PR introduces an explicit `SessionId` and threads it through the
  protocol/client boundary so `session_id` and `thread_id` can diverge
  when they need to, while preserving compatibility for older serialized
  `session_configured` events.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:37 +02:00
  a98623511b
• feat: Add plugin share access controls (#21124)

  Extends `plugin/share/save` to accept optional discoverability and
  shareTargets while uploading plugin contents, and adds
  `plugin/share/updateTargets` for share-only target updates without
  re-uploading.

  xl-openai · 2026-05-05 20:14:18 -07:00
  5119680f85
• [codex-analytics] rework thread_source for thread analytics (#20949)

  ## Summary
  - make `thread_source` an explicit optional thread-level field on
  `thread/start`, `thread/fork`, and returned thread payloads
  - persist `thread_source` in rollout/session metadata so resumed live
  threads retain the original value
  - replace the old best-effort `session_source` -> `thread_source`
  mapping with an explicit caller-supplied analytics classification
  
  ## Why
  Before this change, analytics `thread_source` was populated by a
  best-effort mapping from `session_source`. `session_source` describes
  the runtime/client surface, not the actual thread-level origin, so that
  projection was not accurate enough to distinguish cases such as `user`,
  `subagent`, `memory_consolidation`, and future thread origins reliably.
  
  Making `thread_source` explicit keeps one thread-level analytics field
  while letting callers provide the real classification directly instead
  of recovering it indirectly from `session_source`.
  
  ## Impact
  For new analytics events, `thread_source` now reflects the explicit
  thread-level classification supplied by the caller rather than an
  inferred value derived from `session_source`. Existing protocol fields
  remain optional; callers that omit `threadSource` now produce `null`
  instead of a best-effort inferred value.
  
  ## Validation
  - `just write-app-server-schema`
  - `cargo test -p codex-analytics -p codex-core -p
  codex-app-server-protocol --no-run`
  - `cargo test -p codex-app-server-protocol
  generated_ts_optional_nullable_fields_only_in_params`
  - `cargo test -p codex-analytics
  thread_initialized_event_serializes_expected_shape`
  - `cargo test -p codex-core
  resume_stopped_thread_from_rollout_preserves_thread_source`

  rhan-oai · 2026-05-06 02:12:31 +00:00
  b3d4f1a9f0
• Expose plugin manifest keywords in app server (#21271)

  ## Summary
  - Add plugin manifest keywords to core plugin marketplace/detail models
  - Expose keywords on app-server v2 PluginSummary and generated
  schema/types
  - Populate keywords in plugin/list and plugin/read responses for local
  plugins
  
  Depends on https://github.com/openai/openai/pull/891087
  
  ## Validation
  - just fmt
  - just write-app-server-schema
  - cargo test -p codex-app-server-protocol
  - cargo test -p codex-core-plugins
  - cargo test -p codex-app-server
  plugin_list_keeps_valid_marketplaces_when_another_marketplace_fails_to_load
  - cargo test -p codex-app-server
  plugin_read_returns_plugin_details_with_bundle_contents

  Abdulrahman Alfozan · 2026-05-06 02:09:05 +00:00
  94db03d5af
• chore(app-server-protocol): split v2 API definitions into modules (#21251)

  ## Why
  
  `codex-rs/app-server-protocol/src/protocol/v2.rs` had grown into a
  single ~12k-line definition file for the entire app-server v2 API.
  
  This is purely a mechanical refactor to break up the monolithic `v2.rs`
  file that contains all app-server API v2 types into more modular files,
  grouped by resource (e.g. account, thread, turn, etc.).
  
  `just write-app-server-schema` shows no real changes, so we can be sure
  that this is purely an internal organizational change.
  
  ## What changed
  
  - Replaced the monolithic `protocol/v2.rs` with a `protocol/v2/` module
  tree and a small `mod.rs` that only declares and reexports modules.
  - Grouped v2 API definitions by conceptual owner, including `account`,
  `apps`, `collaboration_mode`, `command_exec`, `config`, `device_key`,
  `experimental_feature`, `feedback`, `fs`, `hook`, `item`, `mcp`,
  `model`, `notification`, `permissions`, `plugin`, `process`, `realtime`,
  `review`, `thread`, `thread_data`, `turn`, and `windows_sandbox`.
  - Moved v2 tests into `protocol/v2/tests.rs` so `mod.rs` stays small.
  - Kept shared protocol helpers in `protocol/v2/shared.rs`, including the
  enum mirroring macro and common cross-resource types.
  - Co-located resource-specific notifications and server-request payloads
  with the modules that own those resources.
  - Regenerated app-server protocol schema fixtures. The schema diffs are
  non-semantic newline-only changes after the refactor.
  
  ## Verification
  
  - `cargo check -p codex-app-server-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `just write-app-server-schema`

  Owen Lin · 2026-05-05 16:46:51 -07:00
  d7de4dd3ac
• 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
• app-server: ignore persist_extended_history param (#21225)

  ## Why
  
  Taking a step to removing the `persistExtendedHistory` field. It's not
  scalable to be persisting so much data in the rollout file and returning
  it in the thread history.
  
  When a client explicitly sends `true`, the server now tells that client
  the parameter is deprecated and ignored so the caller has a clear
  migration signal via the `deprecationNotice` notification.
  
  ## What changed
  
  - Keep the `persist_extended_history` / `persistExtendedHistory` field
  in the v2 protocol for compatibility, but document it as deprecated and
  ignored.
  - Ignore the parameter in app-server `thread/start`, `thread/resume`,
  and `thread/fork`; those paths always use limited history persistence
  now.
  - Stop treating `persistExtendedHistory` as a running-thread resume
  override mismatch.
  - Emit a connection-scoped `deprecationNotice` when a request explicitly
  sets `persist_extended_history: true`.
  
  ## Verification
  
  - Added `thread_start_deprecates_persist_extended_history_true` to cover
  the deprecation notice.
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-app-server-protocol`

  Owen Lin · 2026-05-05 18:36:13 +00:00
  6075b77001
• Add Windows sandbox readiness RPC (#20708)

  ## Why
  
  The desktop app on Windows needs a read-only way to tell, before the
  next tool call, whether the local Windows sandbox setup is in a state
  that should block the user and ask for setup again.
  
  The main case we want to cover is the elevated sandbox setup version
  bump. Today, if the app is configured for elevated Windows sandboxing
  and the installed setup is stale, the next sandboxed shell/exec path can
  end up triggering the elevated setup flow directly. That means the user
  can see an unexpected UAC prompt with no UI explanation.
  
  This change adds a small app-server preflight so the desktop app can ask
  “is Windows sandbox ready, not configured, or update-required?” during
  startup and show the appropriate blocking UI before the user hits a tool
  call.
  
  ## What changed
  
  - Added a new read-only app-server RPC: `windowsSandbox/readiness`
  - Added a new protocol enum and response type:
    - `WindowsSandboxReadiness`
    - `WindowsSandboxReadinessResponse`
  - Added core readiness logic in `core/src/windows_sandbox.rs`:
    - `ready`
    - `notConfigured`
    - `updateRequired`
  - Wired the new request through `codex_message_processor`
  - Regenerated the vendored app-server schema fixtures
  
  ## Readiness semantics
  
  This is intentionally a coarse startup/version-bump readiness check, not
  a full predictor of every runtime repair case.
  
  For now, readiness is determined from:
  - the configured Windows sandbox level
  - `sandbox_setup_is_complete()` for elevated mode
  
  That means:
  - `disabled` maps to `notConfigured`
  - `restricted token` maps to `ready`
  - `elevated` maps to `ready` or `updateRequired` depending on
  `sandbox_setup_is_complete()`
  
  This is deliberate for the first UI integration because the common case
  we want to catch is “the app updated, the elevated setup version bumped,
  and the user should see an update-required blocker instead of a surprise
  UAC prompt”.
  
  It does not attempt to model every case where the deeper runtime path
  might decide to repair or re-run setup.
  
  ## Testing
  
  - Ran `cargo fmt --all -- app-server-protocol/src/protocol/common.rs
  app-server-protocol/src/protocol/v2.rs
  app-server/src/codex_message_processor.rs core/src/windows_sandbox.rs
  core/src/windows_sandbox_tests.rs`
  - Added unit tests for the pure readiness mapping in
  `core/src/windows_sandbox_tests.rs`
  - Regenerated vendored schema fixtures with `cargo run -p
  codex-app-server-protocol --bin write_schema_fixtures -- --schema-root
  app-server-protocol/schema`
  - Did not run the full cargo test suite

  iceweasel-oai · 2026-05-05 09:58:23 -07:00
  f35285dc78
• 1- Add model service tiers metadata (#20969)

  ## Why
  
  The model list needs to carry display-ready service tier metadata so
  clients can render tier choices with stable IDs, names, and
  descriptions. A raw speed-tier string list is not enough for richer UI
  copy or future tier labels.
  
  ## What changed
  
  - Added `ModelServiceTier` to shared model metadata with string `id`,
  `name`, and `description` fields.
  - Added `service_tiers` to `ModelInfo` and `ModelPreset`, preserving
  empty defaults for older cached model payloads.
  - Exposed `serviceTiers` on app-server v2 `Model` responses and threaded
  it through TUI app-server model conversion.
  - Marked legacy `additional_speed_tiers` / `additionalSpeedTiers`
  metadata as deprecated in source and generated schema output.
  - Regenerated app-server protocol JSON schema and TypeScript fixtures,
  including `ModelServiceTier.ts`.
  
  ## Verification
  
  - Ran `just write-app-server-schema`.
  - Did not run local tests per repo instruction; relying on PR CI.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-05 09:51:18 +03:00
  9d579813bb
• [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