162 Commits

• feat: show enterprise monthly credit limits in status (#24812)

  ## Summary
  
  Enterprise users can have an effective monthly credit limit, but Codex
  `/status` currently drops that metadata from the account-usage response.
  
  This change adds the optional `spend_control.individual_limit`
  projection to the existing rate-limit snapshot flow. The backend client
  reads the monthly limit, app-server exposes it as `individualLimit`, and
  the TUI renders a `Monthly credit limit` row through the existing
  progress-bar renderer.
  
  When the backend does not return an effective monthly limit, existing
  rate-limit behavior is unchanged.
  
  ## Existing backend state
  
  The account-usage backend already returns the effective monthly limit
  and current usage together:
  
  ```json
  {
    "spend_control": {
      "reached": false,
      "individual_limit": {
        "limit": "25000",
        "used": "8000",
        "remaining": "17000",
        "used_percent": 32,
        "remaining_percent": 68,
        "reset_after_seconds": 86400,
        "reset_at": 1778137680
      }
    }
  }
  ```
  
  Before this change, Codex projected rolling `primary` and `secondary`
  windows plus `credits`. It ignored `spend_control.individual_limit`, so
  app-server clients and `/status` could not render the monthly cap.
  
  The updated flow is:
  
  ```text
  account usage backend
    -> backend-client reads spend_control.individual_limit
    -> existing rate-limit snapshot carries optional individual_limit
    -> app-server exposes optional individualLimit
    -> TUI renders Monthly credit limit
  ```
  
  ## App-server contract
  
  `account/rateLimits/read` and sparse `account/rateLimits/updated`
  notifications now include an additive nullable
  `rateLimits.individualLimit` field:
  
  ```json
  {
    "individualLimit": {
      "limit": "25000",
      "used": "8000",
      "remainingPercent": 68,
      "resetsAt": 1778137680
    }
  }
  ```
  
  In an `account/rateLimits/read` response, `null` means no monthly limit
  is available. `account/rateLimits/updated` remains a sparse rolling
  notification: clients merge available values into their most recent
  `account/rateLimits/read` snapshot or refetch. Nullable account metadata
  in a rolling notification does not clear a previously observed value.
  
  ## Design decisions
  
  - Extend the existing rate-limit snapshot instead of introducing a
  separate request or wire-level update protocol.
  - Keep the Codex projection narrow: `/status` needs the effective limit,
  current usage, remaining percentage, and reset timestamp.
  - Render the monthly row through the existing progress-bar renderer,
  with one optional detail line for `8,000 of 25,000 credits used`.
  - Keep the backend response optional so existing accounts and older
  usage states preserve their current behavior.
  - Preserve cached monthly metadata when sparse rolling notifications
  omit it. Live account-usage reads remain authoritative and can clear a
  removed limit.
  
  ## Visual evidence
  
  ```text
   Monthly credit limit:   [██████████████░░░░░░] 68% left (resets 07:08 on 7 May)
                           8,000 of 25,000 credits used
  ```
  
  Snapshot:
  `codex-rs/tui/src/status/snapshots/codex_tui__status__tests__status_snapshot_includes_enterprise_monthly_credit_limit.snap`
  
  ## Testing
  
  Tests: generated app-server schema verification, protocol tests,
  backend-client tests, app-server integration coverage, TUI snapshot
  coverage, formatting, and workspace lint cleanup.

  efrazer-oai · 2026-06-01 21:25:42 -07:00
  c8e5db16c9
• app-server: remove experimental persist_extended_history bool flag (#25712)

  ## Summary
  
  Remove the dead experimental `persistExtendedHistory` app-server flag
  and collapse rollout persistence to the single policy app-server already
  used.
  
  ## What Changed
  
  - Removed `persistExtendedHistory` from v2 thread start/resume/fork
  params and deleted its deprecation notice path.
  - Removed the persistence-mode enums and plumbing through core, rollout,
  and thread-store.
  - Made rollout filtering mode-free, keeping the existing limited
  persisted-history behavior.
  
  ## Test Plan
  
  - `just write-app-server-schema`
  - `cargo nextest run --no-fail-fast -p codex-app-server-protocol
  schema_fixtures`
  - `cargo nextest run --no-fail-fast -p codex-app-server
  thread_shell_command_history_responses_exclude_persisted_command_executions`
  - `cargo nextest run --no-fail-fast -p codex-rollout -p
  codex-thread-store`
  - final `rg` for removed flag/type names

  Owen Lin · 2026-06-01 23:33:42 +00:00
  11e0f3d3ae
• Add goal extension idle continuation (#25060)

  ## Why
  
  The goal extension needs a way to resume an active goal after the thread
  becomes idle, but the old core goal runtime should not be refactored as
  part of this step. The missing piece is a small core-owned turn-start
  primitive: let an extension ask for a normal model turn only when the
  thread is idle, and otherwise fail without injecting into whatever is
  currently active.
  
  ## What Changed
  
  - Adds `CodexThread::try_start_turn_if_idle(...)` as the narrow
  extension-facing primitive for synthetic idle work.
  - Implements the session side so it refuses to start when:
    - the provided input is empty,
    - the session is in plan mode,
    - a turn is already active, or
    - trigger-turn mailbox work is pending.
  - Gives trigger-turn mailbox work priority if it appears while the idle
  turn is being prepared.
  - Wires `GoalExtension::on_thread_idle` to read the active persisted
  goal and submit the continuation prompt through this idle-only
  primitive.
  - Keeps the legacy core goal continuation implementation in place
  instead of folding it into this PR.
  
  ## Behavior
  
  This is intentionally best-effort. If `try_start_turn_if_idle` observes
  that the thread is not idle, or that higher-priority mailbox work should
  run first, it returns the input to the caller. The goal extension drops
  that continuation prompt and waits for a future idle opportunity instead
  of injecting stale synthetic goal text into an active turn.
  
  ## Validation
  
  - `just test -p codex-core
  try_start_turn_if_idle_rejects_active_turn_without_injecting`
  - `just test -p codex-goal-extension`

  jif-oai · 2026-06-01 10:42:01 +02:00
  f1b1b64005
• Set multi-agent v2 dogfood defaults (#25266)

  ## Summary
  - default multi-agent v2 to direct-model-only tools so code mode does
  not wrap subagent tools
  - add default root/subagent team prompts aligned with dogfood training
  assumptions
  - tighten spawn-agent model override wording to prefer the inherited
  model by default
  
  ## Tests
  - just fmt
  - just test -p codex-core
  spawn_agent_description_lists_visible_models_and_reasoning_efforts
  - just test -p codex-core
  multi_agent_v2_default_session_thread_cap_counts_root
  - just test -p codex-rollout-trace
  - just fix -p codex-core
  - just fix -p codex-rollout-trace
  
  Note: a broad just test -p codex-core run was attempted locally, but
  this sandbox produced unrelated environment failures around
  sandbox-exec, missing test_stdio_server, and realtime timeouts.

  jif-oai · 2026-06-01 10:24:46 +02:00
  8d49394feb
• store and expose parent_thread_id on Threads (#25113)

  ## Why
  
  This PR
  https://github.com/openai/codex/pull/24161#discussion_r3325692763
  revealed a subagent data modeling issue, where we overloaded
  `forked_from_id` to also mean `parent_thread_id`. That's incorrect since
  guardian and review subagents can be a subagent and NOT fork the main
  thread's history.
  
  The solution here is to explicitly store a new `parent_thread_id` on
  `SessionMeta`, alongside `forked_from_id` which already exists. While
  we're at it, also expose it in the app-server protocol on the `Thread`
  object.
  
  A thread->subagent relationship and a fork of thread history are
  orthogonal concepts.
  
  ## What Changed
  
  - Added top-level `parent_thread_id` persistence on `SessionMeta` and
  runtime/session plumbing through `SessionConfiguredEvent`,
  `CodexSpawnArgs`, `SessionConfiguration`, `ThreadConfigSnapshot`,
  `TurnContext`, and `ModelClient`.
  - Made turn metadata, request headers, analytics, and subagent-start
  events read the separate runtime/top-level parent field instead of
  deriving general parent lineage from `SessionSource` or
  `forked_from_thread_id`.
  - Passed parent lineage separately at delegated subagent, review,
  guardian, agent-job, and multi-agent spawn construction sites;
  copied-history fork lineage remains derived only from `InitialHistory`.
  - Persisted and exposed parent lineage through rollout/thread-store
  projections and app-server v2 `Thread.parentThreadId`.
  - Updated app-server README text and regenerated app-server schema
  fixtures for the additive `parentThreadId` response field.

  Owen Lin · 2026-06-01 04:33:20 +00:00
  cf0911076f
• Use internal model context fragments for goal steering (#24918)

  ## Why
  
  Goal steering is one form of runtime-owned model context, but the old
  `<goal_context>` wrapper made the contextual-fragment hiding path
  goal-specific. Using a source-labeled internal context fragment gives
  core and extensions a shared shape for hidden model steering while
  keeping those prompts out of visible turn history.
  
  The change also keeps legacy `<goal_context>` messages recognized as
  hidden contextual input so existing stored history does not start
  rendering old goal-steering prompts as user-visible turn items.
  
  ## What Changed
  
  - Replaces `GoalContext` with `InternalModelContextFragment` plus a
  validated `InternalContextSource`.
  - Renders goal steering as `<codex_internal_context
  source="goal">...</codex_internal_context>`.
  - Updates core goal steering and `ext/goal` steering to inject the new
  internal-context fragment.
  - Updates contextual-fragment, event-mapping, goal, and session tests
  for the new wrapper.
  
  ## Test Coverage
  
  - Adds coverage for detecting the new internal model context fragment.
  - Preserves coverage for hiding legacy `<goal_context>` fragments.
  - Verifies invalid internal context sources are rejected and arbitrary
  context tags are not hidden.
  - Updates goal steering/session assertions to expect the new
  `source="goal"` wrapper.

  jif-oai · 2026-05-29 10:28:25 +02:00
  740d942f90
• Surface filesystem permission profiles in prompt context (#23924)

  ## Summary
  Some permission profiles can encode filesystem reads that should remain
  unavailable to the agent. Before this change, the model-visible context
  and automatic approval review prompt summarized the effective
  permissions as a legacy sandbox mode, which can omit permission-profile
  filesystem entries from escalation decisions.
  
  For example, a profile can grant workspace access while denying a
  private subtree across every workspace root:
  
  ```toml
  default_permissions = "restricted-workspace"
  
  [permissions.restricted-workspace.workspace_roots]
  "/Users/alice/project" = true
  "/Users/alice/other-project" = true
  
  [permissions.restricted-workspace.filesystem]
  ":minimal" = "read"
  
  [permissions.restricted-workspace.filesystem.":workspace_roots"]
  "." = "write"
  "private" = "deny"
  "private/**" = "deny"
  ```
  
  The context window now describes the workspace roots and effective
  filesystem side of the `PermissionProfile` directly, with deny entries
  marked as non-escalatable:
  
  ```xml
  <environment_context>
    <cwd>/Users/alice/project</cwd>
    <shell>zsh</shell>
    <filesystem><workspace_roots><root>/Users/alice/project</root><root>/Users/alice/other-project</root></workspace_roots><permission_profile type="managed"><file_system type="restricted"><entry access="read"><special>:minimal</special></entry><entry access="write"><path>/Users/alice/project</path></entry><entry access="write"><path>/Users/alice/other-project</path></entry><entry access="deny" escalatable="false"><path>/Users/alice/project/private</path></entry><entry access="deny" escalatable="false"><path>/Users/alice/other-project/private</path></entry><entry access="deny" escalatable="false"><glob>/Users/alice/project/private/**</glob></entry><entry access="deny" escalatable="false"><glob>/Users/alice/other-project/private/**</glob></entry></file_system></permission_profile></filesystem>
  </environment_context>
  ```
  
  Managed requirements can impose the same kind of deny-read restriction:
  
  ```toml
  [permissions.filesystem]
  deny_read = [
    "/Users/alice/project/private",
    "/Users/alice/project/private/**",
  ]
  ```
  
  The automatic approval review prompt also receives the parent turn's
  denied-read context, so review decisions can account for the active
  permission profile.
  
  ## What Changed
  - Render the effective filesystem profile in `<environment_context>`,
  including profile type, filesystem entries, workspace roots, and
  non-escalatable deny entries.
  - Persist effective `workspace_roots` in `TurnContextItem` so
  resumed/replayed context does not have to bind `:workspace_roots`
  through legacy `cwd` fallback.
  - Add explicit permission instructions that denied reads are policy
  restrictions, not escalation targets.
  - Pass the parent turn's denied-read context into automatic approval
  reviews.
  - Add targeted coverage for prompt rendering, workspace-root
  materialization, replay context, and review prompt context.
  - Keep the prompt-context test expectations platform-aware so the same
  filesystem rendering assertions pass on Unix and Windows paths.
  
  ## Testing
  - `just test -p codex-core
  context::environment_context::tests::serialize_environment_context_with_full_filesystem_profile`
  - `just test -p codex-core
  context::environment_context::tests::turn_context_item_filesystem_uses_workspace_roots_instead_of_cwd`
  - `just test -p codex-core
  context::permissions_instructions::permissions_instructions_tests::builds_permissions_from_profile_with_denied_reads`
  - `just fix -p codex-core`
  
  I also attempted `just test -p codex-core`; the changed prompt-context
  tests passed, but the full local run did not complete cleanly in this
  sandboxed macOS environment due unrelated user-shell `CODEX_SANDBOX*`
  expectations and integration-test timeouts.

  Michael Bolin · 2026-05-28 14:56:53 -07:00
  e7dda8070e
• [codex] Add user input client ids (#24653)

  ## Summary
  
  Adds an optional `clientId` field to app-server v2 `UserInput` and
  carries it through the core `UserInput` model so clients can correlate
  echoed user input items without relying on payload equality.
  
  ## Details
  
  - Adds `client_id: Option<String>` to core `UserInput` variants.
  - Exposes the v2 app-server field as `clientId` on the wire and in
  generated TypeScript.
  - Preserves the id when converting between app-server v2 and core
  protocol types.
  - Regenerates app-server schema fixtures.
  
  ## Validation
  
  - `just fmt`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-protocol`
  - `git diff --check`

  Alexi Christakis · 2026-05-28 14:54:39 -07:00
  e92c952b2e
• Wire task completion into thread-idle lifecycle (#24928)

  ## Why
  
  #24744 introduced the thread idle lifecycle hook so idle continuation
  can be owned by lifecycle contributors instead of hard-coded goal
  runtime plumbing. Task completion still called
  `goal_runtime_apply(GoalRuntimeEvent::MaybeContinueIfIdle)` directly, so
  the post-turn idle transition remained goal-specific and did not notify
  generic thread lifecycle contributors.
  
  ## What Changed
  
  - Add `Session::emit_thread_idle_lifecycle_if_idle()` to gate idle
  emission on both no active turn and no queued trigger-turn mailbox work.
  - Call that helper when a task clears the active turn, replacing the
  direct `GoalRuntimeEvent::MaybeContinueIfIdle` path.
  - Cover the behavior with `codex-core` session tests for emitting after
  task completion and suppressing idle emission while trigger-turn mailbox
  work is pending.
  
  ## Verification
  
  - New tests in `core/src/session/tests.rs` exercise the idle lifecycle
  emission and trigger-turn mailbox guard.

  jif-oai · 2026-05-28 20:05:41 +02:00
  462deb0426
• [codex] Store pending response items directly (#24865)
  pakrym-oai · 2026-05-28 07:23:08 -07:00
  1c7832ffa3
• Add turn error lifecycle contributor (#24916)

  Summary
  - Add TurnErrorInput and TurnLifecycleContributor::on_turn_error to the
  extension API.
  - Emit the turn-error lifecycle from core turn error paths, including
  usage limit failures.
  - Add direct lifecycle coverage for the emitted error facts and stores.
  
  Tests
  - just fmt
  - git diff --check
  - Not run: full tests or clippy (per instructions)

  jif-oai · 2026-05-28 16:13:54 +02:00
  e7d156eb08
• fix(linux-sandbox): preserve shell cleanup on interruption (#22729)

  ## Why
  Interrupted `shell_command` calls can race with the outer tool-dispatch
  cancellation path. When that happens, the runtime future may be dropped
  before the spawned process gets a chance to run `SIGTERM` cleanup. For
  bwrapd-backed Linux sandbox commands, that can leave synthetic
  protected-path mount bookkeeping such as `.git/.codex` registrations
  under `/tmp` behind after a TUI interruption.
  
  The relevant cancellation points are the outer dispatch race in
  [`core/src/tools/parallel.rs`](https://github.com/openai/codex/blob/bd184ba84703cc924921ed883f0cf17d3dba60ff/codex-rs/core/src/tools/parallel.rs#L91-L132)
  and the process shutdown logic in
  [`core/src/exec.rs`](https://github.com/openai/codex/blob/bd184ba84703cc924921ed883f0cf17d3dba60ff/codex-rs/core/src/exec.rs#L1367-L1393).
  
  ## What changed
  - Keep `shell_command` dispatch alive long enough for the runtime to
  finish cancellation cleanup instead of immediately returning the
  synthetic aborted response.
  - Fold shell-turn cancellation into the existing `ExecExpiration` path
  in
  [`core/src/tools/runtimes/shell.rs`](https://github.com/openai/codex/blob/bd184ba84703cc924921ed883f0cf17d3dba60ff/codex-rs/core/src/tools/runtimes/shell.rs#L267-L274),
  so cancellation and timeout behavior stay centralized.
  - On cancellation, send `SIGTERM` first, wait briefly for cleanup to
  run, then hard-kill any remaining descendants in the original process
  group.
  - Treat `ESRCH` as an already-gone process-group cleanup case in
  `codex-utils-pty`, which keeps best-effort teardown from surfacing a
  stale-process race as an error.
  
  ## Verification
  - `cargo test -p codex-core cancellation`
  - Added regression coverage for:
    - `shell_tool_cancellation_waits_for_runtime_cleanup`
    - `process_exec_tool_call_cancellation_allows_sigterm_cleanup`

  viyatb-oai · 2026-05-27 12:59:11 -07:00
  9152ebd289
• Add forked_from_thread_id turn metadata (#24160)

  ## Why
  
  When Codex calls responsesapi, we currently send `session_id`,
  `thread_id`, and `turn_id` among other things as
  `client_metadata["x-codex-turn-metadata"]`. This PR adds
  `forked_from_thread_id` which helps explain the "lineage" of a forked
  thread.
  
  ## What's changed
  
  - Track the immediate history source copied into a forked thread through
  thread/session creation, including subagent and review turn metadata
  paths.
  - Include `forked_from_thread_id` in Codex turn metadata while
  preventing turn-scoped Responses API client metadata from overwriting
  Codex-owned lineage fields.
  - Add coverage for fork lineage in turn metadata and the app-server
  Responses API request path.

  Owen Lin · 2026-05-26 14:05:28 -07:00
  1911021c0e
• Add experimental turn additional context (#24154)

  ## Summary
  
  Adds experimental `additionalContext` support to `turn/start` and
  `turn/steer` so clients can provide ephemeral external context, such as
  browser or automation state, without turning that plumbing into a
  visible user prompt or triggering user-prompt lifecycle behavior.
  
  ## API Shape
  
  The parameter shape is:
  
  ```ts
  additionalContext?: Record<string, {
    value: string
    kind: "untrusted" | "application"
  }> | null
  ```
  
  Example:
  
  ```json
  {
    "additionalContext": {
      "browser_info": {
        "value": "Active tab is CI failures.",
        "kind": "untrusted"
      },
      "automation_info": {
        "value": "CI rerun is in progress.",
        "kind": "application"
      }
    }
  }
  ```
  
  The keys are opaque and caller-defined.
  
  ## Context Injection
  
  When provided, accepted entries are inserted into model context as
  hidden contextual message items, not as visible thread user-message
  items.
  
  `kind: "untrusted"` entries are inserted with role `user`:
  
  ```text
  <external_${key}>${value}</external_${key}>
  ```
  
  `kind: "application"` entries are inserted with role `developer`:
  
  ```text
  <${key}>${value}</${key}>
  ```
  
  Values are not escaped. Each value is truncated to 1k approximate tokens
  before wrapping.
  
  For `turn/start`, accepted additional context is inserted before normal
  user input. For `turn/steer`, additional context is merged only when the
  steer includes non-empty user input; context-only steers still reject as
  empty input.
  
  ## Dedupe Strategy
  
  `AdditionalContextStore` lives on session state and stores the latest
  complete additional-context map.
  
  Each `turn/start` or non-empty `turn/steer` treats its
  `additionalContext` as the current complete set of values. Entries are
  injected only when the key is new or the exact entry for that key
  changed, including `value` or `kind`. After merging, the store is
  replaced with the provided map, so omitted keys are removed from the
  retained set and can be injected again later if reintroduced.
  
  Omitting `additionalContext`, passing `null`, or passing an empty object
  resets the store to empty and injects nothing.
  
  ## What Changed
  
  - Threads experimental v2 `additionalContext` through app-server into
  core turn start and steer handling.
  - Adds separate contextual fragment types for untrusted user-role
  context and application developer-role context.
  - Uses pending response input items so additional context can be
  combined with normal user input without treating it as prompt text.
  - Adds integration coverage for start/steer flow, role routing,
  dedupe/reset behavior, deletion/re-add behavior, hook-blocked input
  behavior, empty context-only steer rejection, external-fragment marker
  matching, and truncation.

  pakrym-oai · 2026-05-26 13:02:34 -07:00
  768848ab6f
• Move MCP tool naming mode into manager (#21576)

  ## Why
  
  The `non_prefixed_mcp_tool_names` feature should be applied where MCP
  tools become model-visible, not by remapping names later in core.
  Keeping the decision in `McpConnectionManager` construction makes
  `ToolInfo` the single shaped view that spec building, deferred tool
  search, routing, and unavailable-tool placeholders can consume directly.
  
  This also preserves the existing external behavior while the feature is
  off, and keeps the feature-on behavior for code mode and hooks explicit
  at the manager boundary.
  
  ## What Changed
  
  - Add `McpToolNameMode` to `codex-mcp` and flow it through `McpConfig`
  into `McpConnectionManager::new`.
  - Normalize MCP `ToolInfo` names in the manager using either
  legacy-prefixed namespaces or non-prefixed namespaces; the legacy path
  adds `mcp__` without restoring the old trailing namespace suffix.
  - Remove the core-side MCP name remapping path so specs, tool search,
  session resolution, and unavailable-tool placeholder construction use
  the manager-provided `ToolName` values directly.
  - Keep code mode flattening on the `__` namespace separator.
  - Preserve hook compatibility by giving non-prefixed MCP hook names
  legacy `mcp__...` matcher aliases.
  - Add/adjust integration and unit coverage for non-prefixed code-mode
  behavior, hook matching with the feature on and off, and manager-level
  legacy prefixing.
  
  ## Testing
  
  - `cargo test -p codex-mcp --lib`
  - `cargo test -p codex-core --lib tools::spec::tests -- --nocapture`
  - `cargo test -p codex-core --lib mcp_tools -- --nocapture`
  - `cargo test -p codex-core --lib mcp_tool_exposure -- --nocapture`
  - `cargo test -p codex-core --test all mcp_tool -- --nocapture`
  - `cargo test -p codex-core --test all search_tool -- --nocapture`
  - `cargo test -p codex-core --test all hooks_mcp -- --nocapture`
  - `cargo test -p codex-core --test all
  code_mode_uses_non_prefixed_mcp_tool_names_when_feature_enabled --
  --nocapture`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-features`

  pakrym-oai · 2026-05-26 08:21:15 -07:00
  ff7513cd83
• package: include zsh fork in Codex package (#23756)

  ## Why
  
  The package layout gives Codex a stable place for runtime helpers that
  should travel with the entrypoint. `shell_zsh_fork` still required users
  to configure `zsh_path` manually, even though we already publish
  prebuilt zsh fork artifacts.
  
  This PR builds on #24129 and uses the shared DotSlash artifact fetcher
  to include the zsh fork in Codex packages when a matching target
  artifact exists. Packaged Codex builds can then discover the bundled
  fork automatically; the user/profile `zsh_path` override is removed so
  the feature uses the package-managed artifact instead of a legacy path
  knob.
  
  ## What Changed
  
  - Added `scripts/codex_package/codex-zsh`, a checked-in DotSlash
  manifest for the current macOS arm64 and Linux zsh fork artifacts.
  - Taught `scripts/build_codex_package.py` to fetch the matching zsh fork
  artifact and install it at `codex-resources/zsh/bin/zsh` when available
  for the selected target.
  - Added package layout validation for the optional bundled zsh resource.
  - Added `InstallContext::bundled_zsh_path()` and
  `InstallContext::bundled_zsh_bin_dir()` for package-layout resource
  discovery.
  - Threaded the packaged zsh path through config loading as the runtime
  `zsh_path` for packaged installs, and removed the config/profile/CLI
  override path.
  - Kept the packaged default zsh override typed as `AbsolutePathBuf`
  until the existing runtime `Config::zsh_path` boundary.
  - Updated app-server zsh-fork integration tests to spawn
  `codex-app-server` from a temporary package layout with
  `codex-resources/zsh/bin/zsh`, matching the new packaged discovery path
  instead of setting `zsh_path` in config.
  - Switched package executable copying from metadata-preserving `copy2()`
  to `copyfile()` plus explicit executable bits, which avoids macOS
  file-flag failures when local smoke tests use system binaries as inputs.
  
  ## Testing
  
  To verify that the `zsh` executable from the Codex package is picked up
  correctly, first I ran:
  
  ```shell
  ./scripts/build_codex_package.py
  ```
  
  which created:
  
  ```
  /private/var/folders/vw/x2knqmks50sfhfpy27nftl900000gp/T/codex-package-pms94kdp/
  ```
  
  so then I ran:
  
  ```
  /private/var/folders/vw/x2knqmks50sfhfpy27nftl900000gp/T/codex-package-pms94kdp/bin/codex exec --enable shell_zsh_fork 'run `echo $0`'
  ```
  
  which reported the following, as expected:
  
  ```
  /private/var/folders/vw/x2knqmks50sfhfpy27nftl900000gp/T/codex-package-pms94kdp/codex-resources/zsh/bin/zsh
  ```
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23756).
  * #23768
  * __->__ #23756

  Michael Bolin · 2026-05-22 17:54:07 -07:00
  c7bcb90f9b
• [codex] Use TurnInput for session task input (#24151)

  ## Why
  
  The idea here is to erase the difference between initial and followup
  inputs to a turn. Followup inputs are already represented as TurnInput.
  
  Eventual goal is not to have explicit on task input at all and pull
  everything from input Q.
  
  ## What Changed
  
  - Changes `SessionTask::run` and the erased `AnySessionTask::run` path
  to accept `Vec<TurnInput>`.
  - Wraps user-submitted spawn input as `TurnInput::UserInput` at the
  session task start boundary.
  - Updates `run_turn` to record initial `TurnInput` using the same hook
  and recording path used for pending input.
  - Keeps review-specific conversion local to `ReviewTask`, where the
  sub-Codex one-shot API still expects `Vec<UserInput>`.
  - Moves the synthetic compact prompt into `CompactTask` and starts
  compact tasks with empty task input.
  
  ## Validation
  
  - `cargo check -p codex-core`
  - `just test -p codex-core -E
  'test(task_finish_emits_turn_item_lifecycle_for_leftover_pending_user_input)
  | test(queued_response_items_for_next_turn_move_into_next_active_turn) |
  test(steered_input_reopens_mailbox_delivery_for_current_turn)'`

  pakrym-oai · 2026-05-22 15:21:08 -07:00
  fbd4efa9ed
• Add trace_id to TurnStartedEvent (#23980)

  ## Why
  [Recent PR](https://github.com/openai/codex/pull/22709) removed
  `trace_id` from `TurnContextItem`.
  
  ## What changed
  - Add to `TurnStartedEvent` so rollout consumers can correlate turns
  with telemetry traces.
  - Note that the branch name is out of date because I originally re-added
  to `TurnContextItem`, but we decided to move it to `TurnStartedEvent`.
  
  ## Verification
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-core --lib
  regular_turn_emits_turn_started_without_waiting_for_startup_prewarm`
  - `cargo test -p codex-core --test all
  emits_warning_when_resumed_model_differs`
  - `cargo test -p codex-rollout`
  - `cargo test -p codex-state`

  mchen-oai · 2026-05-22 13:10:56 -07:00
  3c83e57bfa
• Honor client-resolved service tier defaults (#23537)

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

  Shijie Rao · 2026-05-20 15:57:50 -07:00
  370b13afc9
• core: refresh active permission profiles at runtime (#22931)

  ## Why
  
  Once a named permission profile is selected, runtime state has to keep
  that profile identity intact instead of collapsing back to anonymous
  effective permissions. The session refresh path also needs to rebuild
  profile-derived network proxy state so active profile switches take
  effect consistently.
  
  ## What changed
  
  - Preserve the active permission profile through session updates.
  - Rebuild profile-derived runtime/network configuration when the active
  profile changes.
  - Keep the runtime path aligned with the current session configuration
  APIs.
  - Tighten the affected tests, including the Windows delete-pending
  memory-file case that was intermittently tripping CI.
  
  ## Stack
  
  1. **This PR**: runtime/session/network propagation for active
  permission profiles.
  2. [#23708](https://github.com/openai/codex/pull/23708): TUI selection
  plumbing and guardrail flow.
  3. [#21559](https://github.com/openai/codex/pull/21559): profile-aware
  `/permissions` menu and custom profile display.
  
  <img width="1296" height="906" alt="image"
  src="https://github.com/user-attachments/assets/077fa3a7-80cb-4925-80b1-d2395018d90a"
  />

  viyatb-oai · 2026-05-20 21:55:21 +00:00
  40ad7be2b5
• feat: account active goal progress in the goal extension (#23696)

  ## Why
  
  The goal extension can create and surface goals, but the live
  turn-accounting path still stopped short of persisting active-goal
  progress. That leaves token and wall-clock usage, plus
  `ThreadGoalUpdated` events, out of sync with the extension boundary once
  work actually advances or a goal transitions out of active state.
  
  ## What changed
  
  - Teach `GoalAccountingState` to track the current turn, active goal,
  token deltas, and wall-clock progress snapshots against the persisted
  goal id.
  - Flush active-goal accounting from tool-finish, turn-stop, and
  turn-abort lifecycle hooks, and emit `ThreadGoalUpdated` events when
  persisted progress changes.
  - Route `create_goal` and `update_goal` through the same accounting
  state so new goals start from the right baseline, final progress is
  flushed before status changes, and `update_goal` can mark a goal
  `blocked` as well as `complete`.
  - Keep budget-limited goals accruing through the end of the turn while
  clearing local active-goal state once a turn or explicit update is
  finished.
  - Expand backend and lifecycle coverage around store ids, baseline
  reset, tool-finish accounting, budget-limited carry-through, and
  blocked-goal updates.
  
  ## Testing
  
  - Added focused backend coverage in
  `codex-rs/ext/goal/tests/goal_extension_backend.rs` for baseline reset,
  tool-finish accounting, budget-limited turns, and blocked-goal updates.
  - Extended `codex-rs/core/src/session/tests.rs` to assert that lifecycle
  inputs expose the expected session, thread, and turn store ids.

  jif-oai · 2026-05-20 18:36:37 +02:00
  d4f842f3b3
• feat: expose turn-start metadata to extensions (#23688)

  ## Why
  
  The goal extension needs more context when a turn starts than
  `turn_store` alone provides.
  
  In particular, goal accounting needs the stable turn id, the effective
  collaboration mode, and the cumulative token-usage baseline captured at
  turn start so it can:
  
  - suppress goal accounting for plan-mode turns
  - compute exact per-turn deltas from cumulative `total_token_usage`
  snapshots instead of relying on the most recent usage event alone
  - keep the extension-owned accounting path aligned with the host turn
  lifecycle
  
  ## What
  
  - extend `codex_extension_api::TurnStartInput` to expose `turn_id`,
  `collaboration_mode`, and `token_usage_at_turn_start`
  - pass the full `TurnContext` plus the captured token-usage baseline
  through the turn-start lifecycle emission path
  - initialize goal turn accounting from the turn-start baseline and
  collaboration mode
  - switch goal token accounting to compute deltas from cumulative
  `total_token_usage` snapshots
  - add coverage for the new turn-start lifecycle fields and for
  goal-accounting baseline behavior
  
  ## Testing
  
  - added `turn_start_lifecycle_exposes_turn_metadata_and_token_baseline`
  in `codex-rs/core/src/session/tests.rs`
  - added `ext/goal/tests/accounting.rs` coverage for baseline-aware goal
  accounting and plan-mode suppression

  jif-oai · 2026-05-20 15:54:29 +02:00
  59507b8491
• feat: rename 3 (#23669)

  Just a mechanical renaming

  jif-oai · 2026-05-20 12:07:06 +02:00
  66d5edf825
• Split plugin install discovery into list and request tools (#23372)

  ## Summary
  - Add `list_available_plugins_to_install` as the inventory step for
  plugin and connector install suggestions.
  - Slim `request_plugin_install` so it only handles the actual
  elicitation, instead of carrying the full discoverable list in its
  prompt.
  - Emit send-time telemetry when an install elicitation is dispatched,
  including requested tool identity in the event payload.
  - Emit install-result telemetry through `SessionTelemetry`, including
  tool type, user response action, and completion status.
  - Update registration and tests to cover the new two-step flow while
  keeping the existing `tool_suggest` feature gate unchanged.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core request_plugin_install`
  - `cargo test -p codex-core list_available_plugins_to_install`
  - `cargo test -p codex-core
  install_suggestion_tools_can_be_registered_without_search_tool`
  - `cargo test -p codex-otel
  manager_records_plugin_install_suggestion_metric`
  - `cargo test -p codex-otel
  manager_records_plugin_install_elicitation_sent_metric`
  - `just fix -p codex-core`
  - `just fix -p codex-tools`
  - `just fix -p codex-otel`
  - `cargo check -p codex-core`

  Matthew Zeng · 2026-05-19 14:45:37 -07:00
  8335b56c33
• Add SubagentStart hook (#22782)

  # What
  
  `SubagentStart` runs once when Codex creates a thread-spawned subagent,
  before that child sends its first model request. Thread-spawned
  subagents use `SubagentStart` instead of the normal root-agent
  `SessionStart` hook.
  
  Configured handlers match on the subagent `agent_type`, using the same
  value passed to `spawn_agent`. When no agent type is specified, Codex
  uses the default agent type.
  
  Hook input includes the normal session-start fields plus:
  
  - `agent_id`: the child thread id.
  - `agent_type`: the resolved subagent type.
  
  `SubagentStart` may return `hookSpecificOutput.additionalContext`. That
  context is added to the child conversation before the first model
  request.
  
  # Lifecycle Scope
  
  Only thread-spawned subagents run `SubagentStart`.
  
  Internal/system subagents such as Review, Compact, MemoryConsolidation,
  and Other do not run normal `SessionStart` hooks and do not run
  `SubagentStart`. This avoids exposing synthetic matcher labels for
  internal implementation paths.
  
  Also the `SessionStart` hook no longer fires for subagents, this matches
  behavior with other coding agents' implementation
  
  # Stack
  
  1. This PR: add `SubagentStart`.
  2. #22873: add `SubagentStop`.
  3. #22882: add subagent identity to normal hook inputs.

  Abhinav · 2026-05-19 12:45:08 -07:00
  d661ab70ed
• Make deny canonical for filesystem permission entries (#23493)

  ## Why
  Filesystem permission profiles used `none` for deny-read entries, which
  is less direct than the action the entry actually represents. This
  change makes `deny` the canonical filesystem permission spelling while
  preserving compatibility for older configs that still send `none`.
  
  ## What changed
  - rename `FileSystemAccessMode::None` to `Deny`
  - serialize and generate schemas with `deny` as the canonical value
  - retain `none` only as a legacy input alias for temporary config
  compatibility
  - update filesystem glob diagnostics and regression coverage to use the
  canonical spelling
  - refresh config and app-server schema fixtures to match the new wire
  shape
  
  ## Validation
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core config_toml_deserializes_permission_profiles
  --lib`
  - `cargo test -p codex-core
  read_write_glob_patterns_still_reject_non_subpath_globs --lib`
  
  Earlier in the session, a broad `cargo test -p codex-core` run reached
  unrelated pre-existing failures in timing/snapshot/git-info tests under
  this environment; the targeted surfaces touched by this PR passed
  cleanly.

  viyatb-oai · 2026-05-19 11:03:47 -07:00
  3c76081876
• [codex] Preserve steer input as user input (#23405)

  ## Why
  
  Steered input was queued as a `ResponseInputItem`, then parsed back into
  a user message before recording. That path loses information that only
  exists on `UserInput`, such as UI text elements.
  
  This change keeps turn-local pending input typed as either original
  `UserInput` or existing response items, so steered user input reaches
  user-message recording without being reconstructed from a response item.
  
  ## What changed
  
  - Add `TurnInput` for active-turn pending input.
  - Queue `Session::steer_input` as `TurnInput::UserInput`.
  - Run pending-input hook inspection only for `TurnInput::UserInput`.
  - Process drained pending input item by item: accepted items are
  recorded, blocked items append hook context and are skipped.
  - Remove the pending-input prepend/requeue path.
  
  ## Validation
  
  - `just fmt`
  - `just fix -p codex-core`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core --lib
  session::tests::task_finish_emits_turn_item_lifecycle_for_leftover_pending_user_input
  -- --nocapture`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core --lib steer_input`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core --lib pending_input`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core --test all
  pending_input`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core` (unit tests passed:
  1835 passed, 0 failed, 4 ignored; integration `all` target failed due
  missing helper binaries such as `codex`/`test_stdio_server` plus
  unrelated MCP/search/code-mode expectations)

  pakrym-oai · 2026-05-19 09:47:43 -07:00
  f0663fd4fd
• Remove ToolsConfig from tool planning (#22835)

  ## Why
  
  `codex-tools` is meant to hold reusable tool primitives, but
  `ToolsConfig` had become a second copy of core runtime decisions instead
  of a small shared contract. It carried provider capabilities, auth/model
  gates, permission and environment state, web/search/image feature gates,
  multi-agent settings, and goal availability from core into `codex-tools`
  ([definition](https://github.com/openai/codex/blob/22dd9ad3929253ed24d7ee4f10f238e95ab25f37/codex-rs/tools/src/tool_config.rs#L97),
  [stored on each
  `TurnContext`](https://github.com/openai/codex/blob/22dd9ad3929253ed24d7ee4f10f238e95ab25f37/codex-rs/core/src/session/turn_context.rs#L87)).
  Every session/context variant then had to build and mutate that snapshot
  before assembling tools.
  
  This PR removes that master object instead of renaming it. Tool planning
  now reads the live `TurnContext`, where `codex-core` already owns those
  decisions, while `codex-tools` keeps only reusable primitives and a
  generic `ToolSetBuilder`/`ToolSet` accumulator.
  
  ## What Changed
  
  - Removed `ToolsConfig` / `ToolsConfigParams` from `codex-tools`; the
  crate keeps the shared helpers that still belong there, including
  request-user-input mode selection, shell backend/type resolution,
  `UnifiedExecShellMode`, and `ToolEnvironmentMode`.
  - Replaced config-snapshot planning with `ToolRouter::from_turn_context`
  and a `spec_plan` pipeline over `CoreToolPlanContext`, deriving provider
  capabilities, auth gates, model support, feature gates, environment
  count, goal support, multi-agent options, web search, and image
  generation from the authoritative turn state.
  - Added generic `codex_tools::ToolSetBuilder` / `ToolSet`, plus the
  small core adapter needed to accumulate `CoreToolRuntime` values and
  hosted model specs.
  - Added the `tool_family::shell` registration module and moved
  shell/unified-exec/memory accounting call sites to read the narrow
  per-turn fields directly.
  - Narrowed `TurnContext` to the remaining explicit per-turn fields
  needed by planning: `available_models`, `unified_exec_shell_mode`, and
  `goal_tools_supported`.
  - Reworked MCP exposure and tool-search setup so deferred/direct MCP
  behavior is driven by the current turn rather than a precomputed config
  snapshot.
  - Replaced the large expected-spec fixture tests with focused
  behavior-level coverage for shell tools, environments, goal and
  agent-job gates, MCP direct/deferred exposure, tool search,
  request-plugin-install, code mode, multi-agent mode, hosted tools, and
  extension executor dispatch.
  
  ## Verification
  
  - `cargo check -p codex-tools`
  - `cargo check -p codex-core --lib`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core spec_plan --lib`
  - `cargo test -p codex-core router --lib`

  jif-oai · 2026-05-19 11:24:09 +02:00
  05e171094d
• feat: dedicated goal DB (#23300)

  ## Why
  
  Thread goals are moving toward extension-owned runtime behavior, but
  their persisted state was still stored in the shared state database.
  This makes the goal store harder to isolate and keeps future storage
  splits tied to ad hoc runtime plumbing.
  
  This PR gives goals their own SQLite database while keeping the existing
  `StateRuntime` entry point. The goal is to make this the pattern for
  adding more dedicated runtime databases later.
  
  This also reduce load on existing DB and reduce contention
  
  ## Limitation
  Thread preview from goal is not supported anymore. I'm looking into this
  [EDIT]: solved
  
  ## What changed
  
  - Added a dedicated `goals_1.sqlite` database with its own
  `goals_migrations` directory.
  - Moved `thread_goals` creation into the goals DB migration set.
  - Dropped the old `thread_goals` table from the main state DB with a
  normal state migration. There is intentionally no backfill for existing
  goal rows.
  - Changed `GoalStore` to be backed only by the goals DB pool.
  - Removed the old goal-write side effect that filled empty
  `threads.preview` values from the goal objective.
  - Added shared runtime DB path metadata so startup, telemetry, `codex
  doctor`, and repair handling can include future DBs without bespoke path
  lists.
  - Updated Bazel compile data so the new goals migration directory is
  available to `sqlx::migrate!`.
  
  ## Verification
  
  - `cargo check --tests -p codex-state -p codex-cli -p codex-core -p
  codex-app-server`
  - `just fix -p codex-state`
  - `just fix -p codex-cli`
  - `just fix -p codex-app-server`

  jif-oai · 2026-05-19 11:11:41 +02:00
  ba57aab13a
• Preserve context baselines for full-history agent forks (#23352)

  ## Why
  
  Full-history agent forks should continue from the same prompt prefix as
  the parent. Dropping the stored `TurnContext` baseline forced the child
  to rebuild startup context on its first turn, which can duplicate
  developer instructions and also loses the cache continuity that a
  full-history fork is supposed to preserve.
  
  Truncated forks are different: once we keep only the last N turns, the
  original prompt prefix is no longer intact, so the child must establish
  a fresh context baseline.
  
  ## What changed
  
  - Preserve `RolloutItem::TurnContext` when forking with
  `SpawnAgentForkMode::FullHistory`, and keep dropping it for truncated
  forks:
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control.rs#L98-L126
  and
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control.rs#L399-L401
  - Remove the special-case MultiAgentV2 usage-hint filtering path.
  Full-history fork now preserves the cached developer prefix instead of
  trying to reconstruct part of it.
  - Extend the fork coverage to assert both sides of the contract:
  full-history forks keep the parent reference baseline, while last-N
  forks rebuild context after truncation:
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control_tests.rs#L603-L759
  and
  https://github.com/openai/codex/blob/4090717d94c1fc7f33c9bd122be133a0c5752052/codex-rs/core/src/agent/control_tests.rs#L854-L977
  
  ## Verification
  
  - `cargo test -p codex-core
  spawn_agent_can_fork_parent_thread_history_with_sanitized_items --
  --nocapture`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core
  spawn_agent_fork_last_n_turns_keeps_only_recent_turns -- --nocapture`

  jif-oai · 2026-05-19 10:34:24 +02:00
  826b2182ed
• Remove explicit connector tool undeferral (#23390)

  ## Summary
  - remove the explicit-connector carveout that kept mentioned app tools
  directly exposed instead of deferred
  - keep the surviving explicit-mention reconstruction only for analytics,
  preserving `codex_app_mentioned` and `codex_app_used.invoke_type`
  - trim the now-unused prompt/tool-exposure plumbing and refresh coverage
  around always-defer behavior
  
  ## Verification
  - `just fmt`
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-core` *(one transient timeout in
  `shell_snapshot::tests::macos_zsh_snapshot_includes_sections`; isolated
  rerun passed)*
  - `cargo test -p codex-core --lib
  shell_snapshot::tests::macos_zsh_snapshot_includes_sections`
  - `cargo test -p codex-core --test all
  explicit_app_mentions_respect_always_defer`
  - `cargo test -p codex-core --lib
  mcp_tool_exposure::tests::always_defer_feature_defers_apps_too`
  - `just fix -p codex-analytics`
  - `just fix -p codex-core`

  sayan-oai · 2026-05-18 21:33:46 -07:00
  1dd9bf9a74
• [5 of 7] Replace OverrideTurnContext with ThreadSettings (#22508)

  **Stack position:** [5 of 7]
  
  ## Summary
  
  This PR adds `Op::ThreadSettings`, a queued settings-only update
  mechanism for changing stored thread settings without starting a new
  turn. It also removes the legacy `Op::OverrideTurnContext` in the same
  layer, so reviewers can see the replacement and deletion together.
  
  ## Changes
  
  - Add `Op::ThreadSettings` for settings-only queued updates.
  - Emit `ThreadSettingsApplied` with the effective thread settings
  snapshot after core applies an update.
  - Route settings-only updates through the same submission queue as user
  input.
  - Migrate remaining `OverrideTurnContext` tests and callers to the
  queued `Op::ThreadSettings` path.
  - Delete `Op::OverrideTurnContext` from the core protocol and submission
  loop.
  
  This stack addresses #20656 and #22090.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508) (this PR)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 21:03:51 -07:00
  a668379abf
• [3 of 7] Remove UserTurn (#23075)

  **Stack position:** [3 of 7]
  
  ## Summary
  
  This PR finishes the input-op consolidation by moving the remaining
  `Op::UserTurn` callers onto `Op::UserInput` and deleting `Op::UserTurn`.
  This touches a lot of files, but it is a low-risk mechanical migration.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075) (this PR)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 19:56:00 -07:00
  1a25d8b6e5
• [2 of 7] Remove UserInputWithTurnContext (#23081)

  **Stack position:** [2 of 7]
  
  ## Summary
  
  This PR removes the overlapping `Op::UserInputWithTurnContext` variant
  now that `Op::UserInput` can carry thread settings overrides directly.
  
  ## Stack
  
  1. [1 of 7] [Add thread settings to
  UserInput](https://github.com/openai/codex/pull/23080)
  2. [2 of 7] [Remove
  UserInputWithTurnContext](https://github.com/openai/codex/pull/23081)
  (this PR)
  3. [3 of 7] [Remove
  UserTurn](https://github.com/openai/codex/pull/23075)
  4. [4 of 7] [Placeholder for OverrideTurnContext
  cleanup](https://github.com/openai/codex/pull/23087)
  5. [5 of 7] [Replace OverrideTurnContext with
  ThreadSettings](https://github.com/openai/codex/pull/22508)
  6. [6 of 7] [Add app-server thread settings
  API](https://github.com/openai/codex/pull/22509)
  7. [7 of 7] [Sync TUI thread
  settings](https://github.com/openai/codex/pull/22510)

  Eric Traut · 2026-05-18 19:41:33 -07:00
  e811234484
• [1 of 7] Add thread settings to UserInput (#23080)

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

  Eric Traut · 2026-05-18 18:48:35 -07:00
  84d941d07f
• [codex] Move pending input into input queue (#22728)

  ## Why
  
  Pending model input was split across `Session`, `TurnState`, and the
  agent mailbox. That made it easy for new paths to manage queued user
  input or mailbox delivery outside the intended ownership boundary.
  
  This PR consolidates the model-facing input lifecycle behind the session
  input queue so turn-local pending input, next-turn queued items, and
  mailbox delivery coordination are owned in one place.
  
  ## What Changed
  
  - Added `session/input_queue.rs` to own pending input queues and mailbox
  delivery coordination.
  - Removed the standalone `agent/mailbox.rs` channel wrapper and store
  mailbox items directly in the input queue.
  - Moved pending-input mutations off `TurnState`; `TurnState` now exposes
  the queue-owned storage directly for now.
  - Routed abort cleanup, mailbox delivery phase changes, next-turn queued
  items, and active-turn pending input through `InputQueue`.
  - Boxed stack-heavy agent resume/fork startup futures that the refactor
  pushed over the default test stack.
  - Updated session, task, goal, stream-event, and multi-agent call sites
  and tests to use the new queue ownership.
  
  ## Verification
  
  - `cargo test -p codex-core --lib agent::control::tests`
  - `cargo test -p codex-core --lib
  agent::control::tests::resume_closed_child_reopens_open_descendants --
  --exact`
  - `cargo test -p codex-core --lib
  agent::control::tests::spawn_agent_fork_last_n_turns_keeps_only_recent_turns
  -- --exact`
  - `cargo test -p codex-core --lib
  agent::control::tests::resume_thread_subagent_restores_stored_nickname_and_role
  -- --exact`
  - `cargo test -p codex-core` was also run; it completed with 1814
  passed, 4 ignored, and one timeout in
  `agent::control::tests::resume_thread_subagent_restores_stored_nickname_and_role`,
  which passed when rerun in isolation.

  pakrym-oai · 2026-05-18 15:43:01 -07:00
  afa0101ae2
• [codex] Trim unused TurnContextItem fields (#22709)

  ## Why
  
  `TurnContextItem` is the durable baseline used to reconstruct context
  diffs across resume/fork. Most of the old persisted-only fields on it
  are no longer read, so keeping them in rollout snapshots adds schema
  surface and state that can drift without affecting reconstruction.
  
  `summary` is the exception: older Codex versions require it to
  deserialize `turn_context` records, so keep writing a default
  compatibility value until that schema surface can be removed safely.
  
  ## What changed
  
  - Removed the unused persisted fields from `TurnContextItem`: trace ids,
  user/developer instructions, output schema, and truncation policy.
  - Kept `summary` with a compatibility comment and made
  `TurnContext::to_turn_context_item` write `ReasoningSummary::Auto`
  instead of live turn state.
  - Updated rollout/context reconstruction fixtures for the retained
  summary field.
  
  ## Verification
  
  - `cargo test -p codex-protocol --lib turn_context_item`
  - `cargo test -p codex-rollout
  resume_candidate_matches_cwd_reads_latest_turn_context`
  - `cargo test -p codex-state turn_context`
  - `cargo test -p codex-core --lib
  new_default_turn_captures_current_span_trace_id`
  - `cargo test -p codex-core --lib
  record_initial_history_resumed_turn_context_after_compaction_reestablishes_reference_context_item`
  - `cargo test -p codex-core --test all
  emits_warning_when_resumed_model_differs`
  - `git diff --check`

  pakrym-oai · 2026-05-18 21:54:36 +00:00
  f2368b7de6
• goals: keep pause transitions explicit (#23088)

  ## Problem
  
  This addresses several user-reported cases where active goals were
  paused even though the user had not explicitly asked for that
  transition:
  
  - the guardian approval-review circuit breaker interrupted a turn and
  implicitly paused the goal
  - a shutdown in one app-server instance could pause a goal while a
  second instance was still actively running the same thread
  - steering-style interrupts could also pause the goal even though they
  are meant to redirect work, not stop the goal lifecycle
  
  The common problem was that core treated `TurnAbortReason::Interrupted`
  as an implicit request to transition the persisted goal to `paused`.
  That made unrelated interrupt paths mutate goal state as a side effect,
  and in the multi-app-server case it allowed stale process teardown to
  pause a live goal owned by another running client.
  
  After this change, transitioning a goal to `paused` is always an
  explicit action performed by a client or another intentional goal-state
  mutation. It is never an implicit transition triggered by generic
  interrupt handling.
  
  Refs #22884.
  
  ## What changed
  
  - Remove the goal runtime path that paused active goals after
  interrupted task aborts.
  - Drop the now-unused abort reason from `GoalRuntimeEvent::TaskAborted`.
  - Update the focused regression coverage so an interrupted active goal
  still accounts usage but remains `active`.

  Eric Traut · 2026-05-18 11:58:40 -07:00
  55f6bbc667
• goal: pause continuation loops on usage limits and blockers (#23094)

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

  Eric Traut · 2026-05-18 11:28:53 -07:00
  0d344aca9b
• chore: make token usage async (#23305)

  Make the `TokenUsageContributor` async. This will be required for future
  extension and it's basically free

  jif-oai · 2026-05-18 15:59:06 +02:00
  b631d92170
• chore: isolate thread goal storage behind GoalStore (#23295)

  ## Why
  
  Thread goal persistence is being prepared for a dedicated storage
  boundary. Before that split, goal-specific reads, writes, accounting,
  and cleanup were exposed directly on `StateRuntime`, so core and
  app-server callsites stayed coupled to the full runtime instead of a
  goal-specific store.
  
  This PR introduces that boundary without changing the goal wire API or
  current persistence behavior. Callers now go through
  `StateRuntime::thread_goals()` and the new `GoalStore`, while
  `GoalStore` still uses the existing state DB pool underneath.
  
  ## What changed
  
  - Added `GoalStore` in `state/src/runtime/goals.rs` and exposed it from
  `StateRuntime` via `thread_goals()`.
  - Moved thread-goal reads, writes, status updates, pause, delete, and
  usage accounting onto `GoalStore`.
  - Updated core session goal handling, app-server goal RPCs, resume
  snapshots, and goal tests to use the store boundary.
  - Kept thread deletion responsible for cascading goal cleanup by
  deleting the goal through the store only after a thread row is removed.
  
  ## Testing
  
  - Existing goal persistence, resume, and accounting tests were updated
  to exercise the new `GoalStore` access path.

  jif-oai · 2026-05-18 14:47:05 +02:00
  7ee7fe239f
• Make extension lifecycle hooks async (#23291)

  ## Why
  
  Extension lifecycle hooks sit on the host/extension boundary, but the
  current trait surface only allows synchronous callbacks. That forces
  extensions that need to seed, rehydrate, observe, or flush
  extension-owned state during thread and turn transitions to either block
  inside the callback or move async work into separate host plumbing.
  
  This PR makes those lifecycle callbacks awaitable so extension
  implementations can perform async work directly at the lifecycle point
  where the host already has the relevant session, thread, or turn stores
  available.
  
  ## What changed
  
  - Makes `ThreadLifecycleContributor` and `TurnLifecycleContributor`
  async in `codex-extension-api`.
  - Awaits thread start/resume/stop and turn start/stop/abort lifecycle
  callbacks from `codex-core`.
  - Updates the guardian and memories extensions to implement the async
  lifecycle trait surface.
  - Updates the existing lifecycle tests to use async contributor
  implementations.
  - Adds `async-trait` to the crates that now expose or implement these
  async object-safe lifecycle traits.
  
  ## Testing
  
  - Existing `codex-core` lifecycle tests were updated to cover async
  implementations for thread stop and turn abort ordering.

  jif-oai · 2026-05-18 13:53:58 +02:00
  9531e932ef
• test: construct permission profiles directly (#23030)

  ## Why
  
  `SandboxPolicy` is now a legacy compatibility shape, but several tests
  still built a `SandboxPolicy` only to immediately convert it into
  `PermissionProfile` for APIs that already accept canonical runtime
  permissions. Those detours make it harder to audit where legacy sandbox
  policy is still required, because boundary-only usages are mixed
  together with ordinary test setup.
  
  ## What Changed
  
  - Updated tests in `codex-core`, `codex-exec`, `codex-analytics`, and
  `codex-config` to construct `PermissionProfile` values directly when the
  code under test takes a permission profile.
  - Changed exec-policy, request-permissions, session, and sandbox test
  helpers to pass `PermissionProfile` through instead of converting from
  `SandboxPolicy` internally.
  - Left `SandboxPolicy` in place where tests are explicitly exercising
  legacy compatibility or request/response boundaries.
  
  ## Test Plan
  
  - `cargo test -p codex-analytics -p codex-config`
  - `cargo test -p codex-core --lib safety::tests`
  - `cargo test -p codex-core --lib exec_policy::tests::`
  - `cargo test -p codex-core --lib exec::tests`
  - `cargo test -p codex-core --lib guardian_review_session_config`
  - `cargo test -p codex-core --lib tools::network_approval::tests`
  - `cargo test -p codex-core --lib
  tools::runtimes::shell::unix_escalation::tests`
  - `cargo test -p codex-core --lib managed_network`
  - `cargo test -p codex-core --test all request_permissions::`
  - `cargo test -p codex-exec sandbox`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23030).
  * #23036
  * __->__ #23030

  Michael Bolin · 2026-05-16 12:12:37 -07:00
  d91bc15618
• Improve goal completion usage reporting (#22907)

  ## Why
  
  Goal completion follow-up turns currently receive a preformatted English
  usage sentence such as `time used: 2586 seconds`. That nudges the model
  to echo an awkward raw seconds count in the final reply, even though the
  tool result already exposes structured usage fields like
  `goal.timeUsedSeconds`, `goal.tokensUsed`, and `goal.tokenBudget`.
  
  ## What changed
  
  - Replace the preformatted completion usage sentence with guidance to
  read the structured goal fields from the tool result.
  - Preserve token-budget reporting while allowing the model to phrase
  elapsed time in a concise, human-friendly way that fits the response
  language.
  - Update core coverage for both the generated completion guidance and
  the session flow that forwards it back to the model.
  
  ## Verification
  
  Previously, it would have output a final message indicating that it
  "worked for 303 seconds". Now it shows the following:
  
  <img width="286" height="35" alt="image"
  src="https://github.com/user-attachments/assets/d7011880-9449-46a7-856f-4e50ae00eb45"
  />

  Eric Traut · 2026-05-16 11:49:40 -07:00
  941e7f825e
• Preserve image detail in app-server inputs (#20693)

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

  Curtis 'Fjord' Hawthorne · 2026-05-15 15:04:04 -07:00
  8543e39885
• core: construct test permission profiles directly (#22795)

  ## Why
  
  The core migration is trying to make `PermissionProfile` the shape tests
  and runtime code reason about, leaving `SandboxPolicy` only where legacy
  behavior is explicitly under test. The local
  `permission_profile_for_sandbox_policy()` test helpers kept new
  permission-profile tests mentally tied to the old sandbox model even
  when the equivalent profile is straightforward.
  
  ## What Changed
  
  - Removed the `permission_profile_for_sandbox_policy()` helper from the
  network proxy spec tests and session tests.
  - Replaced legacy conversions for read-only, workspace-write, and
  full-access cases with `PermissionProfile::read_only()`,
  `PermissionProfile::workspace_write()`, and
  `PermissionProfile::Disabled`.
  - Constructed the external-sandbox session test's
  `PermissionProfile::External` directly, while preserving the legacy
  `SandboxPolicy` only where the test still exercises legacy config update
  behavior.
  
  ## How To Review
  
  This PR is intentionally test-only. Review the two touched files and
  check that each replacement preserves the old legacy mapping:
  
  - `SandboxPolicy::new_read_only_policy()` ->
  `PermissionProfile::read_only()`
  - `SandboxPolicy::new_workspace_write_policy()` ->
  `PermissionProfile::workspace_write()`
  - `SandboxPolicy::DangerFullAccess` -> `PermissionProfile::Disabled`
  - `SandboxPolicy::ExternalSandbox { network_access: Restricted }` ->
  `PermissionProfile::External { network: Restricted }`
  
  ## Verification
  
  - `cargo test -p codex-core
  requirements_allowed_domains_are_a_baseline_for_user_allowlist`
  - `cargo test -p codex-core
  start_managed_network_proxy_applies_execpolicy_network_rules`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox`
  - `cargo test -p codex-core
  managed_network_proxy_decider_survives_full_access_start`
  - `just fix -p codex-core`
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22795).
  * #22891
  * __->__ #22795

  Michael Bolin · 2026-05-15 13:09:25 -07:00
  8df2d96860
• app-server: use permission ids and runtime workspace roots (#22611)

  ## Why
  
  This PR builds on [#22610](https://github.com/openai/codex/pull/22610)
  and is the app-server side of the migration from mutable per-turn
  `SandboxPolicy` replacement toward selecting immutable permission
  profiles by id plus mutable runtime workspace roots.
  
  Once permission profiles can carry their own immutable
  `workspace_roots`, app-server no longer needs to mutate the selected
  `PermissionProfile` just to represent thread-specific filesystem
  context. The mutable part now lives on the thread as explicit
  `runtimeWorkspaceRoots`, while `:workspace_roots` remains symbolic until
  the sandbox is realized for a turn.
  
  ## What Changed
  
  - Replaced the v2 permission-selection wrapper surface with plain
  profile ids for `thread/start`, `thread/resume`, `thread/fork`, and
  `turn/start`.
  - Removed the API surface for profile modifications
  (`PermissionProfileSelectionParams`,
  `PermissionProfileModificationParams`,
  `ActivePermissionProfileModification`).
  - Added experimental `runtimeWorkspaceRoots` fields to the thread
  lifecycle and turn-start APIs.
  - Threaded runtime workspace roots through core session/thread
  snapshots, turn overrides, app-server request handling, and command
  execution permission resolution.
  - Kept session permission state symbolic so later runtime root updates
  and cwd-only implicit-root retargeting rebind `:workspace_roots`
  correctly.
  - Updated the embedded clients just enough to send and restore the new
  thread state.
  - Refreshed the generated schema/TypeScript artifacts and the app-server
  README to match the new contract.
  
  ## Verification
  
  Targeted coverage for this layer lives in:
  
  - `codex-rs/app-server-protocol/src/protocol/v2/tests.rs`
  - `codex-rs/app-server/tests/suite/v2/thread_start.rs`
  - `codex-rs/app-server/tests/suite/v2/thread_resume.rs`
  - `codex-rs/app-server/tests/suite/v2/turn_start.rs`
  - `codex-rs/core/src/session/tests.rs`
  
  The key regression checks exercise that:
  
  - `runtimeWorkspaceRoots` resolve against the effective cwd on thread
  start.
  - Profile-declared workspace roots are excluded from the runtime
  workspace roots returned by app-server.
  - A turn-level runtime workspace-root update persists onto the thread
  and is returned by `thread/resume`.
  - A named permission profile selected on one turn remains symbolic so a
  later runtime-root-only turn update changes the actual sandbox writes.
  - A cwd-only turn update retargets the implicit runtime cwd root while
  preserving additional runtime roots.
  - The protocol fixtures and generated client artifacts stay in sync with
  the string-based permission selection contract.
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22611).
  * #22612
  * __->__ #22611

  Michael Bolin · 2026-05-14 23:00:05 -07:00
  8a5306ff88
• permissions: resolve profile identity with constraints (#22683)

  ## Why
  
  This PR is the invariant-cleanup layer that follows the workspace-roots
  base merged in [#22610](https://github.com/openai/codex/pull/22610).
  
  #22610 adds `[permissions.<id>.workspace_roots]` and keeps runtime
  workspace roots separate from the raw permission profile, but its
  in-memory representation is intentionally transitional: `Permissions`
  still carries the selected profile identity next to a constrained
  `PermissionProfile`. That makes APIs such as
  `set_constrained_permission_profile_with_active_profile()` fragile
  because the id and value only mean the right thing when every caller
  keeps them in sync.
  
  This PR introduces a single resolved profile state so profile identity,
  `extends`, the profile value, and profile-declared workspace roots
  travel together. The next PR,
  [#22611](https://github.com/openai/codex/pull/22611), builds on this by
  changing the app-server turn API to select permission profiles by id
  plus runtime workspace roots.
  
  ## Stack Context
  
  - #22610, now merged: adds profile-declared `workspace_roots`, runtime
  workspace roots, and `:workspace_roots` materialization.
  - This PR: replaces the parallel active-profile/profile-value fields
  with `PermissionProfileState`.
  - #22611: switches app-server turn updates toward profile ids plus
  runtime workspace roots.
  - #22612: updates TUI/exec summaries to show the effective workspace
  roots.
  
  Keeping this separate from #22611 is deliberate: reviewers can validate
  the internal state invariant before reviewing the app-server protocol
  migration.
  
  ## What Changed
  
  - Added `ResolvedPermissionProfile::{Legacy, BuiltIn, Named}` and
  `PermissionProfileState`.
  - Typed built-in profile ids with `BuiltInPermissionProfileId`.
  - Moved selected profile identity and profile-declared workspace roots
  into the resolved state.
  - Replaced `Permissions` parallel profile fields with one
  `permission_profile_state`.
  - Removed `set_constrained_permission_profile_with_active_profile()`
  from session sync paths.
  - Kept trusted session replay/`SessionConfigured` compatibility through
  explicit session snapshot helpers.
  - Updated session configuration, MCP initialization, app-server, exec,
  TUI, and guardian call sites to consume `&PermissionProfile` directly.
  
  ## Review Guide
  
  Start with `codex-rs/core/src/config/resolved_permission_profile.rs`; it
  is the new invariant boundary. Then review
  `codex-rs/core/src/config/mod.rs` to see how config loading records
  active profile identity and profile workspace roots. The remaining
  call-site changes are mostly mechanical fallout from
  `Permissions::permission_profile()` returning `&PermissionProfile`
  instead of `&Constrained<PermissionProfile>`.
  
  ## Verification
  
  The existing config/session coverage now constructs and asserts through
  `PermissionProfileState`. The workspace-root config test also asserts
  that profile-declared roots are preserved in the resolved state, which
  is the behavior #22611 relies on when runtime roots become mutable
  through the app-server API.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22683).
  * #22612
  * #22611
  * __->__ #22683

  Michael Bolin · 2026-05-14 18:47:44 -07:00
  3c6d727810
• permissions: support workspace roots in profiles (#22610)

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

  Michael Bolin · 2026-05-14 18:25:23 -07:00
  c25d905f61
• permissions: canonicalize workspace_roots and danger-full-access names (#22624)

  ## Why
  
  This is a small precursor to the larger permissions-migration work. Both
  the comparison stack in
  [#22401](https://github.com/openai/codex/pull/22401) /
  [#22402](https://github.com/openai/codex/pull/22402) and the alternate
  stack in [#22610](https://github.com/openai/codex/pull/22610) /
  [#22611](https://github.com/openai/codex/pull/22611) /
  [#22612](https://github.com/openai/codex/pull/22612) are easier to
  review if the terminology is already settled underneath them.
  
  Because `:project_roots` and `:danger-no-sandbox` have not shipped as
  stable user-facing surface area, carrying them forward as aliases would
  just add more migration logic to the later stacks. This PR removes that
  ambiguity now so the follow-on work can rely on one spelling for each
  built-in concept.
  
  ## What Changed
  
  - renamed the config-facing special filesystem key from `:project_roots`
  to `:workspace_roots`
  - dropped unpublished `:project_roots` parsing support in
  `core/src/config/permissions.rs`, so new config only recognizes
  `:workspace_roots`
  - renamed the built-in full-access permission profile id from
  `:danger-no-sandbox` to `:danger-full-access`
  - dropped unpublished `:danger-no-sandbox` support entirely, including
  the old active-profile canonicalization path, and added explicit
  rejection coverage for the legacy id
  - introduced shared built-in permission-profile id constants in
  `codex-rs/protocol/src/models.rs`
  - updated `core`, `app-server`, and `tui` call sites that special-case
  built-in profiles to use the shared constants and canonical ids
  - updated tests and the Linux sandbox README to use `:workspace_roots` /
  `:danger-full-access`
  
  ## Verification
  
  I focused verification on the three places this rename can regress:
  config parsing, active-profile identity surfaced back out of `core`, and
  user/server call sites that special-case built-in profiles.
  
  Targeted checks:
  
  -
  `config::tests::default_permissions_can_select_builtin_profile_without_permissions_table`
  -
  `config::tests::default_permissions_read_only_applies_additional_writable_roots_as_modifications`
  -
  `config::tests::default_permissions_can_select_builtin_full_access_profile`
  - `config::tests::legacy_danger_no_sandbox_is_rejected`
  - `workspace_root` filtered `codex-core` tests
  -
  `request_processors::thread_processor::thread_processor_tests::thread_processor_behavior_tests::requested_permissions_trust_project_uses_permission_profile_intent`
  -
  `suite::v2::turn_start::turn_start_rejects_invalid_permission_selection_before_starting_turn`
  - `status::tests::status_snapshot_shows_auto_review_permissions`
  -
  `status::tests::status_permissions_full_disk_managed_with_network_is_danger_full_access`
  -
  `app_server_session::tests::embedded_turn_permissions_use_active_profile_selection`

  Michael Bolin · 2026-05-14 08:45:54 -07:00
  01d93fd9fc