324 Commits

• feat(tui): redesign session picker (#20065)

  ## Why
  
  The resume/fork picker is becoming the main way users recover previous
  work, but the old fixed table made sessions hard to scan once thread
  names, branches, working directories, and timestamps all mattered. This
  redesign makes the picker denser by default, easier to search, and safer
  to inspect before resuming or forking.
  
  <table>
  <tr>
  <td>
  <img width="1660" height="1103" alt="CleanShot 2026-05-03 at 12 34 10"
  src="https://github.com/user-attachments/assets/313ede1d-1da4-4863-acd2-56b3e27e9703"
  />
  </td>
  <td>
  <img width="1662" height="1100" alt="CleanShot 2026-05-03 at 12 34 15"
  src="https://github.com/user-attachments/assets/cfde7d5c-bab0-4994-a807-254e53f344ea"
  />
  </td>
  </tr>
  <tr>
  <td>
  <img width="1664" height="1107" alt="CleanShot 2026-05-03 at 12 39 22"
  src="https://github.com/user-attachments/assets/e1ee58ca-4dc5-4a35-ae0f-47562da3974c"
  />
  </td>
  <td>
  <img width="1662" height="1100" alt="CleanShot 2026-05-03 at 12 35 09"
  src="https://github.com/user-attachments/assets/9c888072-eedf-4f45-985c-0c14df28bcc7"
  />
  </td>
  </tr>
  </table>
  
  ## What Changed
  
  - Replaces the old session table with responsive session rows that
  prioritize the session name or preview, then show timestamp, cwd, and
  branch metadata.
  - Makes dense view the default while keeping comfortable view available
  through `Ctrl+O`.
  - Persists the picker view preference in `[tui].session_picker_view`,
  including active profile-scoped config.
  - Adds sort/filter controls for updated time, created time, cwd, and all
  sessions.
  - Expands search matching across session name, preview, thread id,
  branch, and cwd.
  - Makes `Esc` safer in search mode: it clears an active query before
  starting a new session.
  - Adds lazy transcript inspection:
    - `Space` expands recent transcript context inline.
    - `Ctrl+T` opens a transcript overlay.
    - raw reasoning visibility follows `show_raw_agent_reasoning`.
  - Keeps remote cwd filtering server-side for remote app-server sessions
  so local path normalization does not incorrectly hide remote results.
  - Updates snapshots and config schema for the new picker states and
  config option.
  
  ## How to Test
  
  1. Start Codex in a repo with several saved sessions.
  2. Press `Ctrl+R` / resume picker entry point.
  3. Confirm the picker opens in dense mode and shows session name or
  preview, timestamp, cwd, and branch metadata.
  4. Press `Ctrl+O` and confirm it switches between dense and comfortable
  views.
  5. Restart Codex and confirm the selected view persists.
  6. Type a query that matches a branch, cwd, thread id, or session name;
  confirm matching sessions appear.
  7. Press `Esc` while the query is non-empty and confirm it clears search
  instead of starting a new session.
  8. Select a session and press `Space`; confirm recent transcript context
  expands inline.
  9. Press `Ctrl+T`; confirm the transcript overlay opens and respects
  raw-reasoning visibility settings.
  
  Targeted tests:
  - `cargo test -p codex-tui resume_picker --no-fail-fast`
  - `cargo test -p codex-core
  runtime_config_resolves_session_picker_view_default_and_override`
  - `cargo test -p codex-core profile_tui_rejects_unsupported_settings`
  - `cargo check -p codex-thread-manager-sample`
  - `cargo insta pending-snapshots`

  Felipe Coury · 2026-05-05 13:32:54 -07:00
  3b2ebb368e
• feat(tui): add raw scrollback mode (#20819)

  ## Why
  
  Granular copy is particularly difficult with the current output. Part of
  it was solved with the introduction of the `/copy` command but when you
  only need to copy parts of a response, you still encounter some issues:
  
  - When you copy a paragraph, the result is a sequence of separate lines
  instead of one correctly joined paragraph.
  - When a word wraps, part of it stays on the original line and the rest
  appears at the start of the next line.
  - When you copy a long command, extra line breaks are often inserted,
  and command arguments can be split across multiple lines.
  
  
  https://github.com/user-attachments/assets/0ef85c84-9363-4aad-b43a-15fce062a443
  
  ## Solution
  
  Now that we own the scrollback and we re-create it when we resize, we
  have the opportunity of toggling between the raw text and the rich text
  we see today.
  
  - Add TUI raw scrollback mode with `tui.raw_output_mode`, `/raw
  [on|off]`, and the configurable `tui.keymap.global.toggle_raw_output`
  action.
  - Render transcript cells through rich/raw-aware paths so raw mode
  preserves source text and lets the terminal soft-wrap selection-friendly
  output.
  - Bind raw-mode toggle to `alt-r` by default, with the keybinding path
  toggling silently while `/raw` continues to emit confirmation messages.
  
  ## Related Issues
  
  Likely addressed by raw mode:
  
  - #12200: clean copy for multiline and soft-wrapped output. Raw mode
  removes Codex-inserted wrapping/indentation and lets the terminal
  soft-wrap logical lines.
  - #9252: command suggestions gain unwanted leading spaces when copied.
  Raw mode renders transcript text without the rich-mode left
  padding/gutter.
  - #8258: prompt output is hard to copy because of leading indentation.
  Raw mode renders user/source-backed transcript text without that
  decorative indentation.
  
  Partially or conditionally addressed:
  
  - #2880: copy/export message as Markdown. Raw mode exposes raw Markdown
  for terminal selection, but this PR does not add a dedicated
  export/copy-message command.
  - #19820: mouse drag selection + copy in the TUI. Raw mode improves
  terminal-native selection of output/history text, but this PR does not
  implement in-TUI mouse selection, highlighting, auto-copy, or composer
  selection.
  - #18979: copied content is divided into two parts. This should improve
  cases caused by Codex-inserted wraps/padding in rendered output; if the
  report is about pasting into the composer/input path, that remains
  outside this PR.
  
  ## Validation
  
  - `just write-config-schema`
  - `just fmt`
  - `cargo test -p codex-config`
  - `cargo test -p codex-tui`
  - `just fix -p codex-tui`
  - `just argument-comment-lint`
  - `cargo test -p codex-tui
  raw_output_mode_can_change_without_inserting_notice -- --nocapture`
  - `cargo test -p codex-tui
  raw_slash_command_toggles_and_accepts_on_off_args -- --nocapture`
  - `cargo test -p codex-tui raw_output_toggle -- --nocapture`
  - `git diff --check`
  - `cargo insta pending-snapshots`

  Felipe Coury · 2026-05-05 11:17:47 -07:00
  5e0a4adbe5
• revert legacy notify deprecation (#21152)

  # Why
  
  Revert #20524 for now because the computer use plugin has not migrated
  off legacy `notify` yet. Keeping the deprecation in place today would
  show users a warning before the plugin path is ready to move, so this
  rolls the change back until that migration is complete.
  
  # What
  
  - revert the legacy `notify` deprecation change from #20524
  - restore the prior `notify` behavior and remove the temporary
  deprecation metrics/docs from that change
  
  Once the computer use plugin has migrated, we can land the same
  deprecation again.

  Abhinav · 2026-05-05 10:34:44 -07:00
  13be504063
• feat: support template interpolation in multi-agent usage hints (#20973)

  ## Why
  
  `multi_agent_v2` usage hints sometimes need to reference resolved config
  values such as the effective thread limit. Those values only exist after
  config layering, defaulting, and feature materialization, so the raw
  TOML alone was not enough to render them.
  
  ## What changed
  
  - allow
  `features.multi_agent_v2.{usage_hint_text,root_agent_usage_hint_text,subagent_usage_hint_text}`
  to use `{{ ... }}` placeholders backed by the materialized effective
  config
  - fail config loading with a targeted error when a referenced
  placeholder does not exist or does not resolve to a scalar value
  - move resolved-config materialization into a shared helper so config
  interpolation and config-lock export/replay both serialize the same
  resolved feature, memory, and agent settings
  
  ## Example
  ```
  [features.multi_agent_v2]
  enabled = true
  usage_hint_text = "lorem {{ features.multi_agent_v2.max_concurrent_threads_per_session }} ipsum"
  ```
  gets rendered as 
  ```
          "description": String("... \lorem 4 ipsum"),
  ```

  jif-oai · 2026-05-04 11:50:01 +02:00
  f48b777717
• fix: reduce ConfigBuilder::build stack usage (#20650)

  ## Why
  
  `ConfigBuilder::build` performs a large amount of async config loading.
  Leaving that entire future on the caller stack makes config startup more
  fragile on small runtime worker stacks.
  
  ## What changed
  
  - keep `ConfigBuilder::build` as a thin wrapper that boxes the
  config-loading future before awaiting it
  - move the existing implementation into a private `build_inner` method
  so the large async state machine lives on the heap instead of the
  runtime thread stack
  
  ## Testing
  
  - Not run locally

  jif-oai · 2026-05-01 20:24:17 +02:00
  2817866a32
• deprecate legacy notify (#20524)

  # Why
  
  `notify` is the remaining compatibility surface from the legacy hook
  implementation. The newer lifecycle hook engine now owns the active hook
  system, so we should start steering users away from adding new `notify`
  configs before removing the old path entirely. This also adds a
  lightweight watchpoint for the deprecation so we can see how much legacy
  usage remains before the clean drop.
  
  # What
  
  - emit a startup deprecation notice when a non-empty `notify` command is
  configured
  - emit `codex.notify.configured` when a session starts with legacy
  `notify` configured
  - emit `codex.notify.run` when the legacy notify path fires after a
  completed turn
  - mark `notify` as deprecated in the config schema and repo docs
  - remove the orphaned `codex-rs/hooks/src/user_notification.rs` file
  that is no longer compiled
  - add regression coverage for the new deprecation notice
  
  # Next steps
  
  A follow-up PR can remove the legacy notify path entirely once we are
  ready for the clean drop. Before then, we can watch
  `codex.notify.configured` and `codex.notify.run` to understand the
  deprecation impact and remaining active usage. The cleanup PR should
  then delete the `notify` config field, the `legacy_notify`
  implementation, the old compatibility dispatch types and callsites that
  only exist for the legacy path, and the remaining compatibility
  docs/tests.
  
  # Testing
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-config`
  - `cargo test -p codex-core emits_deprecation_notice_for_notify`

  Abhinav · 2026-05-01 17:35:21 +00:00
  78baa20780
• feat: export and replay effective config locks (#20405)

  ## Why
  
  For reproducibility. A hand-written `config.toml` is not enough to
  recreate what a Codex session actually ran with because layered config,
  CLI overrides, defaults, feature aliases, resolved feature config,
  prompt setup, and model-catalog/session values can all affect the final
  runtime behavior.
  
  This PR adds an effective config lockfile path: one run can export the
  resolved session config, and a later run can replay that lockfile and
  fail early if the regenerated effective config drifts.
  
  ## What Changed
  
  - Add a dedicated `ConfigLockfileToml` wrapper with top-level lockfile
  metadata plus the replayable config:
  
    ```toml
    version = 1
    codex_version = "..."
  
    [config]
    # effective ConfigToml fields
    ```
  
  - Keep lockfile metadata out of regular `ConfigToml`; replay loads
  `ConfigLockfileToml` and then uses its nested `config` as the
  authoritative config layer.
  - Add `debug.config_lockfile.export_dir` to write
  `<thread_id>.config.lock.toml` when a root session starts.
  - Add `debug.config_lockfile.load_path` to replay a saved lockfile and
  validate the regenerated session lockfile against it.
  - Add `debug.config_lockfile.allow_codex_version_mismatch` to optionally
  tolerate Codex binary version drift while still comparing the rest of
  the lockfile.
  - Add `debug.config_lockfile.save_fields_resolved_from_model_catalog` so
  lock creation can either save model-catalog/session-resolved fields or
  intentionally leave those fields dynamic.
  - Build lockfiles from the effective config plus resolved runtime values
  such as model selection, reasoning settings, prompts, service tier, web
  search mode, feature states/config, memories config, skill instructions,
  and agent limits.
  - Materialize feature aliases and custom feature config into the
  lockfile so replay compares canonical resolved behavior instead of
  user-authored alias shape.
  - Strip profile/debug/file-include/environment-specific inputs from
  generated lockfiles so they contain replayable values rather than the
  inputs that produced those values.
  - Surface JSON-RPC server error code/data in app-server client and TUI
  bootstrap errors so config-lock replay failures include the actual TOML
  diff.
  - Regenerate the config schema for the new debug config keys.
  
  ## Review Notes
  
  The main flow is split across these files:
  
  - `config/src/config_toml.rs`: lockfile/debug TOML shapes.
  - `core/src/config/mod.rs`: loading `debug.config_lockfile.*`, replaying
  a lockfile as a config layer, and preserving the expected lockfile for
  validation.
  - `core/src/session/config_lock.rs`: exporting the current session
  lockfile and materializing resolved session/config values.
  - `core/src/config_lock.rs`: lockfile parsing, metadata/version checks,
  replay comparison, and diff formatting.
  
  ## Usage
  
  Export a lockfile from a normal session:
  
  ```sh
  codex -c 'debug.config_lockfile.export_dir="/tmp/codex-locks"'
  ```
  
  Export a lockfile without saving model-catalog/session-resolved fields:
  
  ```sh
  codex -c 'debug.config_lockfile.export_dir="/tmp/codex-locks"' \
    -c 'debug.config_lockfile.save_fields_resolved_from_model_catalog=false'
  ```
  
  Replay a saved lockfile in a later session:
  
  ```sh
  codex -c 'debug.config_lockfile.load_path="/tmp/codex-locks/<thread_id>.config.lock.toml"'
  ```
  
  If replay resolves to a different effective config, startup fails with a
  TOML diff.
  
  To tolerate Codex binary version drift during replay:
  
  ```sh
  codex -c 'debug.config_lockfile.load_path="/tmp/codex-locks/<thread_id>.config.lock.toml"' \
    -c 'debug.config_lockfile.allow_codex_version_mismatch=true'
  ```
  
  ## Limitations
  
  This does not support custom rules/network policies.
  
  ## Verification
  
  - `cargo test -p codex-core config_lock`
  - `cargo test -p codex-config`
  - `cargo test -p codex-thread-manager-sample`

  jif-oai · 2026-05-01 17:46:02 +02:00
  0b04d1b3cc
• Color TUI statusline from active theme (#19631)

  ## Why
  
  Users have shared that the TUI can feel too visually flat because themes
  mostly show up in code syntax highlighting. The configurable statusline
  is a natural place to make the active theme more visible, while still
  letting users keep the existing monotone statusline if they prefer it.
  
  ## What Changed
  
  - Added a statusline styling helper that builds the rendered statusline
  from `(StatusLineItem, text)` segments, preserving item identity while
  keeping the plain text output unchanged.
  - Derived foreground accent colors from the active syntax theme by
  looking up TextMate scopes through the existing syntax highlighter, with
  conservative ANSI fallbacks when a scope does not provide a foreground.
  - Tuned theme-derived colors to keep the accents visible without making
  the statusline feel overly bright.
  - Added `[tui].status_line_use_colors`, defaulting to `true`, plus a
  separated `/statusline` toggle so users can enable or disable
  theme-derived statusline colors from the setup UI.
  - Updated the live statusline and `/statusline` preview to use the same
  styled builder, while keeping terminal-title preview text plain.
  - Kept statusline separators and active-agent add-ons subdued while
  removing blanket dimming from the whole passive statusline.
  
  ## Verification
  
  - `cargo test -p codex-tui status_line`
  - `cargo test -p codex-tui theme_picker`
  - `cargo test -p codex-tui foreground_style_for_scopes`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-config`
  - `cargo test -p codex-core status_line_use_colors`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`
  
  ## Visual
  
  <img width="369" height="23" alt="Screenshot 2026-04-30 at 6 16 08 PM"
  src="https://github.com/user-attachments/assets/11d03efb-8e4f-4450-8f4d-00a9659ef4cd"
  />
  
  <img width="385" height="23" alt="Screenshot 2026-04-30 at 6 16 02 PM"
  src="https://github.com/user-attachments/assets/a3d89f36-bdc1-42e8-8e84-61350e3999e2"
  />

  Eric Traut · 2026-04-30 22:42:48 -07:00
  a93c89f497
• feat(tui): add vim composer mode (#18595)

  ## Why
  
  Codex now has configurable TUI keymaps, but the composer still behaves
  like a plain text field. Users who prefer modal editing need a way to
  keep Vim muscle memory while drafting prompts, and the keymap picker
  needs to expose Vim-specific actions if those bindings are configurable
  instead of hardcoded.
  
  ## What Changed
  
  - Adds composer Vim mode with insert/normal state, common normal-mode
  movement and editing commands, `d`/`y` operator-pending flows, and
  mode-aware footer and cursor indicators.
  - Adds `/vim`, an optional global `toggle_vim_mode` binding, and
  `tui.vim_mode_default` so Vim mode can be toggled per session or enabled
  as the default composer state.
  - Extends runtime and config keymaps with `vim_normal` and
  `vim_operator` contexts, exposes those contexts in `/keymap`, refreshes
  the config schema, and validates Vim bindings separately.
  - Integrates Vim normal mode with existing composer behavior: `/` opens
  slash command entry, `!` enters shell mode, `j`/`k` navigate history at
  history boundaries, successful submissions reset back to normal mode,
  and paste burst handling remains insert-mode only.
  - Teaches the TUI render path to apply and restore cursor style so Vim
  insert mode can use a bar cursor without leaving the terminal in that
  state after exit.
  
  ## Validation
  
  - `cargo test -p codex-tui keymap -- --nocapture` on the keymap/Vim
  coverage
  - `cargo insta pending-snapshots`
  
  ## Docs
  
  This introduces user-facing `/vim`, `tui.vim_mode_default`, and Vim
  keymap contexts under `tui.keymap`, so the public CLI configuration and
  slash-command docs should be updated before the feature ships.

  Felipe Coury · 2026-04-30 17:20:51 -07:00
  b6f81257f8
• fix: ignore dangerous project-level config keys (#20098)

  ## Description
  Ignore these top-level config keys when loading project-scoped
  config.toml files:
  ```
      "openai_base_url",
      "chatgpt_base_url",
      "model_provider",
      "model_providers",
      "profile",
      "profiles",
      "experimental_realtime_ws_base_url",
  ```
  
  ## What changed
  
  - Add a project-local config denylist for credential-routing fields such
  as `openai_base_url`, `chatgpt_base_url`, `model_provider`,
  `model_providers`, `profile`, `profiles`, and
  `experimental_realtime_ws_base_url`.
  - Strip those fields from project config layers before they participate
  in effective config merging, while leaving safe project-local settings
  intact.
  - Track ignored project-local keys on config layers and surface a
  startup warning telling users to move those settings to user-level
  `config.toml` if they intentionally need them.
  - Update profile behavior coverage so project-local `profile` /
  `profiles` entries are ignored instead of overriding user-level profile
  selection.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core
  project_layer_ignores_unsupported_config_keys`
  - `cargo test -p codex-core project_profiles_are_ignored`
  - `cargo test -p codex-core config::config_loader_tests`

  Owen Lin · 2026-04-30 23:03:01 +00:00
  9ddb267e9c
• Move plugin out of core. (#20348)
  xl-openai · 2026-04-30 14:26:14 -07:00
  7b3de63041
• [codex] Migrate thread turns list to thread store (#19280)

  - migrate `thread/turns/list` to ThreadStore. Uses ThreadStore for most
  data now but merges in the in-memory state from thread manager
  - keep v2 `thread/list` pathless-store friendly by converting
  `StoredThread` directly to API `Thread`
  - add regression coverage for pathless store history/listing

  Tom · 2026-04-30 14:16:42 -07:00
  127be0612c
• permissions: expose active profile metadata (#20095)
  Michael Bolin · 2026-04-29 20:54:59 -07:00
  ac4332c05b
• [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
• [apps] Add apps MCP path override (#20231)

  Summary
  
  - Add `[features.apps_mcp_path_override]` config with a `path` field for
  overriding only the built-in apps MCP path.
  - Keep existing host/base URL derivation unchanged and append the
  configured path after that base.
  - Regenerate the config schema with the custom feature-config case.
  
  Test Plan
  
  - Not run for latest revision; only `just fmt` and `just
  write-config-schema` were run.
  - Earlier revision: `cargo test -p codex-features`
  - Earlier revision: `cargo test -p codex-mcp`

  Alex Daley · 2026-04-29 18:08:06 -04:00
  f63b19bedd
• feat(cli): add explicit sandbox permission profiles (#20117)

  ## Why
  
  `codex sandbox` is useful for exercising sandbox behavior directly, but
  before this stack the CLI
  only picked up permission profiles indirectly from the active config.
  The existing debug-sandbox path
  already compiled `[permissions]` profiles through normal config loading,
  as covered by the existing
  profile tests in
  [`debug_sandbox.rs`](https://github.com/openai/codex/blob/de2ccf94735a3d8a2a7077e6a5292026413867cf/codex-rs/cli/src/debug_sandbox.rs#L715-L760).
  
  This adds the smallest stable entry point first: an explicit profile
  selector that reuses the same
  config machinery as normal Codex config, so standalone testing becomes
  possible without changing
  current no-selector behavior.
  
  ## What changed
  
  - Add additive `--permissions-profile NAME` support to `codex sandbox
  macos|linux|windows`.
  - Resolve built-in and user-defined profile names by feeding
  `default_permissions` through the
  existing config compilation path instead of inventing a sandbox-only
  parser.
  - Make an explicit selector win over an ambient active profile's legacy
  `sandbox_mode`.
  - Keep the existing no-selector behavior unchanged.
  
  ## Stack
  
  1. #20117 `sandbox-ui-profile` --> this PR
  2. #20118 `sandbox-ui-config`
  
  Both PRs are additive. Replay JSON is intentionally deferred to a
  follow-up design pass.
  
  ## Tests ran
  
  - `cargo test -p codex-cli debug_sandbox`
  - `cargo test -p codex-cli sandbox_macos_parses_permissions_profile`
  - `cargo test -p codex-core
  cli_override_takes_precedence_over_profile_sandbox_mode`
  - macOS branch-binary smoke on the rebased top of stack: built-in
  `:workspace` and user-defined
    profiles both executed successfully through `--permissions-profile`.
  - Linux devbox branch-binary smoke on the rebased top of stack: built-in
  `:workspace` and
  user-defined profiles both executed successfully through
  `--permissions-profile`.

  viyatb-oai · 2026-04-29 06:18:16 +00:00
  6ed0440611
• Support disabling tool suggest for specific tools. (#20072)

  ## Summary
  - Add `disable_tool_suggest` to app and plugin config, schema, and
  TypeScript output
  - Exclude disabled connectors and plugins from tool suggestion discovery
  - Persist "never show again" tool-suggestion choices back into
  `config.toml`
  - Update config docs and add coverage for connector and plugin
  suppression
  
  ## Testing
  - Added and updated unit tests for config persistence and tool-suggest
  filtering
  - Not run (not requested)

  Matthew Zeng · 2026-04-29 00:19:34 +00:00
  ebdf3a878c
• Make MultiAgentV2 wait minimum configurable (#20052)

  ## Why
  
  MultiAgentV2 `wait_agent` currently clamps short waits to a fixed 10
  second minimum. That default is still useful for preventing tight
  polling loops, but it is too rigid for environments that need faster
  mailbox wake-up checks or a larger minimum to discourage frequent
  polling.
  
  This PR makes the minimum wait timeout configurable from the existing
  MultiAgentV2 feature config section, so operators can tune the behavior
  without changing the legacy multi-agent tool surface.
  
  ## What Changed
  
  - Added `features.multi_agent_v2.min_wait_timeout_ms`.
  - Defaulted the new setting to the existing 10 second floor.
  - Validated the configured value as `1..=3600000`, matching the existing
  one hour maximum wait bound.
  - Applied the configured minimum to MultiAgentV2 `wait_agent` runtime
  clamping.
  - Plumbed the configured minimum into the `wait_agent` tool schema,
  including the effective default when the minimum is above the normal 30
  second default.
  - Regenerated `core/config.schema.json`.
  
  ## Verification
  
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib multi_agent_v2`
  - `just fix -p codex-core`

  jif-oai · 2026-04-28 22:36:44 +02:00
  34d71d43eb
• permissions: add built-in default profiles (#19900)

  ## Why
  
  The migration away from `SandboxPolicy` needs new configs to start from
  permissions profiles instead of deriving profiles from legacy sandbox
  modes. Existing users can have empty `config.toml` files, and we should
  not rewrite user-owned config files that may live in shared
  repositories.
  
  This PR introduces built-in profile names so an empty config can resolve
  to a canonical `PermissionProfile`, while explicit named `[permissions]`
  profiles still behave predictably.
  
  ## What changed
  
  - Adds built-in `default_permissions` profile names:
    - `:read-only` maps to `PermissionProfile::read_only()`.
  - `:workspace` maps to the workspace-write profile, including
  project-root metadata carveouts.
  - `:danger-no-sandbox` maps to `PermissionProfile::Disabled`, preserving
  the distinction between no sandbox and a broad managed sandbox.
  - Reserves the `:` prefix for built-in profiles so user-defined
  `[permissions]` profiles cannot collide with future built-ins.
  - Allows `default_permissions` to reference a built-in profile without
  requiring a `[permissions]` table.
  - Makes an otherwise empty config choose a built-in profile by
  trust/platform context: trusted or untrusted project roots use
  `:workspace` when the platform supports that sandbox, while roots
  without a trust decision use `:read-only`.
  - Keeps legacy `sandbox_mode` configs on the legacy path, and still
  rejects user-defined `[permissions]` profiles that omit
  `default_permissions` so we do not silently guess among custom profiles.
  - Preserves compatibility behavior for implicit defaults: bare
  `network.enabled = true` allows runtime network without starting the
  managed proxy, explicit profile proxy policy still starts the proxy, and
  implicit workspace/add-dir roots keep legacy metadata carveouts.
  
  ## Verification
  
  - `cargo test -p codex-core builtin --lib`
  - `cargo test -p codex-core profile_network_proxy_config`
  - `cargo test -p codex-core
  implicit_builtin_workspace_profile_preserves_add_dir_metadata_carveouts`
  - `cargo test -p codex-core
  permissions_profiles_network_enabled_allows_runtime_network_without_proxy`
  - `cargo test -p codex-core
  permissions_profiles_proxy_policy_starts_managed_network_proxy`
  
  ## Documentation
  
  Public Codex config docs should mention these built-in names when the
  `[permissions]` config format is ready to document as stable.
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19900).
  * #20041
  * #20040
  * #20037
  * #20035
  * #20034
  * #20033
  * #20032
  * #20030
  * #20028
  * #20027
  * #20026
  * #20024
  * #20021
  * #20018
  * #20016
  * #20015
  * #20013
  * #20011
  * #20010
  * #20008
  * __->__ #19900

  Michael Bolin · 2026-04-28 11:21:39 -07:00
  9e26613657
• feat(tui): add configurable keymap support (#18593)

  ## Why
  
  The TUI currently handles keyboard shortcuts as hard-coded event matches
  spread across app, composer, pager, list, approval, and navigation code.
  That makes shortcuts hard to customize, makes displayed hints easy to
  drift from actual behavior, and makes future keymap work riskier because
  there is no central action inventory.
  
  This PR adds the foundation for configurable, action-based keymaps
  without adding the interactive remapping UI yet. Onboarding
  intentionally stays on fixed startup shortcuts because users cannot
  reasonably configure keymaps before completing onboarding.
  
  This is PR1 in the keymap stack:
  
  - PR1: #18593: configurable keymap foundation
  - PR2: #18594: `/keymap` picker and guided remapping UI
  - PR3: #18595: Vim composer mode and the remap option
  
  ## Design Notes
  
  The new model resolves named actions into concrete runtime bindings once
  from config, then passes those bindings to the UI surfaces that handle
  input or render shortcut hints.
  
  The main concepts are:
  
  - **Context**: a scope where an action is active, such as `global`,
  `chat`, `composer`, `editor`, `pager`, `list`, or `approval`.
  - **Action**: a named operation inside a context, such as
  `global.open_transcript`, `composer.submit`, or `pager.close`.
  - **Binding**: one or more single-key shortcuts assigned to an action,
  written as config strings such as `ctrl-t`, `alt-backspace`, or
  `page-down`. Multi-step sequences such as `ctrl-x ctrl-s`, `g g`, or
  leader-key flows are not part of this PR.
  - **Resolution order**: context-specific config wins first, supported
  global fallbacks come next, and built-in defaults fill in anything
  unset.
  - **Explicit unbinding**: an empty array removes an action binding in
  that scope and does not fall through to a fallback binding.
  - **Conflict validation**: a resolved keymap rejects duplicate active
  bindings inside the same scope so one keypress cannot dispatch two
  actions.
  
  ## What Changed
  
  - Added `TuiKeymap` config support under `[tui.keymap]`, including typed
  contexts/actions, key alias normalization, generated schema coverage,
  and user-facing config errors.
  - Added `RuntimeKeymap` resolution in `codex-rs/tui/src/keymap.rs`,
  including fallback precedence, built-in defaults, explicit unbinding,
  and per-context conflict validation.
  - Rewired existing TUI handlers to consume resolved keymap actions
  instead of directly matching hard-coded keys in each component.
  - Updated key hint rendering and footer/pager/list surfaces so displayed
  shortcuts follow the resolved keymap.
  - Kept onboarding shortcuts fixed in
  `codex-rs/tui/src/onboarding/keys.rs` instead of exposing them through
  `[tui.keymap]`.
  
  ## Validation
  
  The branch includes focused coverage for config parsing, key
  normalization, runtime fallback resolution, explicit unbinding,
  duplicate-key conflict validation, default keymap consistency,
  onboarding startup key behavior, and UI hint snapshots affected by
  resolved key bindings.

  Felipe Coury · 2026-04-28 12:52:25 -03:00
  5e737372ee
• 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 MultiAgentV2 root and subagent context hints (#19805)

  ## Why
  
  MultiAgentV2 sessions need startup guidance that matches the role of the
  thread that is actually being created. Root agents and subagents have
  different responsibilities, and forked subagents can inherit parent
  rollout history. If the parent hint is carried into the child context,
  the child can see stale or conflicting developer guidance before its own
  session-specific context is added.
  
  ## What changed
  
  - Added `features.multi_agent_v2.root_agent_usage_hint_text` and
  `features.multi_agent_v2.subagent_usage_hint_text` config fields,
  including schema/config parsing support.
  - Injected the matching root or subagent hint into the initial context
  as its own developer message when `multi_agent_v2` is enabled.
  - Filtered configured MultiAgentV2 usage-hint developer messages out of
  forked parent history so a child thread receives fresh guidance for its
  own session source/config.
  - Added targeted coverage for config parsing, initial-context rendering,
  feature-config deserialization, and forked-history filtering.
  
  ## Context examples
  
  With this config:
  
  ```toml
  [features.multi_agent_v2]
  enabled = true
  root_agent_usage_hint_text = "Root guidance."
  subagent_usage_hint_text = "Subagent guidance."
  ```
  
  A root thread initial context renders the root hint as a standalone
  developer message:
  
  ```text
  [developer]
  <existing developer context, when present>
  
  [developer]
  Root guidance.
  ```
  
  A subagent thread initial context renders the subagent hint instead:
  
  ```text
  [developer]
  <existing developer context, when present>
  
  [developer]
  Subagent guidance.
  ```
  
  When a subagent forks parent history, any parent developer message whose
  text exactly matches the configured MultiAgentV2 root or subagent hint
  is omitted from the forked history before the child receives its fresh
  subagent hint.

  jif-oai · 2026-04-28 12:31:45 +02:00
  fd36838cf3
• Remove ghost snapshots (#19481)

  ## Summary
  - Remove `ghost_snapshot` / `GhostCommit` from the Responses API surface
  and generated SDK/schema artifacts.
  - Keep legacy config loading compatible, but make undo a no-op that
  reports the feature is unavailable.
  - Clean up core history, compaction, telemetry, rollout, and tests to
  stop carrying ghost snapshot items.
  
  ## Testing
  - Unit tests passed for `codex-protocol`, `codex-core` targeted undo and
  compaction flows, `codex-rollout`, and `codex-app-server-protocol`.
  - Regenerated config and app-server schemas plus Python SDK artifacts
  and verified they match the checked-in outputs.

  pakrym-oai · 2026-04-27 18:48:57 -07:00
  4e05f3053c
• permissions: derive config defaults as profiles (#19772)

  ## Why
  
  This continues the permissions migration by making legacy config default
  resolution produce the canonical `PermissionProfile` first. The legacy
  `SandboxPolicy` projection should stay available at compatibility
  boundaries, but config loading should not create a legacy policy just to
  immediately convert it back into a profile.
  
  Specifically, when `default_permissions` is not specified in
  `config.toml`, instead of creating a `SandboxPolicy` in
  `codex-rs/core/src/config/mod.rs` and then trying to derive a
  `PermissionProfile` from it, we use `derive_permission_profile()` to
  create a more faithful `PermissionProfile` using the values of
  `ConfigToml` directly.
  
  This also keeps the existing behavior of `sandbox_workspace_write` and
  extra writable roots after #19841 replaced `:cwd` with `:project_roots`.
  Legacy workspace-write defaults are represented as symbolic
  `:project_roots` write access plus symbolic project-root metadata
  carveouts. Extra absolute writable roots are still added directly and
  continue to get concrete metadata protections for paths that exist under
  those roots.
  
  The platform sandboxes differ when a symbolic project-root subpath does
  not exist yet.
  
  * **Seatbelt** can encode literal/subpath exclusions directly, so macOS
  emits project-root metadata subpath policies even if `.git`, `.agents`,
  or `.codex` do not exist.
  * **bwrap** has to materialize bind-mount targets. Binding `/dev/null`
  to a missing `.git` can create a host-visible placeholder that changes
  Git repo discovery. Binding missing `.agents` would not affect Git
  discovery, but it would still create a host-visible project metadata
  placeholder from an automatic compatibility carveout. Linux therefore
  skips only missing automatic `.git` and `.agents` read-only metadata
  masks; missing `.codex` remains protected so first-time project config
  creation goes through the protected-path approval flow. User-authored
  `read` and `none` subpath rules keep normal bwrap behavior, and `none`
  can still mask the first missing component to prevent creation under
  writable roots.
  
  ## What Changed
  
  - Adds profile-native helpers for legacy workspace-write semantics,
  including `PermissionProfile::workspace_write_with()`,
  `FileSystemSandboxPolicy::workspace_write()`, and
  `FileSystemSandboxPolicy::with_additional_legacy_workspace_writable_roots()`.
  - Makes `FileSystemSandboxPolicy::workspace_write()` the single legacy
  workspace-write constructor so both `from_legacy_sandbox_policy()` and
  `From<&SandboxPolicy>` include the project-root metadata carveouts.
  - Removes the no-carveout `legacy_workspace_write_base_policy()` path
  and the `prune_read_entries_under_writable_roots()` cleanup that was
  only needed by that split construction.
  - Adds `ConfigToml::derive_permission_profile()` for legacy sandbox-mode
  fallback resolution; named `default_permissions` profiles continue
  through the permissions profile pipeline instead of being reconstructed
  from `sandbox_mode`.
  - Updates `Config::load()` to start from the derived profile, validate
  that it still has a legacy compatibility projection, and apply
  additional writable roots directly to managed workspace-write filesystem
  policies.
  - Updates Linux bwrap argument construction so missing automatic
  `.git`/`.agents` symbolic project-root read-only carveouts are skipped
  before emitting bind args; missing `.codex`, user-authored `read`/`none`
  subpath rules, and existing missing writable-root behavior are
  preserved.
  - Adds coverage that legacy workspace-write config produces symbolic
  project-root metadata carveouts, extra legacy workspace writable roots
  still protect existing metadata paths such as `.git`, and bwrap skips
  missing `.git`/`.agents` project-root carveouts while preserving missing
  `.codex` and user-authored missing subpath rules.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19772).
  * #19776
  * #19775
  * #19774
  * #19773
  * __->__ #19772

  Michael Bolin · 2026-04-27 16:50:10 -07:00
  755880ef9c
• Show action required in terminal title (#18372)

  Implements #18162
  
  This updates the TUI terminal title to show an explicit action-required
  state when Codex is blocked on user approval or input. The terminal
  title now uses the activity title item to cover both active work and
  blocked-on-user states, while still accepting the legacy spinner config
  value.
  
  Changes
  - Rename the terminal title item from `spinner` to `activity` while
  preserving legacy config compatibility
  - Show `[ ! ] Action Required `while approval or input overlays are
  active, with a blinking `[ . ]` alternate state
  - Suppress the normal working spinner while Codex is blocked on user
  action
  - Add targeted coverage for action-required title behavior and legacy
  title-item parsing
  
  Testing
  - Trigger an approval or input modal and confirm the tab title
  alternates between `[ ! ] Action Required` and `[ . ] Action Required`
  - Disable the activity title item and confirm the action-required title
  does not appear
  - Resolve the prompt and confirm the title returns to the normal
  spinning/idel state
  
  
  https://github.com/user-attachments/assets/e9ecc530-a6be-4fd7-b9a6-d550a790eb2c

  canvrno-oai · 2026-04-27 15:27:11 -07:00
  e64c765673
• chore: split memories part 1 (#19818)

  Extract memories into 2 different crates

  jif-oai · 2026-04-27 16:01:05 +02:00
  bb83eec825
• multi_agent_v2: move thread cap into feature config (#19792)

  ## Why
  
  `features.multi_agent_v2.max_concurrent_threads_per_session` is meant to
  be the MultiAgentV2-specific session thread cap: it counts the root
  thread and all open subagent threads. The previous implementation kept
  this surface tied to `agents.max_threads`, which made it a global
  subagent-only cap and allowed the legacy setting to coexist with
  MultiAgentV2.
  
  ## What Changed
  
  - Added `max_concurrent_threads_per_session` to
  `[features.multi_agent_v2]` with default `4`.
  - Removed the `[agents] max_concurrent_threads_per_session` alias to
  `agents.max_threads`.
  - When MultiAgentV2 is enabled, reject `agents.max_threads` and derive
  the existing internal subagent slot limit as
  `max_concurrent_threads_per_session - 1`.
  - Regenerated `core/config.schema.json` and added coverage for the new
  config semantics.
  
  ## Result
  ```
  ➜  codex git:(jif/clean-multi-agent-v2-config) codex -c features.multi_agent_v2.enabled=true -c features.multi_agent_v2.max_concurrent_threads_per_session=3
  ╭────────────────────────────────────────────────────╮
  │ >_ OpenAI Codex (v0.0.0)                           │
  │                                                    │
  │ model:     gpt-5.5 xhigh   fast   /model to change │
  │ directory: ~/code/codex                            │
  ╰────────────────────────────────────────────────────╯
  
    Tip: Update Required - This version will no longer be supported starting May 8th. Please upgrade to the latest version (https://github.com/openai/codex/releases/latest) using your preferred package manager.
  
  › Can you try to spawn 4 agents
  
  
  • I’ll try to start four lightweight agents at once and report exactly what the runtime accepts.
  
  • Spawned Russell [no-apps] (gpt-5.5 xhigh)
    └ Spawn probe 1: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Spawned Descartes [no-apps] (gpt-5.5 xhigh)
    └ Spawn probe 2: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Agent spawn failed
    └ Spawn probe 3: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Agent spawn failed
    └ Spawn probe 4: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • The runtime accepted the first two and rejected the next two with agent thread limit reached. I’m checking whether the two accepted probes have returned cleanly, then I’ll close them if needed.
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-27 13:31:56 +02:00
  f8c527e529
• permissions: constrain requirements as profiles (#19736)
  Michael Bolin · 2026-04-26 21:49:30 -07:00
  523e4aa8e3
• permissions: store only constrained permission profiles (#19735)
  Michael Bolin · 2026-04-26 20:59:58 -07:00
  0ccd659b4b
• 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
• Allow agents.max_threads to work with multi_agent_v2 (#19733)
  Andrey Mishchenko · 2026-04-26 17:56:05 -07:00
  1f304dd1f2
• permissions: remove core legacy policy round trips (#19394)

  ## Why
  
  Several execution paths still converted profile-backed permissions into
  `SandboxPolicy` and then rebuilt runtime permissions from that legacy
  shape. Those round trips are unnecessary after the preceding PRs and can
  lose split filesystem semantics. Core approval and escalation should
  carry the resolved profile directly.
  
  ## What Changed
  
  - Removes `sandbox_policy` from `ResolvedPermissionProfile`; the
  resolved permission object now carries the canonical `PermissionProfile`
  directly.
  - Updates exec-policy fallback, shell/unified-exec interception,
  escalation reruns, and related tests to pass profiles instead of legacy
  policies.
  - Removes legacy additional-permission merge helpers that built an
  effective `SandboxPolicy` before rebuilding runtime permissions.
  - Keeps legacy projections only at compatibility boundaries that still
  require `SandboxPolicy`, not in core permission computation.
  
  ## 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/19394).
  * #19737
  * #19736
  * #19735
  * #19734
  * #19395
  * __->__ #19394

  Michael Bolin · 2026-04-26 17:43:32 -07:00
  2cb8746457
• 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
• permissions: derive compatibility policies from profiles (#19392)

  ## Why
  
  After #19391, `PermissionProfile` and the split filesystem/network
  policies could still be stored in parallel. That creates drift risk: a
  profile can preserve deny globs, external enforcement, or split
  filesystem entries while a cached projection silently loses those
  details. This PR makes the profile the runtime source and derives
  compatibility views from it.
  
  ## What Changed
  
  - Removes stored filesystem/network sandbox projections from
  `Permissions` and `SessionConfiguration`; their accessors now derive
  from the canonical `PermissionProfile`.
  - Derives legacy `SandboxPolicy` snapshots from profiles only where an
  older API still needs that field.
  - Updates MCP connection and elicitation state to track
  `PermissionProfile` instead of `SandboxPolicy` for auto-approval
  decisions.
  - Adds semantic filesystem-policy comparison so cwd changes can preserve
  richer profiles while still recognizing equivalent legacy projections
  independent of entry ordering.
  - Updates config/session tests to assert profile-derived projections
  instead of parallel stored fields.
  
  ## 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/19392).
  * #19395
  * #19394
  * #19393
  * __->__ #19392

  Michael Bolin · 2026-04-26 15:06:42 -07:00
  deaa307fb2
• permissions: make runtime config profile-backed (#19606)

  ## Why
  
  This supersedes #19391. During stack repair, GitHub marked #19391 as
  merged into a temporary stack branch rather than into `main`, so the
  runtime-config change needed a fresh PR.
  
  `PermissionProfile` is now the canonical permissions shape after #19231
  because it can distinguish `Managed`, `Disabled`, and `External`
  enforcement while also carrying filesystem rules that legacy
  `SandboxPolicy` cannot represent cleanly. Core config and session state
  still needed to accept profile-backed permissions without forcing every
  profile through the strict legacy bridge, which rejected valid runtime
  profiles such as direct write roots.
  
  The unrelated CI/test hardening that previously rode along with this PR
  has been split into #19683 so this PR stays focused on the permissions
  model migration.
  
  ## What Changed
  
  - Adds `Permissions.permission_profile` and
  `SessionConfiguration.permission_profile` as constrained runtime state,
  while keeping `sandbox_policy` as a legacy compatibility projection.
  - Introduces profile setters that keep `PermissionProfile`, split
  filesystem/network policies, and legacy `SandboxPolicy` projections
  synchronized.
  - Uses a compatibility projection for requirement checks and legacy
  consumers instead of rejecting profiles that cannot round-trip through
  `SandboxPolicy` exactly.
  - Updates config loading, config overrides, session updates, turn
  context plumbing, prompt permission text, sandbox tags, and exec request
  construction to carry profile-backed runtime permissions.
  - Preserves configured deny-read entries and `glob_scan_max_depth` when
  command/session profiles are narrowed.
  - Adds `PermissionProfile::read_only()` and
  `PermissionProfile::workspace_write()` presets that match legacy
  defaults.
  
  ## 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/19606).
  * #19395
  * #19394
  * #19393
  * #19392
  * __->__ #19606

  Michael Bolin · 2026-04-26 13:29:54 -07:00
  4d7ce3447d
• fix(tui): reflow scrollback on terminal resize (#18575)

  Fixes multiple scrollback and terminal resize issues: #5538, #5576,
  #8352, #12223, #16165, and #15380.
  
  ## Why
  
  Codex writes finalized transcript output into terminal scrollback after
  wrapping it for the current viewport width. A later terminal resize
  could leave that scrollback shaped for the old width, so wider windows
  kept narrow output and narrower windows could show stale wrapping
  artifacts until enough new output replaced the visible area.
  
  This is also the foundation PR for responsive markdown tables. Table
  rendering needs finalized transcript content to be width-sensitive after
  insertion, not only while content is first streaming. Markdown table
  rendering itself stays in #18576.
  
  ## Stack
  
  - PR1: resize backlog reflow and interrupt cleanup
  - #18576: markdown table support
  
  ## What Changed
  
  - Rebuild source-backed transcript history when the terminal width
  changes. `terminal_resize_reflow` is introduced through the experimental
  feature system, but is enabled by default for this rollout so we can
  validate behavior across real terminals.
  - Preserve assistant and plan stream source so finalized streaming
  output can participate in resize reflow after consolidation.
  - Debounce resize work, but force a final source-backed reflow when a
  resize happened during active or unconsolidated streaming output.
  - Clear stale pending history lines on resize so old-width wrapped
  output is not emitted just before rebuilt scrollback.
  - Bound replay work with `[tui.terminal_resize_reflow].max_rows`:
  omitted uses terminal-specific defaults, `0` keeps all rendered rows,
  and a positive value sets an explicit cap. The cap applies both while
  initially replaying a resumed transcript into scrollback and when
  rebuilding scrollback after terminal resize.
  - Consolidate interrupted assistant streams before cleanup, then clear
  pending stream output and active-tail state consistently.
  - Move resize reflow and thread event buffering helpers out of `app.rs`
  into dedicated TUI modules.
  - Add focused coverage for resize reflow, feature-gated behavior,
  streaming source preservation, interrupted output cleanup,
  unicode-neutral text, terminal-specific row caps, and composer/layout
  stability.
  
  ## Runtime Bounds
  
  Resize reflow keeps only the most recent rendered rows when a row cap is
  active. The default is `auto`, which maps to the detected terminal's
  default scrollback size where Codex can identify it: VS Code `1000`,
  Windows Terminal `9001`, WezTerm `3500`, and Alacritty `10000`.
  Terminals without a dedicated mapping use the conservative fallback of
  `1000` rows. Users can override this with `[tui.terminal_resize_reflow]
  max_rows = N`, or set `max_rows = 0` to disable row limiting.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui reflow`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui
  transcript_reflow`
  - `just fix -p codex-tui`
  - PR CI in progress on the squashed branch

  Felipe Coury · 2026-04-25 22:00:32 -03:00
  5591912f0b
• Remove js_repl feature (#19410)
  Curtis 'Fjord' Hawthorne · 2026-04-24 17:49:29 -07:00
  8a559e7938
• [codex] add non-local thread store regression harness (#19266)

  - Add an integration test that guarantees nothing gets written to codex
  home dir or sqlite when running a rollout with a non-local ThreadStore
  - Add an in-memory "spy" ThreadStore for tests like this
  
  Note I could not find a good way to also ensure there were no filesystem
  _reads_ that didn't go through threadstore. I explored a more elaborate
  sandboxed-subprocess approach but it isn't platform portable and felt
  like it wasn't (yet) worth it.

  Tom · 2026-04-24 15:45:44 -07:00
  588f7a9fc4
• 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
• Add agents.interrupt_message for interruption markers (#19351)

  ## Why
  
  Agent interruptions currently always persist a model-visible
  interrupted-turn marker before emitting `TurnAborted`. That marker is
  useful by default because it gives the next model turn context about a
  deliberately interrupted task, but some deployments need to suppress
  that history injection entirely while still keeping the client-visible
  interruption event.
  
  ## What changed
  
  - Add `[agents] interrupt_message = false` to disable the model-visible
  interrupted-turn marker.
  - Resolve the setting into `Config::agent_interrupt_message_enabled`,
  defaulting to `true` so existing behavior is unchanged.
  - Apply the setting to both live interrupted turns and interrupted fork
  snapshots.
  - Keep emitting `TurnAborted` even when the history marker is disabled.
  - Regenerate `core/config.schema.json` for the new
  `agents.interrupt_message` field.
  
  ## Testing
  
  - `cargo test -p codex-core load_config_resolves_agent_interrupt_message
  -- --nocapture`
  - `cargo test -p codex-core
  disabled_interrupted_fork_snapshot_appends_only_interrupt_event --
  --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_interrupted_marker_uses_developer_input_message --
  --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_followup_task_can_disable_interrupted_marker --
  --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_followup_task_interrupts_busy_child_without_losing_message
  -- --nocapture`
  - `cargo check -p codex-core`

  jif-oai · 2026-04-24 16:02:45 +02:00
  28742866c7
• 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 remote thread config endpoint (#18908)

  ## Why
  
  App-server needs a way to fetch thread-scoped config from the remote
  thread config service when the user config opts into that behavior. This
  mirrors the existing experimental remote thread store endpoint while
  keeping local/noop behavior as the default.
  
  Startup paths also need to avoid silently dropping the remote config
  endpoint after the first config load. The stdio app-server path
  discovers the endpoint from the initial config and installs the real
  thread config loader for later config builds, while in-process clients
  used by TUI/exec now select the same remote loader directly from their
  provided config.
  
  ## What changed
  
  - Added `experimental_thread_config_endpoint` to `ConfigToml`, `Config`,
  and `core/config.schema.json`.
  - Added config parsing coverage for the new setting.
  - Updated app-server startup to select `RemoteThreadConfigLoader` from
  the initially loaded config, falling back to `NoopThreadConfigLoader`
  when unset.
  - Let `ConfigManager` replace its thread config loader after startup
  discovery so later config loads use the selected loader.
  - Updated in-process app-server client startup to pass
  `RemoteThreadConfigLoader` when its config has
  `experimental_thread_config_endpoint` set.
  
  ## Verification
  
  - Added `experimental_thread_config_endpoint_loads_from_config_toml`.
  - Added
  `runtime_start_args_use_remote_thread_config_loader_when_configured`.
  - Ran `cargo check -p codex-app-server --lib`.
  - Ran `cargo test -p codex-app-server-client`.

  Rasmus Rygaard · 2026-04-23 11:46:06 -07:00
  f11583b8f6
• Reject agents.max_threads with multi_agent_v2 (#19129)

  ## Why
  
  `multi_agent_v2` uses the v2 agent lifecycle, so accepting the legacy
  `agents.max_threads` limit alongside it creates conflicting
  configuration semantics. Config load should fail early with a clear
  error instead of allowing both knobs to be set.
  
  ## What Changed
  
  - During config load, detect when the effective `multi_agent_v2` feature
  is enabled and `agents.max_threads` is explicitly set.
  - Return an `InvalidInput` error: `agents.max_threads cannot be set when
  multi_agent_v2 is enabled`.
  
  ## Verification
  
  - `cargo test -p codex-core multi_agent_v2_rejects_agents_max_threads`
  passed locally with a temporary focused test for this behavior.
  - `cargo test -p codex-core` was also run; the new focused path passed,
  but the crate suite has unrelated pre-existing failures in managed
  config/proxy/request-permissions tests.

  jif-oai · 2026-04-23 13:31:54 +02:00
  d3b044938d
• feat: Warn and continue on unknown feature requirements (#19038)

  Requirements feature flags now fail open like config feature flags, but
  with a startup warning.
  
  <img width="443" height="68" alt="image"
  src="https://github.com/user-attachments/assets/76767fa7-8ce8-4fc7-8a09-902fcdda6298"
  />

  xl-openai · 2026-04-22 22:50:44 -07:00
  951be1a8a1
• Default Fast service tier for eligible ChatGPT plans (#19053)

  ## Why
  
  Enterprise and business-like ChatGPT plans should get Codex's Fast
  service tier by default when the user or caller has not made an explicit
  service-tier choice. At the same time, callers need a durable way to
  choose standard routing without adding a new persisted `standard`
  service tier value. This keeps existing config compatibility while
  letting core own the managed default policy.
  
  ## What changed
  
  - Resolve the effective service tier in core at session creation:
  explicit `fast` or `flex` wins, explicit null/clear or
  `[notice].fast_default_opt_out = true` resolves to standard routing, and
  otherwise eligible ChatGPT plans resolve to Fast when FastMode is
  enabled.
  - Add `[notice].fast_default_opt_out` as the persisted opt-out marker
  for managed Fast defaults.
  - Treat app-server/TUI `service_tier: null` as an explicit
  standard/clear choice by preserving that intent through config loading.
  - Update TUI rendering to use core's effective service tier for startup
  and status surfaces while still keeping `config.service_tier` as the
  explicit configured choice.
  - Update `/fast off` to clear `service_tier`, persist the opt-out
  marker, and send explicit standard for subsequent turns.
  
  ## Verification
  
  - Added unit coverage for config override/notice handling, service-tier
  resolution, runtime null clearing, and `/fast off` turn propagation.
  - `cargo build -p codex-cli`
  
  Full test suite was not run locally per author request.

  Shijie Rao · 2026-04-22 21:54:44 -07:00
  02170996e6
• 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
• 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) policy config (#18959)

  ## Summary
  Allow users to customize their own auto-review policy config.
  
  ## Testing
  - [x] added config_tests

  Dylan Hurd · 2026-04-22 10:33:02 -07:00
  78593d72ea