953 Commits

• Import external agent sessions in background (#20284)

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

  stefanstokic-oai · 2026-04-30 00:00:41 +00:00
  c8abcbf925
• Consume ai-title from external sessions and add end marker (#20261)

  ## Summary
  - Support Claude Code `ai-title` / `aiTitle` records when detecting and
  importing external agent sessions.
  - Preserve existing `custom-title` / `customTitle` precedence; only fall
  back to `aiTitle` when no custom title is present.
  - Add coverage for both detection and import title selection, including
  the custom-title-over-ai-title case.
  
  ## Testing
  - `cargo test -p codex-external-agent-sessions`
  - `just fix -p codex-external-agent-sessions`

  alexsong-oai · 2026-04-30 00:00:13 +00:00
  7bcd4626c4
• 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
• [mcp] Fix plugin MCP approval policy. (#19537)

  Plugin MCP servers are loaded from plugin manifests rather than
  top-level `[mcp_servers]`, so their tool approval preferences need to be
  stored and applied through the owning plugin config. Without this,
  choosing "Always allow" for a plugin MCP tool could write a preference
  that was not reliably used on later tool calls.
  
  ## Summary
  - Add plugin-scoped MCP policy config under
  `plugins.<plugin>.mcp_servers`, including server enablement, tool
  allow/deny lists, server defaults, and per-tool approval modes.
  - Overlay plugin MCP policy onto manifest-provided server configs when
  plugins are loaded.
  - Route persistent "Always allow" writes for plugin MCP tools back to
  the owning `plugins.<plugin>.mcp_servers.<server>.tools.<tool>` config
  entry.
  - Reload user config after persisting an approval and make the plugin
  load cache config-aware so stale plugin MCP policy is not reused after
  `config.toml` changes.
  - Regenerate the config schema and add coverage for plugin MCP policy
  loading, approval lookup, persistence, and stale-cache prevention.
  
  ## Testing
  - `cargo test -p codex-config`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-core --lib plugin_mcp`

  Matthew Zeng · 2026-04-29 15:40:03 -07:00
  e20391e567
• [app-server] centralize client response analytics (#20059)

  ## Why
  
  The precursor PR keeps successful client responses typed until
  app-server's outgoing response seam. This follow-up uses that seam to
  move successful client-response analytics out of individual handlers and
  into the shared sender path, while keeping filtering decisions inside
  `codex-analytics`.
  
  ## What changed
  
  - Emit successful client-response analytics centrally from
  `OutgoingMessageSender::send_response`.
  - Remove duplicate handler-local response tracking for the current
  thread/turn lifecycle responses.
  - Keep analytics ingestion selective inside `AnalyticsEventsClient`, so
  unrelated client traffic is ignored before cloning or boxing.
  - Collapse client-response analytics facts onto one typed path and
  normalize payloads in the reducer.
  - Add direct client-filter coverage plus sender-level coverage for the
  centralized forwarding path.
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-app-server outgoing_message::tests --lib`

  rhan-oai · 2026-04-29 21:22:39 +00:00
  72a39e3a96
• Require remote plugin detail before uninstall (#19966)

  ## Summary
  - Fetch remote plugin detail before sending the uninstall request.
  - Use the detail response to derive the marketplace namespace and plugin
  name for cache cleanup.
  - Stop the uninstall before the backend POST if detail lookup fails, so
  backend state and local cache state do not diverge.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-app-server plugin_uninstall`
  - `cargo test -p codex-core-plugins`
  - `git diff --check`

  xli-oai · 2026-04-29 14:01:11 -07:00
  afbddabc8b
• [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
• app-server: fix outgoing sender test setup (#20258)

  ## Why
  
  [#17088](https://github.com/openai/codex/pull/17088) changed
  `OutgoingMessageSender::new` to require an `AnalyticsEventsClient`, but
  one `command_exec` test added earlier on `main` still called the old
  one-argument constructor. That leaves current `main` failing to compile
  in Bazel and argument-comment-lint jobs.
  
  ## What changed
  
  - Pass `AnalyticsEventsClient::disabled()` to the missed
  `OutgoingMessageSender::new` test call site in `command_exec.rs`.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  timeout_or_cancellation_reports_cancellation_without_timeout_exit_code`

  sayan-oai · 2026-04-29 20:47:20 +00:00
  b15074d0a4
• [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
• fix: handle deferred network proxy denials (#19184)

  ## Why
  
  This bug is exposed by Guardian/auto-review approvals. With the managed
  network proxy enabled, a blocked network request can be reported back
  through the network approval service as an approval denial after the
  command has already started. Before this change, the shell and unified
  exec runtimes registered those network approval calls, but did not have
  a way to observe an async proxy denial as a cancellation/failure signal
  for the running process.
  
  The result was confusing: Guardian/auto-review could correctly deny
  network access, but the command path could keep running or unregister
  the approval without surfacing the denial as the command failure.
  
  ## What Changed
  
  - `NetworkApprovalService` now attaches a cancellation token to active
  and deferred network approvals.
  - Proxy-denial outcomes are recorded only for active registrations,
  cancel the owning token, and are consumed when the approval is
  finalized.
  - The shell runtime combines the normal command timeout with the
  network-denial cancellation token.
  - Unified exec stores the deferred network approval object, terminates
  tracked processes when the proxy denial arrives, and returns the denial
  as a process failure while polling or completing the process.
  - Tool orchestration passes the active network approval cancellation
  token into the sandbox attempt and preserves deferred approval errors
  instead of silently unregistering them.
  - App-server `command/exec` now handles the combined
  timeout-or-cancellation expiration variant used by the runtime.
  
  ## Verification
  
  - `cargo test -p codex-core network_approval --lib`
  - `cargo clippy -p codex-app-server --all-targets -- -D warnings`
  - `cargo clippy -p codex-core --all-targets -- -D warnings`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-29 19:13:57 +00:00
  07c8b8c77c
• feat: Use remote installed plugin cache for skills and MCP (#20096)

  - Fetches and caches remote /installed plugin state
  - Lets skills/list load skills from remote-installed cached plugins
  without requiring a local marketplace entry
  - Routes plugin list/startup/install/uninstall changes through async
  plugin cache invalidation and MCP refresh

  xl-openai · 2026-04-29 12:09:49 -07:00
  73cd831952
• Include auto-review rollout in feedback uploads (#20064)

  ## Summary
  
  - include the live auto-review trunk rollout when `/feedback` uploads
  logs
  - upload that attachment as
  `auto-review-rollout-<parent-thread-id>.jsonl` so it is distinguishable
  from the parent rollout
  - show the same auto-review attachment name in the TUI consent popup
  
  ## Scope
  
  - this only covers the live cached auto-review trunk for the current
  parent thread
  - it does not add durable historical parent->auto-review lookup
  - it does not add persisted rollout support for ephemeral parallel
  review forks
  
  ## UI 
  
  <img width="599" height="185" alt="Screenshot 2026-04-28 at 1 17 18 PM"
  src="https://github.com/user-attachments/assets/6a0e79c2-5d21-4702-8a89-f765778bc9e9"
  />
  
  ## Validation
  
  - `cargo test -p codex-core
  cached_guardian_subagent_exposes_its_rollout_path`
  - `cargo test -p codex-feedback`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-tui feedback_upload_consent_popup_snapshot`
  - `cargo test -p codex-tui
  feedback_good_result_consent_popup_includes_connectivity_diagnostics_filename`
  
  ## Known unrelated local failures
  
  - `cargo test -p codex-core` currently fails in the pre-existing proxy
  env snapshot test
  `tools::runtimes::tests::maybe_wrap_shell_lc_with_snapshot_keeps_user_proxy_env_when_proxy_inactive`
  - `cargo test -p codex-tui` currently hits pre-existing `status::*`
  snapshot drift unrelated to this change
  
  ## Follow-Up 
  - persist parallel auto-review fork sessions so /feedback can include
  their rollout history too
  - attach each persisted fork as its own clearly named file, for example
  auto-review-rollout-<parent-thread-id>-fork <n>.jsonl, instead of
  merging multiple Guardian sessions into one attachment
  - keep the same live-session-only scope initially; durable historical
  parent -> auto-review lookup can remain a separate decision if we later
  need feedback from resumed sessions

  Won Park · 2026-04-29 11:44:55 -07:00
  5cf0adba93
• Add ThreadManager sample crate (#20141)

  Summary:
  - Add codex-thread-manager-sample, a one-shot binary that starts a
  ThreadManager thread, submits a prompt, and prints the final assistant
  output.
  - Pass ThreadStore into ThreadManager::new and expose
  thread_store_from_config for existing callsites.
  - Build the sample Config directly with only --model and prompt inputs.
  
  Verification:
  - just fmt
  - cargo check -p codex-thread-manager-sample -p codex-app-server -p
  codex-mcp-server
  - git diff --check
  
  Tests: Not run per request.

  pakrym-oai · 2026-04-29 11:21:06 -07:00
  8356806fc9
• Fix migrated hook path rewriting (#20144)

  ## Summary
  - Rewrite migrated external-agent hook commands by replacing the full
  hook script path token instead of only the `.claude/hooks/` segment.
  - Preserve quoting around the full rewritten target path so script names
  with spaces, absolute paths, and shell operators/redirection continue to
  work.
  - Apply `.claude/settings.local.json` over `.claude/settings.json` for
  config, MCP, and plugin migration so local scope matches Claude settings
  precedence.
  - Skip legacy command markdown without `description` frontmatter,
  including README-style docs under `.claude/commands`.
  
  ## Root Cause
  The previous hook rewrite handled `.claude/hooks/` as a substring
  replacement. For absolute source commands, that left the original
  project-root prefix before the newly quoted `.codex/hooks` directory,
  producing invalid commands like
  `project/'project/.codex/hooks'/script.sh`.
  
  The migration also only used project `settings.json` for
  config/MCP/plugin decisions, so local settings such as
  `disabledMcpjsonServers` could be ignored even though Claude gives local
  settings higher precedence than project settings.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-external-agent-migration`
  - `cargo test -p codex-app-server external_agent_config`
  - `just fix -p codex-external-agent-migration`
  - `just fix -p codex-app-server`
  - `git diff --check`

  alexsong-oai · 2026-04-29 00:46:11 -07:00
  d92c909ee4
• Add environment provider snapshot (#20058)

  ## Summary
  - Change `EnvironmentProvider` to return concrete `Environment`
  instances instead of `EnvironmentConfigurations`.
  - Make `DefaultEnvironmentProvider` provide the provider-visible `local`
  environment plus optional `remote` environment from
  `CODEX_EXEC_SERVER_URL`.
  - Keep `EnvironmentManager` as the concrete cache while exposing its own
  explicit local environment for `local_environment()` fallback paths.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-28 20:05:18 -07:00
  e1ec9e63a0
• Soften skill description budget warnings (#20112)

  Updates skill description budget messaging to be less alarming

  xl-openai · 2026-04-28 19:56:25 -07:00
  6f328d5e02
• 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
• Fix plugin list workspace settings test isolation (#20086)

  Fixes test that often fails locally when running `cargo test`
  - Add an app-server test helper that combines managed-config isolation
  with custom env overrides.
  - Isolate `HOME` / `USERPROFILE` in plugin-list workspace settings tests
  so host home marketplaces do not affect results.

  canvrno-oai · 2026-04-28 18:34:38 -07:00
  4c39ad33cb
• 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
• Return None when auth refresh fails (#20092)

  Right now, if Codex winds up in a state with auth but it can't refresh
  the token, the user is left with an unhelpful message that says to log
  out and log back in again.
  
  Ultimately, we should prevent that from happening but if it does,
  returning None will allow the caller to redirect the user back to the
  login page

  Gabriel Peal · 2026-04-28 16:15:47 -07:00
  5e6cbbadf7
• app-server: disable remote control without sqlite (#20068)

  ## Why
  
  Remote control depends on the app-server SQLite state DB for persisted
  enrollment identity. If the state DB cannot be opened at startup,
  continuing with remote control enabled leaves the process in a
  misleading state where enrollment identity cannot be read or persisted.
  
  Feature-disabled remote control remains disabled regardless of SQLite
  state. This only changes the case where remote control is requested but
  the SQLite state DB is unavailable.
  
  ## What changed
  
  - Logs SQLite state DB initialization failures instead of dropping the
  error silently.
  - Treats remote control as effectively disabled when the SQLite state DB
  is unavailable.
  - Prevents `RemoteControlHandle::set_enabled(true)` from enabling remote
  control later in the same process if the state DB was unavailable at
  startup.
  - Keeps the existing behavior that disabled remote control does not
  validate or connect to the remote-control URL.
  - Makes persisted enrollment load/update failures propagate as
  remote-control errors instead of silently falling back to in-memory
  state.
  - Makes the direct websocket connection path fail when called without a
  SQLite state DB.
  - Adds coverage for startup without a state DB, later handle enablement
  with no state DB, and direct websocket connection without a state DB.
  
  ## Verification
  
  - `cargo test -p codex-app-server transport::remote_control --lib`
  - `just fix -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-28 13:49:00 -07:00
  10e2a73b3c
• app-server: allow remote_control runtime feature override (#20047)
  Ruslan Nigmatullin · 2026-04-28 13:36:12 -07:00
  1de7a9bf69
• 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: trigger memories from user turns with cooldown (#19970)

  ## Why
  
  Memory startup was tied to thread lifecycle events such as create, load,
  and fork. That can run memory work before a thread receives real user
  input, and it makes startup cost scale with thread management instead of
  actual turns. Moving the trigger to `thread/sendInput` keeps memory
  startup aligned with the first real user turn and lets it use the
  current thread config at turn time.
  
  The idea is to prevent ghost cost due to pre-warm triggered by the app
  
  Turn-based startup can also make global phase-2 consolidation easier to
  request repeatedly, so this adds a success cooldown and tightens the
  default startup scan window.
  
  ## What Changed
  
  - Start `codex_memories_write::start_memories_startup_task` after a
  non-empty `thread/sendInput` turn is submitted, instead of from thread
  create/load/fork paths:
  https://github.com/openai/codex/blob/d4a6885b7829e2fd2ec7a09355e4f75ebe1d1fe3/codex-rs/app-server/src/codex_message_processor.rs#L6477-L6487
  - Expose `CodexThread::config()` so app-server can pass the live config
  into memory startup at turn time.
  - Add a six-hour successful-run cooldown for global phase-2
  consolidation via `SkippedCooldown`:
  https://github.com/openai/codex/blob/d4a6885b7829e2fd2ec7a09355e4f75ebe1d1fe3/codex-rs/state/src/runtime/memories.rs#L963-L966
  - Reduce memory startup defaults to at most 2 rollouts over 10 days:
  https://github.com/openai/codex/blob/d4a6885b7829e2fd2ec7a09355e4f75ebe1d1fe3/codex-rs/config/src/types.rs#L31-L34
  
  ## Verification
  
  Updated the memory runtime coverage around phase-2 reclaim behavior,
  including `phase2_global_lock_respects_success_cooldown`.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-28 16:23:13 +02:00
  a9e5c34083
• 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
• feat: Cache remote plugin bundles on install (#19914)

  Remote installs now fetch, validate, download, and cache the plugin
  bundle locally

  xl-openai · 2026-04-28 00:53:27 -07:00
  7d72fc8f53
• permissions: derive snapshot sandbox projections (#19775)

  ## Why
  
  `ThreadConfigSnapshot` is used by app-server and thread metadata code as
  a stable view of active runtime settings. Keeping both `sandbox_policy`
  and `permission_profile` in the snapshot duplicates permission state and
  makes it possible for the legacy projection to drift from the canonical
  profile.
  
  The legacy `sandbox` value is still needed at app-server compatibility
  boundaries, so this PR derives it on demand from the snapshot profile
  and cwd instead of storing it.
  
  ## What Changed
  
  - Removes `ThreadConfigSnapshot.sandbox_policy`.
  - Adds `ThreadConfigSnapshot::sandbox_policy()` as a compatibility
  projection from `permission_profile` plus `cwd`.
  - Updates app-server response/metadata code and tests to call the
  projection only where legacy fields still exist.
  - Keeps snapshot construction profile-only so split filesystem rules,
  disabled enforcement, and external enforcement remain represented by the
  canonical profile.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  thread_response_permission_profile_preserves_enforcement --lib`
  - `cargo test -p codex-core
  dispatch_reclaims_stale_global_lock_and_starts_consolidation --lib`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19775).
  * #19900
  * #19899
  * #19776
  * __->__ #19775

  Michael Bolin · 2026-04-27 22:30:47 -07:00
  fc2a69107c
• permissions: make SessionConfigured profile-only (#19774)

  ## Why
  
  `SessionConfiguredEvent` is the internal event that tells clients what
  permissions are active for a session. Emitting both `sandbox_policy` and
  `permission_profile` leaves two possible authorities and forces every
  consumer to decide which one to honor. At this point in the migration,
  the profile is expressive enough to represent managed, disabled, and
  external sandbox enforcement, so the internal event can be profile-only.
  
  The wire compatibility concern is older serialized events or rollout
  data that only contain `sandbox_policy`; those still need to
  deserialize.
  
  ## What Changed
  
  - Removes `sandbox_policy` from `SessionConfiguredEvent` and makes
  `permission_profile` required.
  - Adds custom deserialization so old payloads with only `sandbox_policy`
  are upgraded to a cwd-anchored `PermissionProfile`.
  - Updates core event emission and TUI session handling to sync
  permissions from the profile directly.
  - Updates app-server response construction to derive the legacy
  `sandbox` response field from the active thread snapshot instead of from
  `SessionConfiguredEvent`.
  - Updates yolo-mode display logic to treat both
  `PermissionProfile::Disabled` and managed unrestricted filesystem plus
  enabled network as full-access, while still preserving the distinction
  between no sandbox and external sandboxing.
  
  ## Verification
  
  - `cargo test -p codex-protocol session_configured_event --lib`
  - `cargo test -p codex-protocol serialize_event --lib`
  - `cargo test -p codex-exec session_configured --lib`
  - `cargo test -p codex-app-server
  thread_response_permission_profile_preserves_enforcement --lib`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox
  --lib`
  - `cargo test -p codex-tui session_configured --lib`
  - `cargo test -p codex-tui
  yolo_mode_includes_managed_full_access_profiles --lib`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19774).
  * #19900
  * #19899
  * #19776
  * #19775
  * __->__ #19774

  Michael Bolin · 2026-04-27 22:06:47 -07:00
  bf38def44e
• Streamline review and feedback handlers (#19498)

  ## Why
  
  The remaining review, interrupt, fuzzy search, feedback, and git-diff
  handlers still had local send-error branches that obscured otherwise
  simple request handling. This final slice flattens those handlers
  without changing the public protocol behavior.
  
  ## What Changed
  
  - Streamlined review start, turn interrupt, fuzzy search session,
  feedback upload, and git diff handlers in
  `codex-rs/app-server/src/codex_message_processor.rs`.
  - Converted validation and upload failures into returned JSON-RPC errors
  where that avoids nested `send_error`/`return` blocks.
  - Left unrelated sandbox setup and notification code untouched.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::review --
  --test-threads=1`

  pakrym-oai · 2026-04-27 16:36:04 -07:00
  c5a495c2cd
• Streamline turn and realtime handlers (#19497)

  ## Why
  
  Turn and realtime handlers had nested validation and send-error branches
  that made the request path longer than the behavior warranted. This
  slice keeps the same request semantics while letting the handlers return
  errors from the failing step.
  
  ## What Changed
  
  - Streamlined turn start, injected item, and turn steer request handling
  in `codex-rs/app-server/src/codex_message_processor.rs`.
  - Applied the same result-returning shape to realtime session response
  handlers.
  - Preserved existing request validation and thread-manager interactions.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::turn_start --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::turn_steer --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::thread_inject_items --
  --test-threads=1`

  pakrym-oai · 2026-04-27 15:21:59 -07:00
  e903d000b0
• Streamline thread resume and fork handlers (#19495)

  ## Why
  
  Thread resume and fork had some of the deepest error-handling
  indentation in this area because helpers emitted request errors
  directly. Returning those failures gives the handlers a single request
  boundary while preserving the async pending-resume behavior.
  
  ## What Changed
  
  - Converted thread resume helpers in
  `codex-rs/app-server/src/codex_message_processor.rs` to return `Result`
  values for validation and view loading failures.
  - Applied the same pattern to thread fork request handling.
  - Simplified pending resume error construction by using the shared
  JSON-RPC error helpers.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::thread_resume --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::thread_fork --
  --test-threads=1`

  pakrym-oai · 2026-04-27 15:04:53 -07:00
  739ab6bc51
• Streamline thread read handlers (#19494)

  ## Why
  
  The thread read/list handlers mostly assemble views, but their error
  handling was interleaved with response emission. Returning view-building
  errors from the helper path keeps those handlers focused on data
  assembly.
  
  ## What Changed
  
  - Added a small mapper for `ThreadReadViewError` to JSON-RPC errors in
  `codex-rs/app-server/src/codex_message_processor.rs`.
  - Streamlined thread list, loaded-thread, read, turn-list, and summary
  handlers to produce result values for the request boundary.
  - Kept the existing invalid-request vs internal-error distinctions for
  missing or unreadable thread data.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all conversation_summary --
  --test-threads=1`

  pakrym-oai · 2026-04-27 14:30:24 -07:00
  2be9fd5a93
• Streamline thread mutation handlers (#19493)

  ## Why
  
  Thread mutation handlers had many short error branches whose only job
  was to emit a JSON-RPC error and stop. This slice keeps those errors
  visible, but lets each handler build a result and return early from
  validation helpers instead of nesting the main path.
  
  ## What Changed
  
  - Streamlined thread archive/unarchive, rename, memory, metadata,
  rollback, compact, background terminal, shell, and guardian handlers in
  `codex-rs/app-server/src/codex_message_processor.rs`.
  - Reused shared JSON-RPC error constructors in
  `codex-rs/app-server/src/bespoke_event_handling.rs` for rollback-related
  request failures.
  - Preserved direct `send_error` calls where they remain the simplest
  boundary for pending async event responses.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::thread_rollback --
  --test-threads=1`

  pakrym-oai · 2026-04-27 14:18:55 -07:00
  5c30d79afb
• Streamline thread start handler (#19492)

  ## Why
  
  The thread start handler mixed request validation, thread construction,
  dynamic-tool validation, and JSON-RPC error emission in one nested flow.
  Returning request errors from the helper path makes the successful setup
  path easier to follow.
  
  ## What Changed
  
  - Reworked `thread/start` handling in
  `codex-rs/app-server/src/codex_message_processor.rs` so helper methods
  return `Result` and the handler emits one result.
  - Moved dynamic-tool validation failures into returned JSON-RPC errors
  instead of local `send_error` branches.
  - Preserved the existing thread creation and task-spawning behavior.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::dynamic_tools --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::turn_start --
  --test-threads=1`

  pakrym-oai · 2026-04-27 13:56:20 -07:00
  c5e2921e1d
• 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
• [codex-analytics] remove ga flag (#19863)
  rhan-oai · 2026-04-27 19:29:19 +00:00
  215d5a8f7c
• Streamline account and command handlers (#19491)

  ## Why
  
  Account login/logout and command exec handlers were doing local error
  sends in the middle of each handler. That made these request flows
  branch heavily even though most of the logic is validate, perform the
  operation, and return the response.
  
  ## What Changed
  
  - Converted ChatGPT/API-key login, login cancel, logout, rate-limit, and
  add-credit handlers in
  `codex-rs/app-server/src/codex_message_processor.rs` to compute `Result`
  values and send them once at the request boundary.
  - Applied the same shape to command exec start/write/resize/terminate
  handlers.
  - Kept side-effect notifications in the same places after successful
  request handling.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::account --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::command_exec --
  --test-threads=1`

  pakrym-oai · 2026-04-27 12:03:49 -07:00
  e5709db6dc
• refactor: make auth loading async (#19762)

  ## Summary
  
  Auth loading used to expose synchronous construction helpers in several
  places even though some auth sources now need async work. This PR makes
  the auth-loading surface async and updates the callers to await it.
  
  This is intentionally only plumbing. It does not change how
  AgentIdentity tokens are decoded, how task runtime ids are allocated, or
  how JWT signatures are verified.
  
  ## Stack
  
  1. **This PR:** [refactor: make auth loading
  async](https://github.com/openai/codex/pull/19762)
  2. [refactor: load AgentIdentity runtime
  eagerly](https://github.com/openai/codex/pull/19763)
  3. [feat: verify AgentIdentity JWTs with
  JWKS](https://github.com/openai/codex/pull/19764)
  
  ## Important call sites
  
  | Area | Change |
  | --- | --- |
  | `codex-login` auth loading | `CodexAuth` and `AuthManager`
  construction paths now await auth loading. |
  | app-server startup | Auth manager construction is awaited during
  initialization. |
  | CLI/TUI/exec/MCP/chatgpt callers | Existing auth-loading calls now
  await the same behavior. |
  | cloud requirements storage loader | The loader becomes async so it can
  share the same auth construction path. |
  | auth tests | Tests that load auth now run in async contexts. |
  
  ## Testing
  
  Tests: targeted Rust auth test compilation, formatter, scoped Clippy
  fix, and Bazel lock check.

  efrazer-oai · 2026-04-27 11:00:27 -07:00
  2009f6e894
• Streamline plugin, apps, and skills handlers (#19490)

  ## Why
  
  The plugin, app, and skills handlers had a lot of repeated
  `send_error`/`return` branches that made the success path hard to scan.
  This slice keeps behavior the same while moving fallible steps into
  local response-producing helpers, so the request boundary can send one
  result.
  
  ## What Changed
  
  - Converted plugin list/install/uninstall handlers in
  `codex-rs/app-server/src/codex_message_processor/plugins.rs` to return
  `Result<*Response, JSONRPCErrorError>` from helper methods and call
  `send_result` once.
  - Added local error-mapping helpers for plugin install/uninstall and
  marketplace failures.
  - Applied the same mechanical shape to app list, skills list/config, and
  marketplace add/remove/upgrade handlers in
  `codex-rs/app-server/src/codex_message_processor.rs`.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server --test all v2::app_list --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::plugin_ --
  --test-threads=1`
  - `cargo test -p codex-app-server --test all v2::skills_list --
  --test-threads=1`

  pakrym-oai · 2026-04-27 10:18:25 -07:00
  4ed22fc7d2
• permissions: centralize legacy sandbox projection (#19734)

  ## Why
  
  The remaining migration work still needs `SandboxPolicy` at a few
  compatibility boundaries, but those projections should come from one
  canonical path. Keeping ad hoc legacy projections scattered through
  app-server, CLI, and config code makes it easy for behavior to drift as
  `PermissionProfile` gains fidelity that the legacy enum cannot
  represent.
  
  ## What Changed
  
  - Adds `Permissions::legacy_sandbox_policy(cwd)` and
  `Config::legacy_sandbox_policy()` as the compatibility projection from
  the canonical `PermissionProfile`.
  - Adds `Permissions::can_set_legacy_sandbox_policy()` so legacy inputs
  are checked after they are converted into profile semantics.
  - Updates app-server command handling, Windows sandbox setup, session
  configuration, and sandbox summaries to use the centralized projection
  helper.
  - Leaves `SandboxPolicy` in place only for boundary inputs/outputs that
  still speak the legacy abstraction.
  
  ## Verification
  
  - `cargo check -p codex-config -p codex-core -p codex-sandboxing -p
  codex-app-server -p codex-cli -p codex-tui`
  - `cargo test -p codex-tui
  permissions_selection_history_snapshot_full_access_to_default --
  --nocapture`
  - `cargo test -p codex-tui
  permissions_selection_sends_approvals_reviewer_in_override_turn_context
  -- --nocapture`
  - `bazel test //codex-rs/tui:tui-unit-tests-bin
  --test_arg=permissions_selection_history_snapshot_full_access_to_default
  --test_output=errors`
  - `bazel test //codex-rs/tui:tui-unit-tests-bin
  --test_arg=permissions_selection_sends_approvals_reviewer_in_override_turn_context
  --test_output=errors`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19734).
  * #19737
  * #19736
  * #19735
  * __->__ #19734

  Michael Bolin · 2026-04-26 20:31:23 -07:00
  0d8cdc0510
• inline hostname resolution for remote sandbox config (#19739)

  # Why
  
  Requirements support host-specific
  `remote_sandbox_config.hostname_patterns`, but config loading previously
  resolved and passed the system hostname through every config-loading
  path even when no requirements layer used `remote_sandbox_config`. On
  machines where hostname lookup is slow, startup and app-server config
  reads paid for a feature that was not active.
  
  We only need the hostname when a requirements layer actually declares
  `remote_sandbox_config`, so this moves hostname resolution to the single
  requirements merge point and keeps all other config callers unaware of
  hostname matching.
  
  # What
  
  - Removed the eager `host_name` plumbing from
  `load_config_layers_state`, `load_requirements_toml`, `ConfigBuilder`,
  app-server `ConfigManager`, network proxy loading, and related call
  sites.
  - Resolve the hostname inside
  `merge_requirements_with_remote_sandbox_config` only when the incoming
  requirements contain `remote_sandbox_config`.

  Abhinav · 2026-04-27 03:18:57 +00:00
  c3e60849e5
• permissions: finish profile-backed app surfaces (#19395)
  Michael Bolin · 2026-04-26 19:42:39 -07:00
  ad57a3fee2
• Delete unused ResponseItem::Message.end_turn (#19605)

  This field is unused. Delete it.

  Andrey Mishchenko · 2026-04-26 17:18:09 -07:00
  35bc6e3d01
• permissions: migrate approval and sandbox consumers to profiles (#19393)

  ## Why
  
  Runtime decisions should not infer permissions from the lossy legacy
  sandbox projection once `PermissionProfile` is available. In particular,
  `Disabled` and `External` need to remain distinct, and managed profiles
  with split filesystem or deny-read rules should not be collapsed before
  approval, network, safety, or analytics code makes decisions.
  
  ## What Changed
  
  - Changes managed network proxy setup and network approval logic to use
  `PermissionProfile` when deciding whether a managed sandbox is active.
  - Migrates patch safety, Guardian/user-shell approval paths, Landlock
  helper setup, analytics sandbox classification, and selected
  turn/session code to profile-backed permissions.
  - Validates command-level profile overrides against the constrained
  `PermissionProfile` rather than a strict `SandboxPolicy` round trip.
  - Preserves configured deny-read restrictions when command profiles are
  narrowed.
  - Adds coverage for profile-backed trust, network proxy/approval
  behavior, patch safety, analytics classification, and command-profile
  narrowing.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19393).
  * #19395
  * #19394
  * __->__ #19393

  Michael Bolin · 2026-04-26 15:30:40 -07:00
  dda8199b73
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• Lift app-server JSON-RPC error handling to request boundary (#19484)

  ## Why
  
  App-server request handling had a lot of repeated JSON-RPC error
  construction and one-off `send_error`/`return` branches. This made small
  handlers noisy and pushed error response details into leaf code that
  otherwise only needed to validate input or call the underlying API.
  
  ## What Changed
  
  - Added shared JSON-RPC error constructors in
  `codex-rs/app-server/src/error_code.rs`.
  - Lifted straightforward request result emission into
  `codex-rs/app-server/src/message_processor.rs` so response/error
  dispatch happens at the request boundary.
  - Reused the result helpers across command exec, config, filesystem,
  device-key, external-agent config, fs-watch, and outgoing-message paths.
  - Removed leaf wrapper handlers where the method body was only
  forwarding to a response helper.
  - Returned request validation errors upward in the simple cases instead
  of sending an error locally and immediately returning.
  
  ## Verification
  
  - `cargo test -p codex-app-server --lib command_exec::tests`
  - `cargo test -p codex-app-server --lib outgoing_message::tests`
  - `cargo test -p codex-app-server --lib in_process::tests`
  - `cargo test -p codex-app-server --test all v2::fs`
  - `cargo test -p codex-app-server --test all v2::config_rpc`
  - `cargo test -p codex-app-server --test all v2::external_agent_config`
  - `cargo test -p codex-app-server --test all v2::initialize`
  - `just fix -p codex-app-server`
  - `git diff --check`
  
  Note: full `cargo test -p codex-app-server` was attempted and stopped in
  `message_processor::tracing_tests::turn_start_jsonrpc_span_parents_core_turn_spans`
  with a stack overflow after unrelated tests had already passed.

  pakrym-oai · 2026-04-26 15:10:35 -07:00
  2a020f1a0a