458 Commits

• 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
• [codex] Emit MCP tool calls as turn items (#20677)

  ## Why
  
  `McpToolCall` was still an app-server item synthesized from deprecated
  legacy begin/end events. Recent item migrations moved this ownership
  into core `TurnItem`s, so MCP tool calls now follow the same canonical
  lifecycle and leave legacy events as compatibility fanout.
  
  Keeping the core item close to the v2 `ThreadItem::McpToolCall` shape
  also avoids spreading MCP result semantics across app-server conversion
  code. Core now owns whether a completed call is `completed` or `failed`,
  and whether the payload is a tool result or an error.
  
  ## What changed
  
  - Added core `TurnItem::McpToolCall` with flattened `server`, `tool`,
  `arguments`, `status`, `result`, and `error` fields.
  - Updated MCP tool call emitters, including MCP resource tools, to emit
  `ItemStarted`/`ItemCompleted` around directly constructed core MCP
  items.
  - Updated app-server v2 conversion to project the core MCP item into
  `ThreadItem::McpToolCall` without deriving status or splitting `Result`
  locally.
  - Ignored live deprecated MCP legacy fanout in app-server v2 to avoid
  duplicate item notifications, while keeping thread history replay on the
  legacy event path.
  
  ## Verification
  
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core --lib mcp_tool_call`
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server
  mcp_tool_call_completion_notification_contains_truncated_large_result`

  pakrym-oai · 2026-05-03 22:50:13 -07:00
  c8c30d9d75
• [codex] Emit image view as core item (#20512)

  ## Why
  
  Image-view results should be represented as a core-produced turn item
  instead of being reconstructed by app-server. At the same time, existing
  rollout/history paths still understand the legacy `ViewImageToolCall`
  event, so this keeps that event as compatibility output generated from
  the new item lifecycle.
  
  ## What changed
  
  - Added `TurnItem::ImageView` to `codex-protocol`.
  - Emitted image-view item start/completion directly from the core
  `view_image` handler.
  - Kept `ViewImageToolCall` as a legacy event and generate it from
  completed `TurnItem::ImageView` items.
  - Kept `thread_history.rs` on the legacy `ViewImageToolCall` replay
  path, with `ImageView` item lifecycle events ignored there.
  - Updated app-server protocol conversion, rollout persistence, and
  affected exhaustive event matches for the new item plus legacy fan-out
  shape.
  
  ## Verification
  
  - `cargo test -p codex-protocol -p codex-app-server-protocol -p
  codex-rollout -p codex-rollout-trace -p codex-mcp-server -p
  codex-app-server --lib`
  - `cargo test -p codex-core --test all
  view_image_tool_attaches_local_image`
  - `just fix -p codex-protocol -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-rollout -p codex-rollout-trace -p
  codex-mcp-server`
  - `git diff --check`

  pakrym-oai · 2026-05-01 11:28:30 -07:00
  aed74e5ee4
• Move apply-patch file changes into turn items (#20540)

  ## Why
  
  Apply-patch file changes are now part of the core turn item stream, so
  v2 clients can consume the same first-class item lifecycle path used by
  other turn items instead of relying on app-server-specific remapping
  from legacy patch events.
  
  ## What changed
  
  - Added a core `TurnItem::FileChange` carrying apply-patch changes and
  completion metadata.
  - Updated the apply-patch tool emitter to send `ItemStarted` /
  `ItemCompleted` with the new `FileChange` item while preserving legacy
  `PatchApplyBegin` / `PatchApplyEnd` fan-out.
  - Updated app-server v2 conversion to render the new core item directly
  and stopped `event_mapping` from remapping old patch begin/end events
  into item notifications.
  - Kept thread history reconstruction based on the existing old
  apply-patch events for rollout compatibility.
  
  ## Verification
  
  - `cargo test -p codex-protocol -p codex-app-server-protocol`
  - `cargo test -p codex-core --test all
  apply_patch_tool_executes_and_emits_patch_events`
  - `cargo test -p codex-app-server bespoke_event_handling`

  pakrym-oai · 2026-05-01 08:47:18 -07:00
  f476338f93
• feat: Track local paths for shared plugins (#20560)

  When a local plugin is shared, Codex now records the local plugin path
  by remote plugin id under CODEX_HOME/.tmp.
  
  plugin/share/list includes the remote share URL and the matching local
  plugin path when available, and plugin/share/delete
  clears the local mapping after deleting the remote share.
  
  Also add sharedURL to plugin/share/list.

  xl-openai · 2026-05-01 00:50:12 -07:00
  48791920a8
• 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
• [codex] Remove unused event messages (#20511)

  ## Why
  
  Several legacy `EventMsg` variants were still emitted or mapped even
  though clients either ignored them or had moved to item/lifecycle
  events. `Op::Undo` had also degraded to an unavailable shim, so this
  removes that dead task path instead of preserving a command that cannot
  do useful work.
  
  `McpStartupComplete`, `WebSearchBegin`, and `ImageGenerationBegin` are
  intentionally kept because useful consumers still depend on them: MCP
  startup completion drives readiness behavior, and the begin events let
  app-server/core consumers surface in-progress web-search and
  image-generation items before the final payload arrives.
  
  ## What Changed
  
  - Removed weak legacy event variants and payloads from `codex-protocol`,
  including legacy agent deltas, background events, and undo lifecycle
  events.
  - Kept/restored `EventMsg::McpStartupComplete`,
  `EventMsg::WebSearchBegin`, and `EventMsg::ImageGenerationBegin` with
  serializer and emission coverage.
  - Updated core, rollout, MCP server, app-server thread history,
  review/delegate filtering, and tests to rely on the useful replacement
  events that remain.
  - Removed `Op::Undo`, `UndoTask`, the undo test module, and stale TUI
  slash-command comments.
  - Stopped agent job/background progress and compaction retry notices
  from emitting `BackgroundEvent` payloads.
  
  ## Verification
  
  - `cargo check -p codex-protocol -p codex-app-server-protocol -p
  codex-core -p codex-rollout -p codex-rollout-trace -p codex-mcp-server`
  - `cargo test -p codex-protocol -p codex-app-server-protocol -p
  codex-rollout -p codex-rollout-trace -p codex-mcp-server`
  - `cargo test -p codex-core --test all suite::items`
  - `just fix -p codex-protocol -p codex-app-server-protocol -p codex-core
  -p codex-rollout -p codex-rollout-trace -p codex-mcp-server`
  - Earlier coverage on this PR also included `codex-mcp`, `codex-tui`,
  core library tests, MCP/plugin/delegate/review/agent job tests, and MCP
  startup TUI tests.

  pakrym-oai · 2026-04-30 20:03:26 -07:00
  f50c02d7bc
• 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
• 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
• Move item event mapping into app-server-protocol (#20299)

  ## Why
  
  Follow-up to #20291.
  
  The v2 item-event-to-notification translation had been embedded in
  `app-server/src/bespoke_event_handling.rs`, which made it hard to reuse
  anywhere else. This PR moves that stateless mapping into shared protocol
  code so other entry points can produce the same `ServerNotification`
  payloads without copying app-server logic.
  
  That also lets `thread-manager-sample` demonstrate the same notification
  surface that the app server exposes, instead of only printing the final
  assistant message.
  
  ## What changed
  
  - move `item_event_to_server_notification` into
  `codex-app-server-protocol::protocol::event_mapping`
  - keep the mapper tests next to the shared implementation in
  `codex-app-server-protocol`
  - re-export the mapper from `codex-core-api` so lightweight consumers
  can use it without reaching into `app-server-protocol` directly
  - simplify `app-server/src/bespoke_event_handling.rs` so it delegates
  the stateless event-to-notification projection to the shared helper
  - update `thread-manager-sample` to:
    - print mapped notifications as newline-delimited JSON
    - use the shared mapper through `codex-core-api`
  - enable the default feature set so the sample exposes the normal tool
  surface
  - use a `read_only` permission profile so shell commands can run in the
  sample without widening permissions
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-api`
  - `cargo test -p codex-app-server bespoke_event_handling::tests`
  - `cargo test -p codex-thread-manager-sample`
  - `cargo run -p codex-thread-manager-sample -- "briefly explore the repo
  with pwd and ls, then summarize it"`

  pakrym-oai · 2026-04-30 11:02:13 -07:00
  5cc5f12efc
• 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
• feat: Add workspace plugin sharing APIs (#20278)

  1. Adds v2 plugin/share/save, plugin/share/list, and plugin/share/delete
  RPCs.
  2. Implements save by archiving a local plugin root, enforcing a size
  limit, uploading through the workspace upload flow, and supporting
  updates via remotePluginId.
  3. Lists created workspace plugins
  4. Deletes a previously uploaded/shared plugin.

  xl-openai · 2026-04-29 23:49:20 -07:00
  87d0cf1a62
• 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
• Add hooks/list app-server RPC (#19778)

  ## Why
  
  We need a way to list the available hooks to expose via the TUI and App
  so users can view and manage their hooks
  
  ## What
  
  - Adds `hooks/list` for one or more `cwd` values that returns discovered
  hook metadata
  
  ## Stack
  
  1. openai/codex#19705
  2. This PR - openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Review Notes
  
  The generated schema files account for most of the raw diff, these files
  have the core change:
  
  - `hooks/src/engine/discovery.rs` builds the inventory entries during
  hook discovery while leaving runtime handlers focused on execution.
  - `app-server/src/codex_message_processor.rs` wires `hooks/list` into
  the app-server flow for each requested `cwd`.
  - `app-server-protocol/src/protocol/v2.rs` defines the new v2
  request/response payloads exposed on the wire.
  
  ### Core Changes
  
  `core/src/plugins/manager.rs` adds `plugins_for_layer_stack(...)` so
  `skills/list` and `hooks/list`can resolve plugin state for each
  requested `cwd`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-29 23:39:57 +00:00
  8774229a89
• Update Codex login success page UX (#20136)

  ## Summary
  
  update the local login success page to match the Codex desktop auth UX
  use theme-aware colors and an inline 20px Codex mark
  keep the actual localhost success page aligned with the browser auth UX
  PR
  
  ## Tests
  
  <img width="1728" height="1117" alt="Screenshot 2026-04-29 at 12 00
  34 PM"
  src="https://github.com/user-attachments/assets/76a40c3f-07c3-452c-97da-e7c43717cd2c"
  />

  rafael-jac · 2026-04-29 19:14:53 -04:00
  98f67b15d3
• [app-server] type client response payloads (#20050)

  ## Why
  
  `pr17088` adds typed server-originated request/response plumbing, but
  successful client responses are still erased into bare JSON-RPC `result`
  values before app-server can make any typed decision about them.
  
  This precursor PR keeps successful client responses typed until the
  outgoing response seam. It is intentionally limited to
  protocol/app-server plumbing so the analytics behavior change can review
  separately on top.
  
  ## What changed
  
  - Add `ClientResponsePayload` as the pre-serialization client response
  body type.
  - Route app-server successful response paths through the typed payload
  seam while preserving existing handler-local analytics behavior.
  - Keep `InterruptConversation` JSON-RPC-only because it has no
  `ClientResponse` variant.
  - Move the new payload conversion tests into a dedicated protocol test
  module.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server-protocol`

  rhan-oai · 2026-04-29 20:50:47 +00:00
  973c5c823e
• [codex-analytics] ingest server requests and responses (#17088)

  ## Why
  
  Codex analytics needs a typed seam for app-server-originated
  request/response traffic so future tool-approval analytics can consume
  those facts without adding bespoke callsite tracking each time. Server
  responses arrive as JSON-RPC `id + result` payloads, so analytics has to
  reconstruct the matching typed response from the original typed request
  while that request context still exists in app-server.
  
  This also puts analytics on the app-server outbound path, which needs to
  avoid keeping the runtime alive during shutdown. The final ownership fix
  keeps the normal strong auth-manager retention in analytics and makes
  the external-auth refresh bridge hold a weak back-reference to
  `OutgoingMessageSender`, breaking the runtime cycle at the bridge
  boundary instead of exposing retention policy through the analytics
  client API.
  
  ## What changed
  
  - Adds typed `ServerRequest` and `ServerResponse` analytics facts, plus
  `AnalyticsEventsClient::track_server_request` and
  `track_server_response`.
  - Renames the existing client-side facts to `ClientRequest` and
  `ClientResponse` so reducers can distinguish client-to-server traffic
  from server-to-client traffic.
  - Adds `ServerRequest::response_from_result`, allowing a stored typed
  request to decode the matching typed server response from a raw JSON-RPC
  result payload.
  - Threads `AnalyticsEventsClient` through `OutgoingMessageSender` and
  records targeted server requests, replayed targeted requests, and
  matching targeted responses with the responding connection id needed for
  correlation.
  - Intentionally leaves broadcast server requests/responses out of
  analytics for now because the current model is per connection, while
  broadcasts fan one logical request out across multiple connections.
  - Breaks the app-server shutdown cycle by storing
  `Weak<OutgoingMessageSender>` in `ExternalAuthRefreshBridge` and
  upgrading it only when an external-auth refresh is actually requested.
  - Keeps reducer ingestion of the new server-side facts as no-ops for
  now; this PR is plumbing for later tool-approval analytics work.
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-app-server outgoing_message::tests::`
  - Covers typed-response reconstruction plus the targeted, replayed,
  broadcast-exclusion, and response-attribution analytics paths.
  
  ## Follow-up
  
  This PR intentionally stops at ingestion plumbing, so `ServerRequest`
  and `ServerResponse` facts are still reducer no-ops. Once a follow-up PR
  adds real downstream analytics output for those facts:
  
  - replace the temporary pre-reducer observation seam with reducer tests
  for the emitted event shape;
  - add end-to-end coverage in `app-server/tests/suite/v2/analytics.rs`
  for the real app-server workflow and captured analytics payload;
  - remove the temporary sender-level observer tests added here in favor
  of the real-output coverage above.
  
  ---
  
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17088).
  * #18748
  * #18747
  * #17090
  * #17089
  * #20241
  * #20239
  * __->__ #17088

  rhan-oai · 2026-04-29 19:56:41 +00:00
  0690ab0842
• feat: expose provider capability bounds to app server clients (#20049)

  follow up of #19442. The app server now exposes provider-derived bounds
  through a new v2 `modelProvider/read` method. The response reports the
  configured provider map key as `modelProvider` and returns the effective
  capability booleans so clients can align their UI with the same
  provider-owned limits used by core.

  Celia Chen · 2026-04-29 01:36:19 +00:00
  8c47e36504
• Support detect and import MCP, Subagents, hooks, commands from external (#19949)

  ## Why
  This PR expands the migration path so Codex can detect and import MCP
  server config, hooks, commands, and subagents configs in a Codex-native
  shape.
  
  ## What changed
  
  - Added a `codex-external-agent-migration` crate that owns conversion
  logic for external-agent MCP servers, hooks, commands, and subagents.
  - Extended the app-server external-agent config detection/import API
  with migration item types for MCP server config, hooks, commands, and
  subagents.
  
  ## Migration strategy
  
  The migration is intentionally conservative: Codex only imports
  external-agent config that can be represented safely in Codex today.
  Unsupported or ambiguous config is skipped instead of being partially
  translated into behavior that may not match the source system.
  
  - **MCP servers**: import supported stdio and HTTP MCP server
  definitions into `mcp_servers`. Disabled servers and servers filtered
  out by source `enabledMcpjsonServers` / `disabledMcpjsonServers` are
  skipped. Project-scoped MCP entries from `.claude.json` are included
  when they match the repo path.
  - **Hooks**: import only supported command hooks into
  `.codex/hooks.json`. Unsupported hook features such as conditional
  groups, async handlers, prompt/http hooks, or unknown fields are
  skipped. Referenced hook scripts are copied into `.codex/hooks/`,
  preserving any existing target scripts.
  - **Commands**: import supported external commands as Codex skills under
  `.agents/skills/source-command-*`. Commands that rely on source runtime
  expansion such as `$ARGUMENTS`, `$1`, `@file` references, shell
  interpolation, or colliding generated names are skipped.
  - **Subagents**: import valid subagent Markdown files into
  `.codex/agents/*.toml` when they have the minimum Codex agent fields.
  Source model names are not migrated, so imported agents keep the user’s
  Codex default model; compatible reasoning effort and sandbox mode are
  migrated when present.
  - **Skills and project guidance**: copy missing skill directories into
  `.agents/skills` and migrate `CLAUDE.md` guidance into `AGENTS.md`,
  rewriting source-agent terminology to Codex terminology where
  appropriate.
  - **Detection details**: detected migration items include lightweight
  details for UI preview, such as MCP server names, hook event names,
  generated command skill names, and subagent names. Import still
  recomputes from disk instead of trusting details as the source of truth.
  
  - Adds focused coverage for the new migration behavior and app-server
  import flow.
  
  ## Verification
  
  - `cargo test -p codex-external-agent-migration`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server external_agent_config`
  - `just bazel-lock-check`

  alexsong-oai · 2026-04-29 00:45:24 +00:00
  cb8b1bbcd6
• app-server: notify clients of remote-control status changes (#19919)

  ## Why
  
  Remote-control app-server enrollments have both an internal server id
  and the environment id exposed to remote-control clients. App-server
  clients need one current status snapshot that says whether remote
  control is usable and which environment id, if any, is exposed.
  
  A temporary websocket disconnect is not itself an identity change.
  Account changes, stale enrollment invalidation, successful
  re-enrollment, and missing ChatGPT auth are meaningful status changes.
  Disabled remote control remains `disabled` regardless of auth or SQLite
  state. SQLite startup failure disablement and enrollment persistence
  failures are handled in #20068; this PR reports the resulting effective
  status to clients.
  
  ## What changed
  
  - Adds v2 `remoteControl/status/changed` carrying `state` and
  `environmentId`.
  - Adds `RemoteControlConnectionState` values: `disabled`, `connecting`,
  `connected`, and `errored`.
  - Exposes remote-control status updates through `RemoteControlHandle`
  using a Tokio watch channel.
  - Always sends the current remote-control status snapshot to newly
  initialized app-server clients.
  - Broadcasts status changes to initialized app-server clients when state
  or environment id changes.
  - Treats missing ChatGPT auth as an `errored` status while leaving it
  retryable because auth can change at runtime.
  - Clears `environmentId` when enrollment is cleared for account changes,
  auth loss, stale backend invalidation, or disabled remote control.
  - Updates app-server protocol schema fixtures, generated TypeScript,
  app-server README, remote-control tests, and TUI exhaustive notification
  matches.
  
  ## Stack
  
  - Builds on #20068.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server transport::remote_control --lib`
  - `cargo check -p codex-tui`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`

  Ruslan Nigmatullin · 2026-04-28 23:52:14 +00:00
  c6465c1ec2
• Discover hooks bundled with plugins (#19705)

  ## Why
  
  Plugins can bundle lifecycle hooks, but Codex previously only discovered
  hooks from user, project, and managed config layers. This adds the
  plugin discovery and runtime plumbing needed for plugin-bundled hooks
  while keeping execution behind the `plugin_hooks` feature flag.
  
  ## What
  
  - Discovers plugin hook sources from each plugin's default
  `hooks/hooks.json`.
  - Supports `plugin.json` manifest `hooks` entries as either relative
  paths or inline hook objects.
  - Plumbs discovered plugin hook sources through plugin loading into the
  hook runtime when `plugin_hooks` is enabled.
  - Marks plugin-originated hook runs as `HookSource::Plugin`.
  - Injects `PLUGIN_ROOT` and `CLAUDE_PLUGIN_ROOT` into plugin hook
  command environments.
  - Updates generated schemas and hook source metadata for the plugin hook
  source.
  
  ## Stack
  
  1. This PR - openai/codex#19705
  2. openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  - Core logic is in `codex-rs/core-plugins/src/loader.rs` and
  `codex-rs/hooks/src/engine/discovery.rs`
  - Moved existing / adding new tests to
  `codex-rs/core-plugins/src/loader_tests.rs` hence the large diff there
  - Otherwise mostly plumbing and minor schema updates
  
  ### Core Changes
  
  The `codex-rs/core` changes are limited to wiring plugin hook support
  into existing core flows:
  
  - `core/src/session/session.rs` conditionally pulls effective plugin
  hook sources and plugin hook load warnings from `PluginsManager` when
  `plugin_hooks` is enabled, then passes them into `HooksConfig`.
  - `core/src/hook_runtime.rs` adds the `plugin` metric tag for
  `HookSource::Plugin`.
  - `core/config.schema.json` picks up the new `plugin_hooks` feature
  flag, and `core/src/plugins/manager_tests.rs` updates fixtures for the
  added plugin hook fields.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-28 14:17:18 -07:00
  c6e7d564c3
• app-server: run initialized rpcs with keyed serialization (#17373)

  ## Why
  
  Initialized app-server RPCs no longer need to bottleneck behind one
  request processor path. Running them concurrently improves
  responsiveness, but several request families still mutate shared state
  or depend on ordered side effects. Those stateful families need an
  auditable serialization contract so concurrency does not reorder thread,
  config, auth, command, watcher, MCP, or similar state transitions.
  
  This PR keeps that boundary explicit: stateful work is serialized by the
  smallest useful key, while intentionally read-only or externally
  concurrent work remains unkeyed. In particular, `thread/list` and
  `thread/turns/list` explicitly have no serialization because they
  primarily read append-only rollout storage and should continue to be
  served concurrently.
  
  ## What changed
  
  - Adds `ClientRequest::serialization_scope()` in `app-server-protocol`
  and requires every client request definition to declare its
  serialization behavior.
  - Introduces keyed request scopes for thread, thread path, command exec
  process, fuzzy search session, fs watch, MCP OAuth, and global state
  buckets such as config, account auth, memory, and device keys.
  - Routes initialized app-server RPCs through per-key FIFO serialization
  while allowing unkeyed initialized requests to run concurrently.
  - Cancels in-flight initialized RPC work when the connection disconnects
  or the app-server exits so spawned request tasks do not outlive their
  session.
  - Adds focused coverage for representative keyed and unkeyed
  serialization scopes, including explicitly concurrent
  `thread/turns/list` behavior.
  
  ## Validation
  
  - Added protocol tests for representative keyed serialization scopes and
  intentionally unkeyed request families.
  - Added app-server request serialization tests covering per-key FIFO
  behavior, concurrent unkeyed execution, disconnect shutdown, and config
  read-after-write ordering.
  - Local focused protocol validation after the latest rebase is currently
  blocked by packageproxy failing to resolve locked `rustls-webpki
  0.103.13`; CI is expected to provide the full validation signal.

  Ruslan Nigmatullin · 2026-04-28 12:23:34 -07:00
  0700f979ba
• External agent session support (#19895)

  ## Summary
  
  This extends external agent detection/import beyond config artifacts so
  Codex can detect recent sessions files from the external agent home and
  import them into Codex rollout history.
  
  ## What changed
  
  - Added a focused `external_agent_sessions` module for:
    - session discovery
    - source-record parsing
    - rollout construction
    - import ledger tracking
  - Wired session detection/import into the app-server external agent
  config API.
  - Added compaction handling so large imported sessions can be resumed
  safely before the first follow-up turn.
  
  ## Testing
  
  Added coverage for:
  - recent-session detection
  - custom-title handling
  - recency filtering
  - dedupe and re-detect-after-source-change behavior
  - visible imported turn construction
  - backward-compatible import payload deserialization
  - end-to-end RPC import flow
  - rejection of undetected session paths
  - repeat-import behavior
  - large-session compaction before first follow-up
  
  Ran:
  - `cargo test -p codex-app-server external_agent_config_import_ --test
  all`

  stefanstokic-oai · 2026-04-28 17:42:36 +00:00
  4c68bd728f
• feat: split memories part 2 (#19860)

  Keep extracting memories out of core and moving the write trigger in the
  app-server
  This is temporary and it should move at the client level as a follow-up
  This makes core fully independant from `codex-memories-write`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-28 13:03:28 +02:00
  431ebeaef7
• Add remote plugin uninstall API (#19456)

  ## Summary
  - Adds the remote `plugin/uninstall` request form using required
  `pluginId` plus optional `remoteMarketplaceName`, while preserving local
  `pluginId` uninstall.
  - Adds `codex_core_plugins::remote::uninstall_remote_plugin` for the
  deployed ChatGPT plugin backend uninstall path and validates the backend
  returns the same id with `enabled: false`.
  - Routes app-server remote uninstall through feature checks, remote
  plugin id validation, backend mutation, local downloaded cache deletion,
  cache clearing, docs, and regenerated protocol schemas.
  
  ## Tests
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol
  plugin_uninstall_params_serialization_omits_force_remote_sync`
  - `cargo test -p codex-app-server plugin_uninstall --test all`
  - `cargo test -p codex-app-server plugin_uninstall`
  - `cargo build -p codex-cli`
  - `CODEX_BIN=/Users/xli/code/codex/codex-rs/target/debug/codex python3
  /Users/xli/.codex/skills/xli-test-marketplace-api/scripts/run_marketplace_api_matrix.py`
  (44 pass / 0 fail)
  - `just fix -p codex-app-server-protocol -p codex-app-server -p
  codex-tui`
  - `just fix -p codex-app-server`

  xli-oai · 2026-04-28 03:27:53 -07:00
  803705f795
• app-server-protocol: mark permission profiles experimental (#19899)

  ## Why
  
  `PermissionProfile` is now the canonical internal permissions
  representation, but the app-server wire shape is still intentionally
  unstable while the migration continues. Stable app-server clients should
  not see or generate code for these fields until the wire format settles.
  
  ## What changed
  
  - Marks every app-server v2 field that sends `PermissionProfile` as
  experimental, including `command/exec`, `thread/start`, `thread/resume`,
  `thread/fork`, and `turn/start` request/response payloads.
  - Enables per-field experimental inspection for `command/exec`, so
  `permissionProfile` is gated without making the entire method
  experimental.
  - Fixes the generated TypeScript schema filter to be comment-aware. The
  previous scanner treated apostrophes inside doc comments as string
  delimiters, so some experimental fields leaked into stable TypeScript
  even though stable JSON was filtered correctly.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19899).
  * #19900
  * __->__ #19899

  Michael Bolin · 2026-04-28 06:08:34 +00:00
  0a32c8b396
• permissions: remove cwd special path (#19841)

  ## Why
  
  The experimental `PermissionProfile` API had both `:cwd` and
  `:project_roots` special filesystem paths, which made the permission
  root ambiguous. This PR removes the unstable `current_working_directory`
  special path before the permissions API is stabilized, so callers use
  `:project_roots` for symbolic project-root access.
  
  ## What changed
  
  - Removes `FileSystemSpecialPath::CurrentWorkingDirectory` from protocol
  and app-server protocol models, plus regenerated app-server
  JSON/TypeScript schemas.
  - Replaces internal `:cwd` permission entries with `:project_roots`
  entries.
  - Keeps the existing cwd-update behavior for legacy-shaped
  workspace-write profiles, while removing the deleted
  `CurrentWorkingDirectory` case from that compatibility path.
  - Keeps `PermissionProfile::workspace_write()` as the reusable symbolic
  workspace-write helper, with docs noting that `:project_roots` entries
  resolve at enforcement time.
  - Updates app-server docs/examples and approval UI labeling to stop
  advertising `:cwd` as a permission token.
  
  ## Compatibility
  
  Persisted rollout items may contain the old
  `{"kind":"current_working_directory"}` tag from earlier experimental
  `permissionProfile` snapshots. This PR keeps that tag as a
  deserialize-only alias for `ProjectRoots { subpath: None }`, while
  continuing to serialize only the new `project_roots` tag.
  
  ## Follow-up
  
  This PR intentionally does not introduce an explicit project-root set on
  `SessionConfiguration` or runtime sandbox resolution. Today, the
  resolver still uses the active cwd as the single implicit project root.
  A follow-up should model project roots separately from tool cwd so
  `:project_roots` entries can resolve against the configured project
  roots, and resolve to no entries when there are no project roots.
  
  ## Verification
  
  - `cargo test -p codex-protocol permissions:: --lib`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-sandboxing -p codex-exec-server --lib`
  - `cargo test -p codex-core session_configuration_apply_ --lib`
  - `cargo test -p codex-app-server
  command_exec_permission_profile_project_roots_use_command_cwd --test
  all`
  - `cargo test -p codex-tui
  thread_read_session_state_does_not_reuse_primary_permission_profile
  --lib`
  - `cargo test -p codex-tui
  preset_matching_accepts_workspace_write_with_extra_roots --lib`
  - `cargo test -p codex-config --lib`

  Michael Bolin · 2026-04-27 13:41:27 -07:00
  4b55979755
• Delete unused ResponseItem::Message.end_turn (#19605)

  This field is unused. Delete it.

  Andrey Mishchenko · 2026-04-26 17:18:09 -07:00
  35bc6e3d01
• Add goal app-server API (2 / 5) (#18074)

  Adds the app-server v2 goal API on top of the persisted goal state from
  PR 1.
  
  ## Why
  
  Clients need a stable app-server surface for reading and controlling
  materialized thread goals before the model tools and TUI can use them.
  Goal changes also need to be observable by app-server clients, including
  clients that resume an existing thread.
  
  ## What changed
  
  - Added v2 `thread/goal/get`, `thread/goal/set`, and `thread/goal/clear`
  RPCs for materialized threads.
  - Added `thread/goal/updated` and `thread/goal/cleared` notifications so
  clients can keep local goal state in sync.
  - Added resume/snapshot wiring so reconnecting clients see the current
  goal state for a thread.
  - Added app-server handlers that reconcile persisted rollout state
  before direct goal mutations.
  - Updated the app-server README plus generated JSON and TypeScript
  schema fixtures for the new API surface.
  
  ## Verification
  
  - Added app-server v2 coverage for goal get/set/clear behavior,
  notification emission, resume snapshots, and non-local thread-store
  interactions.

  Eric Traut · 2026-04-24 20:53:41 -07:00
  6c874f9b34
• permissions: remove legacy read-only access modes (#19449)

  ## Why
  
  `ReadOnlyAccess` was a transitional legacy shape on `SandboxPolicy`:
  `FullAccess` meant the historical read-only/workspace-write modes could
  read the full filesystem, while `Restricted` tried to carry partial
  readable roots. The partial-read model now belongs in
  `FileSystemSandboxPolicy` and `PermissionProfile`, so keeping it on
  `SandboxPolicy` makes every legacy projection reintroduce lossy
  read-root bookkeeping and creates unnecessary noise in the rest of the
  permissions migration.
  
  This PR makes the legacy policy model narrower and explicit:
  `SandboxPolicy::ReadOnly` and `SandboxPolicy::WorkspaceWrite` represent
  the old full-read sandbox modes only. Split readable roots, deny-read
  globs, and platform-default/minimal read behavior stay in the runtime
  permissions model.
  
  ## What changed
  
  - Removes `ReadOnlyAccess` from
  `codex_protocol::protocol::SandboxPolicy`, including the generated
  `access` and `readOnlyAccess` API fields.
  - Updates legacy policy/profile conversions so restricted filesystem
  reads are represented only by `FileSystemSandboxPolicy` /
  `PermissionProfile` entries.
  - Keeps app-server v2 compatible with legacy `fullAccess` read-access
  payloads by accepting and ignoring that no-op shape, while rejecting
  legacy `restricted` read-access payloads instead of silently widening
  them to full-read legacy policies.
  - Carries Windows sandbox platform-default read behavior with an
  explicit override flag instead of depending on
  `ReadOnlyAccess::Restricted`.
  - Refreshes generated app-server schema/types and updates tests/docs for
  the simplified legacy policy shape.
  
  ## Verification
  
  - `cargo check -p codex-app-server-protocol --tests`
  - `cargo check -p codex-windows-sandbox --tests`
  - `cargo test -p codex-app-server-protocol sandbox_policy_`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19449).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19449

  Michael Bolin · 2026-04-24 17:16:58 -07:00
  789f387982
• permissions: make legacy profile conversion cwd-free (#19414)

  ## Why
  
  The profile conversion path still required a `cwd` even when it was only
  translating a legacy `SandboxPolicy` into a `PermissionProfile`. That
  made profile producers invent an ambient `cwd`, which is exactly the
  anchoring we are trying to remove from permission-profile data. A legacy
  workspace-write policy can be represented symbolically instead: `:cwd =
  write` plus read-only `:project_roots` metadata subpaths.
  
  This PR creates that cwd-free base so the rest of the stack can stop
  threading cwd through profile construction. Callers that actually need a
  concrete runtime filesystem policy for a specific cwd still have an
  explicitly named cwd-bound conversion.
  
  ## What Changed
  
  - `PermissionProfile::from_legacy_sandbox_policy` now takes only
  `&SandboxPolicy`.
  - `FileSystemSandboxPolicy::from_legacy_sandbox_policy` is now the
  symbolic, cwd-free projection for profiles.
  - The old concrete projection is retained as
  `FileSystemSandboxPolicy::from_legacy_sandbox_policy_for_cwd` for
  runtime/boundary code that must materialize legacy cwd behavior.
  - Workspace-write profiles preserve `CurrentWorkingDirectory` and
  `ProjectRoots` special entries instead of materializing cwd into
  absolute paths.
  
  ## Verification
  
  - `cargo check -p codex-protocol -p codex-core -p
  codex-app-server-protocol -p codex-app-server -p codex-exec -p
  codex-exec-server -p codex-tui -p codex-sandboxing -p
  codex-linux-sandbox -p codex-analytics --tests`
  - `just fix -p codex-protocol -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-exec -p codex-exec-server -p codex-tui -p
  codex-sandboxing -p codex-linux-sandbox -p codex-analytics`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19414).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19414

  Michael Bolin · 2026-04-24 13:42:05 -07:00
  13e0ec1614
• permissions: make profiles represent enforcement (#19231)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions abstraction,
  but the old shape only carried optional filesystem and network fields.
  It could describe allowed access, but not who is responsible for
  enforcing it. That made `DangerFullAccess` and `ExternalSandbox` lossy
  when profiles were exported, cached, or round-tripped through app-server
  APIs.
  
  The important model change is that active permissions are now a disjoint
  union over the enforcement mode. Conceptually:
  
  ```rust
  pub enum PermissionProfile {
      Managed {
          file_system: FileSystemSandboxPolicy,
          network: NetworkSandboxPolicy,
      },
      Disabled,
      External {
          network: NetworkSandboxPolicy,
      },
  }
  ```
  
  This distinction matters because `Disabled` means Codex should apply no
  outer sandbox at all, while `External` means filesystem isolation is
  owned by an outside caller. Those are not equivalent to a broad managed
  sandbox. For example, macOS cannot nest Seatbelt inside Seatbelt, so an
  inner sandbox may require the outer Codex layer to use no sandbox rather
  than a permissive one.
  
  ## How Existing Modeling Maps
  
  Legacy `SandboxPolicy` remains a boundary projection, but it now maps
  into the higher-fidelity profile model:
  
  - `ReadOnly` and `WorkspaceWrite` map to `PermissionProfile::Managed`
  with restricted filesystem entries plus the corresponding network
  policy.
  - `DangerFullAccess` maps to `PermissionProfile::Disabled`, preserving
  the “no outer sandbox” intent instead of treating it as a lax managed
  sandbox.
  - `ExternalSandbox { network_access }` maps to
  `PermissionProfile::External { network }`, preserving external
  filesystem enforcement while still carrying the active network policy.
  - Split runtime policies that legacy `SandboxPolicy` cannot faithfully
  express, such as managed unrestricted filesystem plus restricted
  network, stay `Managed` instead of being collapsed into
  `ExternalSandbox`.
  - Per-command/session/turn grants remain partial overlays via
  `AdditionalPermissionProfile`; full `PermissionProfile` is reserved for
  complete active runtime permissions.
  
  ## What Changed
  
  - Change active `PermissionProfile` into a tagged union: `managed`,
  `disabled`, and `external`.
  - Keep partial permission grants separate with
  `AdditionalPermissionProfile` for command/session/turn overlays.
  - Represent managed filesystem permissions as either `restricted`
  entries or `unrestricted`; `glob_scan_max_depth` is non-zero when
  present.
  - Preserve old rollout compatibility by accepting the pre-tagged `{
  network, file_system }` profile shape during deserialization.
  - Preserve fidelity for important edge cases: `DangerFullAccess`
  round-trips as `disabled`, `ExternalSandbox` round-trips as `external`,
  and managed unrestricted filesystem + restricted network stays managed
  instead of being mistaken for external enforcement.
  - Preserve configured deny-read entries and bounded glob scan depth when
  full profiles are projected back into runtime policies, including
  unrestricted replacements that now become `:root = write` plus deny
  entries.
  - Regenerate the experimental app-server v2 JSON/TypeScript schema and
  update the `command/exec` README example for the tagged
  `permissionProfile` shape.
  
  ## Compatibility
  
  Legacy `SandboxPolicy` remains available at config/API boundaries as the
  compatibility projection. Existing rollout lines with the old
  `PermissionProfile` shape continue to load. The app-server
  `permissionProfile` field is experimental, so its v2 wire shape is
  intentionally updated to match the higher-fidelity model.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo check --tests`
  - `cargo test -p codex-protocol permission_profile`
  - `cargo test -p codex-protocol
  preserving_deny_entries_keeps_unrestricted_policy_enforceable`
  - `cargo test -p codex-app-server-protocol
  permission_profile_file_system_permissions`
  - `cargo test -p codex-app-server-protocol serialize_client_response`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox`
  - `just fix`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  Michael Bolin · 2026-04-23 23:02:18 -07:00
  4816b89204
• Add sticky environment API and thread state (#18897)

  ## Summary
  - add sticky environment selections to app-server v2 thread/start and
  turn/start request flow
  - carry thread-level selections through core session/thread state
  - add app-server coverage for sticky selections and turn overrides
  
  ## Stack
  1. This PR: API and thread persistence
  2. #18898: config.toml named environment loading
  3. #18899: downstream tool/runtime consumers
  
  ## Validation
  - Not run locally; split only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-23 18:57:13 -07:00
  49fb25997f
• feat: expose AWS account state from account/read (#19048)

  ## Why
  
  AWS/Bedrock mode currently reports `account: null` with
  `requiresOpenaiAuth: false` from `account/read`. That suppresses the
  OpenAI-auth requirement, but it does not let app clients distinguish AWS
  auth from any other non-OpenAI custom provider. For the prototype AWS
  provider UX, clients need a simple provider-derived signal so they can
  suppress ChatGPT/API-key login and token-refresh paths without
  hardcoding Bedrock checks.
  
  ## What changed
  
  - Adds an `aws` variant to the v2 `Account` protocol union.
  - Adds `ProviderAccountKind` to `codex-model-provider` so the runtime
  provider owns the app-visible account classification.
  - Makes Amazon Bedrock return `ProviderAccountKind::Aws` from the
  model-provider layer.
  - Updates app-server `account/read` to map `ProviderAccountKind` to the
  existing `GetAccountResponse` wire shape.
  - Preserves the existing `account: null, requiresOpenaiAuth: false`
  behavior for other non-OpenAI providers.
  - Regenerates the app-server protocol schema fixtures.
  - Adds coverage for provider account classification and for the Amazon
  Bedrock `account/read` response.
  
  ## Testing
  
  - `cargo test -p codex-model-provider`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server get_account_with_aws_provider`
  
  ## Notes
  
  I attempted `just bazel-lock-update` and `just bazel-lock-check`, but
  both are blocked in my local environment because `bazel` is not
  installed.

  Celia Chen · 2026-04-24 01:53:13 +00:00
  432771c5fd
• Add app-server marketplace upgrade RPC (#19074)

  ## Summary
  - add a v2 `marketplace/upgrade` app-server RPC that mirrors the
  existing configured Git marketplace upgrade path
  - expose typed request/response/error payloads and regenerate
  JSON/TypeScript schema fixtures
  - add app-server integration coverage for all, named, already
  up-to-date, and invalid marketplace upgrade requests
  
  ## Tests
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server marketplace_upgrade`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fmt`

  xli-oai · 2026-04-23 13:00:46 -07:00
  0d6a90cd6b
• Add excludeTurns parameter to thread/resume and thread/fork (#19014)

  For callers who expect to be paginating the results for the UI, they can
  now call thread/resume or thread/fork with excludeturns:true so it will
  not fetch any pages of turns, and instead only set up the subscription.
  That call can be immediately followed by pagination requests to
  thread/turns/list to fetch pages of turns according to the UI's current
  interactions.

  David de Regt · 2026-04-23 10:07:59 -07:00
  3d3028a5a9
• Fix auto-review config compatibility across protocol and SDK (#19113)

  ## Why
  
  This keeps the partial Guardian subagent -> Auto-review rename
  forward-compatible across mixed Codex installations. Newer binaries need
  to understand the new `auto_review` spelling, but they cannot write it
  to shared `~/.codex/config.toml` yet because older CLI/app-server
  bundles only know `user` and `guardian_subagent` and can fail during
  config load before recovering.
  
  The Python SDK had the opposite compatibility gap: app-server responses
  can contain `approvalsReviewer: "auto_review"`, but the checked-in
  generated SDK enum did not accept that value.
  
  ## What Changed
  
  - Keep `ApprovalsReviewer::AutoReview` readable from both
  `guardian_subagent` and `auto_review`, while serializing it as
  `guardian_subagent` in both protocol crates.
  - Update TUI Auto-review persistence tests so enabling Auto-review
  writes `approvals_reviewer = "guardian_subagent"` while UI copy still
  says Auto-review.
  - Map managed/cloud `feature_requirements.auto_review` to the existing
  `Feature::GuardianApproval` gate without adding a broad local
  `[features].auto_review` key or changing config writes.
  - Add `auto_review` to the Python SDK `ApprovalsReviewer` enum and cover
  `ThreadResumeResponse` validation.
  
  ## Testing
  
  - `cargo test -p codex-protocol approvals_reviewer`
  - `cargo test -p codex-app-server-protocol approvals_reviewer`
  - `cargo test -p codex-tui
  update_feature_flags_enabling_guardian_selects_auto_review`
  - `cargo test -p codex-tui
  update_feature_flags_enabling_guardian_in_profile_sets_profile_auto_review_policy`
  - `cargo test -p codex-core
  feature_requirements_auto_review_disables_guardian_approval`
  - `pytest
  sdk/python/tests/test_client_rpc_methods.py::test_thread_resume_response_accepts_auto_review_reviewer`
  - `git diff --check`

  Won Park · 2026-04-23 03:12:56 -07:00
  17ae906048
• app-server: include filesystem entries in permission requests (#19086)

  ## Why
  
  `item/permissions/requestApproval` sends a requested permission profile
  to app-server clients. The core profile already stores filesystem
  permissions as `entries`, but the v2 compatibility conversion used the
  legacy `read`/`write` projection whenever possible and left `entries`
  unset.
  
  That made the request ambiguous for clients that consume the canonical
  v2 shape: `permissions.fileSystem.entries` was missing even though
  filesystem access was being requested. A client that rendered or echoed
  grants from `entries` could treat the request as having no filesystem
  permission entries, then return an empty or incomplete grant. The
  app-server intersects responses with the original request, so omitted
  filesystem permissions are denied.
  
  ## What Changed
  
  - Populate `AdditionalFileSystemPermissions.entries` when converting
  legacy read/write roots for request permission payloads, while
  preserving `read` and `write` for compatibility.
  - Mark `read` and `write` as transitional schema fields in the generated
  app-server schema.
  - Add regression coverage for the v2 conversion, the app-server
  `item/permissions/requestApproval` round trip, and TUI app-server
  approval conversion expectations.
  - Refresh generated JSON and TypeScript schema fixtures.
  
  ## Verification
  
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server request_permissions_round_trip`
  - `cargo test -p codex-tui
  converts_request_permissions_into_granted_permissions`
  - `cargo test -p codex-tui
  resolves_permissions_and_user_input_through_app_server_request_id`

  Michael Bolin · 2026-04-23 00:21:59 -07:00
  8bc667b07b
• app-server: accept command permission profiles (#18283)

  ## Why
  
  `command/exec` is another app-server entry point that can run under
  caller-provided permissions. It needs to accept `PermissionProfile`
  directly so command execution is not left behind on `SandboxPolicy`
  while thread APIs move forward.
  
  Command-level profiles also need to preserve the semantics clients
  expect from profile-relative paths. `:cwd` and cwd-relative deny globs
  should be anchored to the resolved command cwd for a command-specific
  profile, while configured deny-read restrictions such as `**/*.env =
  none` still need to be enforced because they can come from config or
  requirements rather than the command override itself.
  
  ## What Changed
  
  This adds `permissionProfile` to `CommandExecParams`, rejects requests
  that combine it with `sandboxPolicy`, and converts accepted profiles
  into the runtime filesystem/network permissions used for command
  execution.
  
  When a command supplies a profile, the app-server resolves that profile
  against the command cwd instead of the thread/server cwd. It also
  preserves configured deny-read entries and `globScanMaxDepth` on the
  effective filesystem policy so one-off command overrides cannot drop
  those read protections. The PR also updates app-server docs/schema
  fixtures and adds command-exec coverage for accepted, rejected,
  cwd-scoped, and deny-read-preserving profile paths.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  command_exec_permission_profile_cwd_uses_command_cwd`
  - `cargo test -p codex-app-server
  command_profile_preserves_configured_deny_read_restrictions`
  - `cargo test -p codex-app-server
  command_exec_accepts_permission_profile`
  - `cargo test -p codex-app-server
  command_exec_rejects_sandbox_policy_with_permission_profile`
  - `just fix -p codex-app-server`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18283).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * __->__ #18283

  Michael Bolin · 2026-04-22 22:33:16 -07:00
  9d824cf4b4
• Add safety check notification and error handling (#19055)

  Adds a new app-server notification that fires when a user account has
  been flagged for potential safety reasons.

  Eric Traut · 2026-04-22 22:24:12 -07:00
  bbff4ee61a
• codex: support hooks in config.toml and requirements.toml (#18893)

  ## Summary
  
  Support the existing hooks schema in inline TOML so hooks can be
  configured from both `config.toml` and enterprise-managed
  `requirements.toml` without requiring a separate `hooks.json` payload.
  
  This gives enterprise admins a way to ship managed hook policy through
  the existing requirements channel while still leaving script delivery to
  MDM or other device-management tooling, and it keeps `hooks.json`
  working unchanged for existing users.
  
  This also lays the groundwork for follow-on managed filtering work such
  as #15937, while continuing to respect project trust gating from #14718.
  It does **not** implement `allow_managed_hooks_only` itself.
  
  NOTE: yes, it's a bit unfortunate that the toml isn't formatted as
  closely as normal to our default styling. This is because we're trying
  to stay compatible with the spec for plugins/hooks that we'll need to
  support & the main usecase here is embedding into requirements.toml
  
  ## What changed
  
  - moved the shared hook serde model out of `codex-rs/hooks` into
  `codex-rs/config` so the same schema can power `hooks.json`, inline
  `config.toml` hooks, and managed `requirements.toml` hooks
  - added `hooks` support to both `ConfigToml` and
  `ConfigRequirementsToml`, including requirements-side `managed_dir` /
  `windows_managed_dir`
  - treated requirements-managed hooks as one constrained value via
  `Constrained`, so managed hook policy is merged atomically and cannot
  drift across requirement sources
  - updated hook discovery to load requirements-managed hooks first, then
  per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning
  when a single layer defines both representations
  - threaded managed hook metadata through discovered handlers and exposed
  requirements hooks in app-server responses, generated schemas, and
  `/debug-config`
  - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`,
  `codex-rs/core/src/config_loader/tests.rs`, and
  `codex-rs/core/tests/suite/hooks.rs`
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server config_api`
  
  ## Documentation
  
  Companion updates are needed in the developers website repo for:
  
  - the hooks guide
  - the config reference, sample, basic, and advanced pages
  - the enterprise managed configuration guide
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Andrei Eternal · 2026-04-22 21:20:09 -07:00
  2b2de3f38b
• feat(request-permissions) approve with strict review (#19050)

  ## Summary
  Allow the user to approve a request_permissions_tool request with the
  condition that all commands in the rest of the turn are reviewed by
  guardian, regardless of sandbox status.
  
  ## Testing
  - [x] Added unit tests
  - [x] Ran locally

  Dylan Hurd · 2026-04-23 01:56:32 +00:00
  5e71da1424
• Rename approvals reviewer variant to auto-review (#19056)

  ## Why
  
  `approvals_reviewer` now uses `auto_review` as the canonical config/API
  value after #18504, but the Rust enum variant and nearby helper/test
  names still used `GuardianSubagent` / guardian approval wording. That
  made follow-up code and reviews confusing even though the external value
  had already moved to Auto-review.
  
  ## What changed
  
  - Renamed `ApprovalsReviewer::GuardianSubagent` to
  `ApprovalsReviewer::AutoReview`.
  - Updated protocol, app-server, config, core, TUI, exec, and analytics
  test callsites.
  - Renamed nearby helper/test names from guardian approval wording to
  Auto-review wording where they refer to the approvals reviewer mode.
  - Preserved wire compatibility:
    - `auto_review` remains the canonical serialized value.
    - `guardian_subagent` remains accepted as a legacy alias.
  
  This intentionally does not rename the `[features].guardian_approval`
  key, `Feature::GuardianApproval`, `core/src/guardian`, analytics event
  names, or app-server Guardian review event types.
  
  ## Verification
  
  - `cargo test -p codex-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
  - `cargo test -p codex-app-server-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
  - `cargo test -p codex-config approvals_reviewer`
  - `cargo test -p codex-tui update_feature_flags`
  - `cargo test -p codex-core permissions_instructions`
  - `cargo test -p codex-tui permissions_selection`

  Won Park · 2026-04-22 17:22:35 -07:00
  83ec1eb5d6
• Rebrand approvals reviewer config to auto-review (#18504)

  ### Why
  
  Auto-review is the user-facing name for the approvals reviewer, but the
  config/API value still exposed the old `guardian_subagent` name. That
  made new configs and generated schemas point users at Guardian
  terminology even though the intended product surface is Auto-review.
  
  This PR updates the external `approvals_reviewer` value while preserving
  compatibility for existing configs and clients.
  
  ### What changed
  
  - Makes `auto_review` the canonical serialized value for
  `approvals_reviewer`.
  - Keeps `guardian_subagent` accepted as a legacy alias.
  - Keeps `user` accepted and serialized as `user`.
  - Updates generated config and app-server schemas so
  `approvals_reviewer` includes:
    - `user`
    - `auto_review`
    - `guardian_subagent`
  - Updates app-server README docs for the reviewer value.
  - Updates analytics and config requirements tests for the canonical
  auto_review value.
  
  
  ### Compatibility
  
  Existing configs and API payloads using:
  
  ```toml
  approvals_reviewer = "guardian_subagent"
  ```
  
  continue to load and map to the Auto-review reviewer behavior. 
  
  New serialization emits: 
  ```toml
  approvals_reviewer = "auto_review" 
  ```
  
  This PR intentionally does not rename the [features].guardian_approval
  key or broad internal Guardian symbols. Those are split out for a
  follow-up PR to keep this migration small and avoid touching large
  TUI/internal surfaces.
  
  **Verification**
  cargo test -p codex-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent
  cargo test -p codex-app-server-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent

  Won Park · 2026-04-22 15:45:35 -07:00
  46142c3cb0
• app-server: accept permission profile overrides (#18279)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions shape shared
  by core and app-server. After app-server responses expose the active
  profile, clients need to be able to send that same shape back when
  starting, resuming, forking, or overriding a turn instead of translating
  through the legacy `sandbox`/`sandboxPolicy` shorthands.
  
  This still needs to preserve the existing requirements/platform
  enforcement model. A profile-shaped request can be downgraded or
  rejected by constraints, but the server should keep the user's
  elevated-access intent for project trust decisions. Turn-level profile
  overrides also need to retain existing read protections, including
  deny-read entries and bounded glob-scan metadata, so a permission
  override cannot accidentally drop configured protections such as
  `**/*.env = deny`.
  
  ## What changed
  
  - Adds optional `permissionProfile` request fields to `thread/start`,
  `thread/resume`, `thread/fork`, and `turn/start`.
  - Rejects ambiguous requests that specify both `permissionProfile` and
  the legacy `sandbox`/`sandboxPolicy` fields, including running-thread
  resume requests.
  - Converts profile-shaped overrides into core runtime filesystem/network
  permissions while continuing to derive the constrained legacy sandbox
  projection used by existing execution paths.
  - Preserves project-trust intent for profile overrides that are
  equivalent to workspace-write or full-access sandbox requests.
  - Preserves existing deny-read entries and `globScanMaxDepth` when
  applying turn-level `permissionProfile` overrides.
  - Updates app-server docs plus generated JSON/TypeScript schema fixtures
  and regression coverage.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol schema_fixtures`
  - `cargo test -p codex-core
  session_configuration_apply_permission_profile_preserves_existing_deny_read_entries`
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18279).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * #18282
  * #18281
  * #18280
  * __->__ #18279

  Michael Bolin · 2026-04-22 13:34:33 -07:00
  18a26d7bbc
• feat(auto-review) short-circuit (#18890)

  ## Summary
  Short circuit the convo if auto-review hits too many denials
  
  ## Testing
  - [x] Added unit tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-04-22 20:34:15 +00:00
  ed4def8286
• Add plumbing to approve stored Auto-Review denials (#18955)

  ## Summary
  
  This adds the structural plumbing needed for an app-server client to
  approve a previously denied Guardian review and carry that approval
  context into the next model turn.
  
  This PR does not add the actual `/auto-review-denials` tool 
  
  ## What Changed
  
  - Added app-server v2 RPC `thread/approveGuardianDeniedAction`.
  - Added generated JSON schema and TypeScript fixtures for
  `ThreadApproveGuardianDeniedAction*`.
  - Added core `Op::ApproveGuardianDeniedAction`.
  - Added a core handler that validates the event is a denied Guardian
  assessment and injects a developer message containing the stored denial
  event JSON.
  - Queues the approval context for the next turn if there is no active
  turn yet.
  - Added the TUI app-server bridge so `Op::ApproveGuardianDeniedAction {
  event }` is routed to the app-server request.
  
  ## What This Does Not Do
  
  - Does not add `/auto-review-denials`.
  - Does not add chat widget recent-denial state.
  - Does not add popup/list UI.
  - Does not add a product-facing denial lookup/store.
  - Does not change where Guardian denials are originally emitted or
  persisted.
  
  ## Verification
  
  - `cargo test -p codex-tui thread_approve_guardian_denied_action`

  Won Park · 2026-04-22 10:38:19 -07:00
  11e5af53c4
• Support multiple cwd filters for thread list (#18502)

  ## Summary
  
  - Teach app-server `thread/list` to accept either a single `cwd` or an
  array of cwd filters, returning threads whose recorded session cwd
  matches any requested path
  - Add `useStateDbOnly` as an explicit opt-in fast path for callers that
  want to answer `thread/list` from SQLite without scanning JSONL rollout
  files
  - Preserve backwards compatibility: by default, `thread/list` still
  scans JSONL rollouts and repairs SQLite state
  - Wire the new cwd array and SQLite-only options through app-server,
  local/remote thread-store, rollout listing, generated TypeScript/schema
  fixtures, proto output, and docs
  
  ## Test Plan
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-rollout`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-app-server thread_list`
  - `just fmt`
  - `just fix -p codex-app-server-protocol -p codex-rollout -p
  codex-thread-store -p codex-app-server`
  - `cargo build -p codex-cli --bin codex`

  acrognale-oai · 2026-04-22 06:10:09 -04:00
  4f8c58f737