6202 Commits

• Restore Windows coverage for code-mode image generation exposure (#25960)

  ## Summary
  
  Restore Windows coverage for standalone image generation in code mode.
  
  The previous test executed a V8-backed code-mode cell on Windows CI,
  where that runtime path is intentionally excluded because it is
  unreliable. The test was then ignored entirely on Windows, removing
  useful coverage.
  
  This splits the test into two checks:
  
  - All platforms verify that `image_gen__imagegen` is exposed to the
  model when image generation is configured for code mode only.
  - Non-Windows platforms continue to execute the full V8-backed flow and
  verify that the nested image-generation call succeeds.
  
  ## Verification
  
  - `just fmt`
  - `git diff --check`
  - `just test -p codex-app-server standalone_image_generation`
  
  Result: 3 tests passed, plus the required bench smoke check.

  Won Park · 2026-06-03 14:02:55 -07:00
  0eb7e6d79b
• Fix forked thread name inheritance (#26075)

  Fixes #25950.
  
  ## Why
  Forking a renamed thread could fall back to the source thread's
  first-prompt title because the fork path did not preserve the source's
  explicit name. That meant fork-of-renamed-fork flows could show stale
  sidebar labels even though the user had renamed the parent.
  
  ## What changed
  `thread/fork` now reads the source thread's distinct `name`, normalizes
  it, persists it onto materialized forks, and applies it to the returned
  API thread. Because the source `name` already excludes first-prompt
  pseudo-titles, forks inherit only an explicit user rename instead of
  stale generated metadata.

  Eric Traut · 2026-06-03 12:56:54 -07:00
  d8121f93c8
• [profile-switcher][rust] -- [1/2] Add app-server account session protocol (#25469)

  ## Summary
  
  Adds the app-server v2 `accountSession/*` protocol used by the Desktop
  profile switcher and the backend account metadata client needed to
  populate workspace choices.
  
  This is the protocol layer only. The app-server lifecycle and
  consolidated saved-session storage are split into a follow-up PR.
  
  ## Rust Stack
  
  1. This PR
  2. [openai/codex#25383](https://github.com/openai/codex/pull/25383) adds
  app-server session lifecycle behavior and consolidated saved-session
  storage.
  
  ## Validation
  
  - Generated app-server schema fixtures are included from the existing
  generation flow in the lifecycle PR where the routes are registered.
  - Did not run tests per requested scope.

  dhruvgupta-oai · 2026-06-04 01:25:11 +05:30
  a2ebe07b39
• Expose local image paths to models (#25944)

  ## Why
  
  Local image attachments include image bytes, but the adjacent
  model-visible label omits the source path. Exposing the path lets
  model-selected workflows refer back to the intended local image
  explicitly.
  
  ## What changed
  
  - Include an escaped `path` attribute in model-visible local image
  opening tags.
  - Reuse the path-aware marker generator in rollout coverage.
  - Update protocol, replay, and rollout coverage for the new request
  shape.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-protocol`
  - `just test -p codex-core skips_local_image_label_text`
  - `just test -p codex-core
  copy_paste_local_image_persists_rollout_request_shape`
  - `git diff --check`

  Won Park · 2026-06-03 19:49:58 +00:00
  57ab4c89e0
• Preserve remote plugin default prompts (#25887)

  ## Summary
  
  - Read `default_prompts` from remote plugin release metadata.
  - Prefer the plural prompt list over legacy `default_prompt`.
  - Fall back to `default_prompt` as a single-item list for backward
  compatibility.
  
  ## Testing
  
  - `just test -p codex-core-plugins`
  - `just test -p codex-app-server`

  Eric Ning · 2026-06-03 12:39:13 -07:00
  aeac226d16
• core: stop threading SandboxPolicy through exec (#25700)

  ## Why
  
  #25450 attempts a broad `SandboxPolicy` removal across several unrelated
  surfaces, which makes it hard to review and still leaves new helper code
  moving legacy policies around. This PR is a narrower alternative:
  migrate only the exec-side Windows sandbox plumbing so the review can
  focus on one production path and one compatibility boundary.
  
  The goal is to stop threading `SandboxPolicy` through exec code without
  expanding the migration into app-server, protocol, telemetry, config, or
  session behavior.
  
  ## What changed
  
  - Removed `ExecRequest::compatibility_sandbox_policy()`.
  - Changed the Windows restricted-token and elevated filesystem override
  helpers to accept `PermissionProfile` plus the split filesystem/network
  policies instead of a `SandboxPolicy`.
  - Kept the remaining legacy projection local to the writable-root
  comparison that still needs to compare split policy behavior against the
  legacy Windows backend model.
  - Rejected restricted split filesystem policies that still grant
  full-disk writes before using the Windows restricted-token backend,
  preserving the previous clear-failure behavior for profiles that project
  to `ExternalSandbox`.
  - Updated the Windows sandbox override tests to exercise the new call
  shape and cover the full-write split-profile regression.
  
  ## Verification
  
  - `just test -p codex-core windows_restricted_token`
  - `just test -p codex-core windows_elevated`

  Michael Bolin · 2026-06-03 10:41:41 -07:00
  52b359b249
• Fix multiline paste in /goal edit (#26047)

  Fixes #26025.
  
  ## Why
  `/goal edit` opens `CustomPromptView`, which did not use the paste-burst
  handling that protects the main composer when terminals deliver paste as
  rapid key events. On Windows terminals, the first pasted newline could
  be treated as Enter-to-submit, truncating the goal edit and leaving the
  rest of the paste behind.
  
  ## What
  This reuses `PasteBurst` in `CustomPromptView` as a lightweight
  Enter-suppression detector for paste-like key streams. Characters still
  insert directly, explicit paste still goes through the view paste path,
  and ordinary text entry still submits on Enter.

  Eric Traut · 2026-06-03 09:36:50 -07:00
  a2a9e767f7
• feat: guard git enrichment (#26175)

  Skip turn git metadata enrichment when a turn has remote or multiple
  executors, so we do not report the orchestrator checkout as executor
  workspace metadata.
  
  Test: `just test -p codex-core` (blocked by existing
  `Session::conversation_id` compile error in `close_agent.rs`).

  jif · 2026-06-03 18:36:10 +02:00
  8030c36970
• nit: small prompt update for MAv2 (#26179)

  Simple prompt change for MAv2 because of OOD compared to CBv9

  jif · 2026-06-03 18:34:32 +02:00
  99c9be1d30
• [codex] Restore setup helper UAC manifest (#25949)

  ## Why
  
  #23764 removed Windows resource stamping from `codex-windows-sandbox`,
  but it also removed the setup helper's UAC manifest. That manifest was
  doing more than cosmetic version metadata: Microsoft documents
  `requestedExecutionLevel level="asInvoker"` as the setting that makes an
  executable run at the same permission level as the process that started
  it:
  https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#trustinfo
  
  In the reported session, `codex-windows-sandbox-setup.exe` was launched
  for a non-elevated setup refresh and `CreateProcess` failed with `os
  error 740` (`The requested operation requires elevation`). Restoring an
  explicit `asInvoker` manifest records the helper's intended default
  launch contract: normal launches inherit the caller's token, and
  elevation only happens through the code paths that request it
  explicitly.
  
  The setup helper has two launch modes:
  
  - setup refresh uses a normal `Command::new(...)` spawn and should never
  trigger UAC
  - full setup explicitly uses `ShellExecuteExW` with the `runas` verb
  when elevation is required
  
  Restoring `asInvoker` keeps refresh non-elevated by default while
  preserving the explicit elevated path for full setup.
  
  ## What changed
  
  - Restored a minimal `codex-windows-sandbox-setup.manifest` containing
  only `requestedExecutionLevel level="asInvoker"`.
  - Added a small build script that passes setup-helper-scoped manifest
  linker args for MSVC and the Windows GNU/LLVM target used by Bazel.
  - Wired the manifest into Bazel build-script data.
  
  This does not restore `winres`, `FileDescription`, `ProductName`, or
  package-wide resource stamping, so other Codex binaries that link
  `codex-windows-sandbox` do not inherit metadata from this package.
  
  ## Verification
  
  - `cargo fmt -p codex-windows-sandbox`
  - `cargo build -p codex-windows-sandbox --bin
  codex-windows-sandbox-setup`
  - `cargo build -p codex-windows-sandbox --bin codex-command-runner`
  - `cargo build -p codex-windows-sandbox --lib`
  - Build-script output simulation for `CARGO_CFG_TARGET_ENV=msvc` emits
  `/MANIFEST:EMBED` and `/MANIFESTINPUT:<manifest>`.
  - Build-script output simulation for `CARGO_CFG_TARGET_ENV=gnu` +
  `CARGO_CFG_TARGET_ABI=llvm` emits `-Wl,-Xlink=/manifest:embed` and
  `-Wl,-Xlink=/manifestinput:<manifest>`.
  - Inspected the built binaries and confirmed:
  - `codex-windows-sandbox-setup.exe` contains `requestedExecutionLevel` /
  `asInvoker`
    - `codex-command-runner.exe` does not contain those manifest strings
  - Windows `VersionInfo` remains blank for `FileDescription` /
  `ProductName`
  - `just test -p codex-windows-sandbox` ran through Nextest, with 114
  passing, 2 skipped, and 1 existing Windows sandbox failure:
  `unified_exec::tests::legacy_non_tty_cmd_emits_output` fails with
  `CreateRestrictedToken failed: 87`.

  iceweasel-oai · 2026-06-03 09:21:24 -07:00
  b2344d8fbc
• fix: main (#26176)
  jif · 2026-06-03 16:47:34 +02:00
  4417e4c193
• Implement v1 skills extension prompt injection (#26167)

  ## Why
  
  The skills extension needs a real turn-time path before host, executor,
  or remote skills can be routed through it. The previous code was mostly
  a placeholder catalog/provider sketch, so there was no bounded
  available-skills fragment, no source-owned `SKILL.md` read, and no place
  for warnings or per-turn selection state to live.
  
  This PR makes `ext/skills` the authority-preserving flow for listing
  candidate skills and injecting only explicitly selected main prompts,
  without adding more of that logic to `codex-core`.
  
  ## What changed
  
  - Expands catalog entries with `main_prompt`, display path, short
  description, dependency metadata, enabled/prompt visibility flags, and
  authority/package-aware read requests.
  - Replaces the placeholder `providers/*` modules with
  `SkillProviderSource` and `SkillProviders`, routing list/read/search
  calls by source kind and surfacing provider failures as warnings.
  - Adds bounded available-skills rendering and `SKILL.md` main-prompt
  truncation before the fragments enter model context.
  - Resolves explicit skill selections from structured `UserInput::Skill`,
  skill-file mentions, `skill://...` paths, and plain `$skill` text
  mentions, then reads selected prompts through their owning provider.
  - Stores mutable per-thread skills config and per-turn
  catalog/selection/warning state.
  - Adds `install_with_providers` so tests and future host wiring can
  supply concrete providers.
  
  ## Testing
  
  - Not run locally.
  - Added `codex-rs/ext/skills/tests/skills_extension.rs` coverage for
  available-catalog injection, selected prompt injection through the
  owning provider, and prompt-hidden skills that remain invokable.

  jif · 2026-06-03 16:24:16 +02:00
  96d2d2f68c
• chore: mechanical rename (#26156)

  Rename `Session::conversation_id` to `Session::thread_id` with an auto
  refactor in RustRover

  jif · 2026-06-03 15:38:30 +02:00
  c9ae0f48a1
• fix: serialize goal progress accounting (#26155)

  ## Why
  
  Goal progress accounting can be reached from multiple completion paths
  for the same thread. Each path takes a progress snapshot, writes the
  usage delta, and then marks that snapshot as accounted. When two
  tool-completion hooks run at the same time, they can both observe the
  same unaccounted delta and charge it twice.
  
  ## What changed
  
  - Added a per-thread progress-accounting permit to
  `GoalAccountingState`.
  - Held that permit across the snapshot/write/mark-accounted critical
  section for active-turn, idle, and tool-finish accounting.
  - Added regression coverage for parallel tool-finish hooks so a shared
  token delta is charged once and only one progress event is emitted.
  
  ## Testing
  
  - Not run locally.
  - Added `parallel_tool_finish_accounts_active_goal_progress_once`.

  jif · 2026-06-03 15:10:16 +02:00
  7db18c8241
• skills: resolve per-turn catalogs from turn input context (#26106)

  ## Why
  
  The skills extension needs the resolved turn environments to build a
  real per-turn `SkillListQuery`. The previous `TurnLifecycleContributor`
  hook only had a turn id, so it could only seed a placeholder query and
  never carry the executor authorities that executor-scoped skill routing
  will need.
  
  Moving catalog resolution onto `TurnInputContributor` puts the skills
  extension on the same turn-preparation path that already has the
  environment ids and working directories for the submitted turn, while
  keeping the actual prompt injection work for follow-up changes.
  
  ## What changed
  
  - switch `ext/skills` from `TurnLifecycleContributor` to
  `TurnInputContributor`
  - build `executor_authorities` from `TurnInputContext.environments` and
  pass them through `SkillListQuery`
  - keep storing the resolved catalog in `SkillsTurnState`, but drop the
  placeholder query helper that no longer matches the real data flow
  - update the extension TODOs to reflect that per-turn catalog resolution
  now happens in the turn-input contributor, and that prompt/context
  injection still needs to move later
  
  ## Testing
  
  - Not run locally.

  jif · 2026-06-03 13:32:55 +02:00
  3389fa554e
• Reject MAv2 close_agent self-targets (#26144)

  ## Why
  
  `close_agent` is a parent-owned coordination tool: a worker should
  return its result, then let its parent decide when to close it. Before
  this change, if an MAv2 worker targeted itself, the resolved target
  could flow through the normal close path and ask the agent control layer
  to close the current conversation.
  
  ## What changed
  
  - Reject `close_agent` when the resolved target is the current session's
  `conversation_id`, returning a model-visible error that tells the worker
  to return its result instead.
  - Keep the guard after target resolution so it covers both thread-id
  targets and task-path targets.
  - Add coverage for self-targeting by thread id and by task name in
  `multi_agents_tests.rs`.
  
  Relevant code:
  
  -
  [`handle_close_agent`](https://github.com/openai/codex/blob/7c24e6641b693a3eed933dd376ce8f424ab6ea5f/codex-rs/core/src/tools/handlers/multi_agents_v2/close_agent.rs#L39-L57)
  - [`multi_agent_v2_close_agent_rejects_self_target_by_id` /
  `multi_agent_v2_close_agent_rejects_self_target_by_task_name`](https://github.com/openai/codex/blob/7c24e6641b693a3eed933dd376ce8f424ab6ea5f/codex-rs/core/src/tools/handlers/multi_agents_tests.rs#L3936-L4070)
  
  ## Testing
  
  Not run locally.

  jif · 2026-06-03 13:30:04 +02:00
  51493157cd
• chore: extract context fragments into dedicated crate (#26122)

  ## Why
  
  `codex-core` currently owns the generic contextual-fragment trait and
  several reusable fragment implementations. That makes it harder for
  other crates to share the same host-owned model-input abstraction
  without depending on all of `codex-core`.
  
  This change extracts the reusable fragment machinery into a small
  `codex-context-fragments` crate so future extension and skills work can
  depend on the fragment abstraction directly.
  
  ## What Changed
  
  - Added the `codex-context-fragments` crate with:
    - `ContextualUserFragment`
    - `FragmentRegistration` / `FragmentRegistrationProxy`
    - additional-context fragment types
  - Moved `SkillInstructions` into `codex-core-skills`, since
  skill-specific rendering belongs with skills rather than generic core
  context machinery.
  - Kept `codex-core` re-exporting the fragment types it still uses
  internally, so existing call sites keep the same shape.
  - Updated Cargo and Bazel workspace metadata for the new crate.
  
  ## Verification
  
  - `cargo metadata --locked --format-version 1 --no-deps`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  jif · 2026-06-03 12:25:21 +02:00
  ac67905fc4
• feat: default hide_spawn_agent_metadata to true (#26114)

  For MAv2 CBv9

  jif · 2026-06-03 12:22:23 +02:00
  668703c23f
• feat(app-server): add remote control client management RPCs (#25785)

  ## Why
  
  Remote-control clients need to list and revoke controller-device grants
  without enabling or enrolling the local relay. These are signed-in
  account-management operations, so coupling them to websocket, pairing,
  enrollment, or persisted relay state would prevent clients from managing
  stale grants from the picker.
  
  Related enhancement request: N/A. This adds the Codex app-server surface
  for the planned upstream environment-scoped revoke endpoint.
  
  ## What Changed
  
  - Added experimental app-server v2 RPCs:
    - `remoteControl/client/list`
    - `remoteControl/client/revoke`
  - Added picker-oriented protocol types and standard generated schema
  fixtures. The list response intentionally omits backend account id,
  enrollment status, and location fields.
  - Added `app-server-transport/src/transport/remote_control/clients.rs`
  for environment-scoped GET and DELETE requests. It builds escaped URL
  path segments, forwards optional pagination query fields, sends ChatGPT
  auth plus `chatgpt-account-id`, converts RFC3339 `last_seen_at` values
  to Unix seconds, accepts `204 No Content` revoke responses, and retries
  once after a `401`.
  - Extracted shared ChatGPT auth loading and recovery into
  `app-server-transport/src/transport/remote_control/auth.rs` so
  websocket, pairing, and client management use the same account-auth
  boundary.
  - Retained the configured remote-control base URL on
  `RemoteControlHandle` and resolve management URLs lazily, preserving
  deferred validation while relay startup is disabled.
  - Registered list as `global_shared_read("remote-control-clients")` and
  revoke as `global("remote-control-clients")`.
  
  ## Verification
  
  - Added transport coverage proving list and revoke work while relay
  state is disabled, IDs are escaped, picker-only fields are returned,
  timestamps are converted, revoke accepts `204`, auth headers are
  forwarded, `401` retries exactly once, `403` is not retried, and
  malformed list payloads retain decode context.
  - Added an app-server integration test proving both JSON-RPC methods
  work before relay enablement and successful revoke returns `{}`.
  - Regenerated and validated experimental and standard app-server schema
  fixtures.

  Anton Panasenko · 2026-06-02 17:01:02 -07:00
  98a62a62ce
• Allow EDU accounts to fetch cloud config bundles (#25963)

  ## Summary
  
  Allow EDU ChatGPT workspaces to fetch cloud config bundles. The existing
  cloud config eligibility gate only allowed business-like and enterprise
  plans, which meant EDU admins could configure managed policies in the UI
  but the Codex client would skip fetching them.
  
  This keeps individual/pro and team-like usage-based plans excluded, and
  adds service-level coverage for both `edu` and `education` plan aliases.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-cloud-config`
  - Built the Codex app locally, created a new EDU ChatGPT workspace, and
  verified config bundles can be fetched and are properly applied.

  joeflorencio-openai · 2026-06-02 16:41:48 -07:00
  1fd2a6d328
• feat: add extension turn-input contributors (#25959)

  ## Disclaimer
  Do not use for now
  
  ## Why
  
  Extensions can already contribute prompt fragments and request same-turn
  item injection, but there was no host-owned hook for contributing
  structured `ResponseItem`s while Codex is assembling a new turn's
  initial model input. This change adds that seam so extensions can attach
  turn-local input that depends on the submitted user input and resolved
  turn environments without routing through prompt text or late injection.
  
  ## What changed
  
  - add `TurnInputContributor` to `codex_extension_api` and export the new
  `TurnInputContext` / `TurnInputEnvironment` types it receives
  - teach `ExtensionRegistry` to register and expose turn-input
  contributors alongside the existing extension hooks
  - call registered turn-input contributors from
  `core/src/session/turn.rs` while building the initial injected input for
  a turn, then append their returned `ResponseItem`s after the skill and
  plugin injections

  jif · 2026-06-03 01:33:31 +02:00
  271d5cecf2
• config: express implicit sandbox defaults as permission profiles (#25926)

  ## Why
  
  `PermissionProfile` is becoming the default way to represent Codex
  permissions, but the implicit default behavior should stay the same for
  now:
  
  - trusted projects use `:workspace`
  - untrusted projects also use `:workspace`
  - roots without a trust decision use `:read-only`
  - unsandboxed Windows falls back to `:read-only`
  
  This keeps the existing sandbox semantics while making silent config
  defaults observable as built-in permission profiles instead of treating
  the legacy `SandboxPolicy` projection as the primary shape.
  
  ## What Changed
  
  - Refactored legacy sandbox derivation to resolve the configured sandbox
  mode once, then apply the implicit project fallback only when no sandbox
  mode was configured.
  - Preserved the existing trust-decision fallback: trusted and untrusted
  projects default to workspace-write where supported.
  - Added empty-config coverage asserting that an untrusted project
  resolves to the built-in active permission profile (`:workspace` outside
  unsandboxed Windows).
  
  ## Verification
  
  - `just fmt`
  - `just test -p codex-core 'config::'`
  - `just test -p codex-config`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25926).
  * __->__ #25926

  Michael Bolin · 2026-06-02 16:26:36 -07:00
  a28b32a835
• [codex] Fix Windows BuildBuddy Bazel wrapper execution (#25915)

  ## Why
  
  #25156 moved Bazel CI launches into a shared Python wrapper. On Windows,
  launching Bazel with `os.execvp` can split the spaced
  `--test_env=PATH=...` argument and fail to propagate the eventual Bazel
  exit status, allowing jobs to pass without running tests. This reapplies
  the wrapper after #25909 with a Windows-safe launch path.
  
  ## What changed
  
  Use a waited `subprocess.run` launch on Windows while preserving
  `os.execvp` on Unix. Add a process-level regression test for spaced
  arguments and child exit status, and run it on Windows Bazel shard 1.
  
  ## Experiment
  
  To confirm Bazel was actually invoking tests, patch `87b61d0be6`
  temporarily added an intentionally failing `codex-core` unit test. Bazel
  failed on that sentinel on all three major platforms:
  
  - [Linux Bazel
  test](https://github.com/openai/codex/actions/runs/26841132773/job/79151062486)
  - [macOS Bazel
  test](https://github.com/openai/codex/actions/runs/26841132773/job/79151062362)
  - [Windows Bazel test shard
  1/4](https://github.com/openai/codex/actions/runs/26841132773/job/79151062155)
  
  The sentinel was removed after collecting this evidence. Windows Bazel
  [clippy](https://github.com/openai/codex/actions/runs/26841132773/job/79151062914)
  and [release
  verification](https://github.com/openai/codex/actions/runs/26841132773/job/79151062739)
  also passed.
  
  ## Validation
  
  After removing the sentinel, `just test -p codex-core` no longer
  reported it. The local run retained two unrelated environment-specific
  failures.

  Adam Perry @ OpenAI · 2026-06-02 16:22:32 -07:00
  6471f8b31a
• feat: add skills extension scaffold (#25953)

  ## Disclaimer
  This is only here for iteration purpose! Do not make any code rely on
  this
  
  ## Why
  
  Skills still live behind `codex-core` discovery and injection paths, but
  the extension system needs an authority-aware home before that logic can
  move. This adds that boundary without changing current skills behavior,
  and keeps host, executor, and remote skills distinct so future
  list/read/search flows do not collapse back to ambient local paths.
  
  ## What changed
  
  - Add the `codex-skills-extension` workspace/Bazel crate under
  `ext/skills`.
  - Define the initial catalog, authority, provider, and turn-state types
  for authority-bound skill packages and resources.
  - Register placeholder thread/config/prompt/turn lifecycle contributors
  plus host, executor, and remote provider aggregation points.
  - Capture the remaining extraction work as TODOs, including the missing
  extension API hooks needed for per-turn catalog construction and typed
  skill injection.
  - Keep plugins outside the runtime skills model: plugin-installed skills
  are treated as materialized host-owned skill sources once available.
  
  ## Verification
  
  - Not run locally.

  jif · 2026-06-03 01:10:26 +02:00
  2d385e166c
• Expose standalone image generation in code mode (#25923)

  ## Why
  
  Standalone image generation remained top-level-only in code-mode
  sessions.
  
  ## What changed
  
  - Change imagegen exposure from `DirectModelOnly` to `Direct`.
  - Keep direct-mode access while enabling nested code-mode access.
  - Add a focused regression test for the exposure contract.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`

  Won Park · 2026-06-02 22:27:52 +00:00
  bec21c7114
• config: remove dead profile sandbox fallback (#25943)

  ## Why
  
  `profile_sandbox_mode` was left over from the old selected legacy
  profile path. Production now always derives permissions without that
  value, and legacy profile contents are ignored, so keeping a parameter
  that is always `None` makes `derive_permission_profile` look like it
  still supports a fallback that no longer exists.
  
  ## What Changed
  
  - Removed the `profile_sandbox_mode` argument from
  `ConfigToml::derive_permission_profile`.
  - Updated the production caller and legacy sandbox-policy test helper to
  match.
  - Dropped the stale unselected legacy-profile sandbox test that only
  protected the removed fallback shape.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-core 'config::'`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25943).
  * #25926
  * __->__ #25943

  Michael Bolin · 2026-06-02 22:05:04 +00:00
  c6d76750e8
• Add remote request permissions integration coverage (#25867)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. #25862 - Propagate permission approval environment id: carries the
  selected environment id through approval events, app-server requests,
  TUI prompts, and delegate forwarding.
  4. This PR (#25867) - Add remote request permissions integration
  coverage: verifies the selected remote environment across request,
  approval, grant reuse, and exec.
  
  This PR is stacked on #25862 and should be reviewed after #25850,
  #25858, and #25862.
  
  ## Why
  
  The environment-scoped permission stack needs one end-to-end check that
  exercises the CCA-shaped path, not only unit-level parsing. This
  verifies that a model-sent `environmentId` on `request_permissions`
  reaches the approval event, stores the grant under the selected
  environment, and is reused by a later tool call in that same
  environment.
  
  ## What Changed
  
  - Adds a remote executor integration test for `request_permissions` with
  `environmentId: remote` and a relative write root.
  - Asserts the permission event reports the remote environment and cwd,
  and that the normalized grant resolves under the remote cwd.
  - Approves the grant, then runs a remote `exec_command` without explicit
  per-call permissions and verifies it completes without another exec
  approval and writes only in the remote filesystem.
  
  ## Verification
  
  - Not run locally per instruction.
  - `git diff --check`

  jif · 2026-06-02 23:55:08 +02:00
  d55e5a9bde
• [codex] Keep hosted tools visible in code-only mode (#25890)

  ## Why
  
  `code_mode_only` moved ordinary runtime tools behind `exec`, but it also
  hid hosted Responses tools. Hosted `web_search` and `image_generation`
  do not have a nested `exec` runtime path, so code-only sessions lost
  those capabilities entirely even when their existing provider, auth,
  model, and configuration gates passed.
  
  ## What changed
  
  - Keep hosted Responses tools top-level in `code_mode_only` sessions
  after their existing gates pass.
  - Preserve the existing nested-tool behavior for ordinary runtimes and
  the direct-only behavior for multi-agent v2 tools.
  - Add planner coverage for `code_mode_only` with default multi-agent v2
  settings, hosted live web search, and hosted image generation.
  
  ## Verification
  
  - Added focused regression coverage in
  `codex-rs/core/src/tools/spec_plan_tests.rs`.
  - Left execution to CI per repository workflow.

  Ahmed Ibrahim · 2026-06-02 14:50:16 -07:00
  68e2c8ed69
• Split cloud config bundle service modules (#25668)

  ## Summary
  
  - Splits the monolithic `codex-cloud-config` implementation into focused
  modules.
  - Keeps behavior unchanged from the preceding config bundle runtime
  switch.
  
  ## Details
  
  This is the reviewability follow-up after the lineage-preserving
  migration PRs. The split separates backend transport, loader
  construction, cache handling, metrics, validation, service
  orchestration, and focused tests into named files.
  
  Verification: `just fmt`; `just test -p codex-cloud-config`.

  joeflorencio-openai · 2026-06-02 14:30:12 -07:00
  e7039f9844
• core: stop passing legacy SandboxPolicy to guardian reviews (#25911)

  ## Why
  
  Guardian review turns already submit a read-only `PermissionProfile`,
  which is the permissions model the runtime should honor. Passing the
  equivalent legacy `SandboxPolicy` through `ThreadSettingsOverrides`
  keeps two representations of the same read-only constraint alive on this
  path and makes the guardian flow depend on compatibility plumbing that
  is being phased out.
  
  ## What Changed
  
  - Set `sandbox_policy` to `None` when the guardian review session
  submits its child `Op::UserInput`.
  - Keep `permission_profile: Some(PermissionProfile::read_only())` and
  `approval_policy: Some(AskForApproval::Never)`, so the guardian review
  remains read-only and cannot request approvals.
  - Remove the now-unused `SandboxPolicy` import and redundant comment
  from `codex-rs/core/src/guardian/review_session.rs`.
  
  ## Verification
  
  Not run locally; this is a narrow cleanup of redundant thread-settings
  override state.

  Michael Bolin · 2026-06-02 14:16:12 -07:00
  f6d64bd6ab
• fix: update image generation test helper rename (#25938)

  ## Summary
  - update the app-server image generation integration test to use
  `TestAppServer`
  - completes the test helper rename from #25701 for this newer test file
  
  ## Validation
  - `cargo fmt -- --config imports_granularity=Item`
  - `cargo check -p codex-app-server --test all`
  
  Note: `just fmt` ran Rust formatting but failed on Python/SDK formatting
  because the sandbox could not access the local `uv` cache.

  joeflorencio-openai · 2026-06-02 14:11:20 -07:00
  c74be11672
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• Populate workspace kind on Codex turn events (#25135)

  ## Summary
  - carry `workspace_kind` from Responses API client metadata into the
  turn resolved analytics fact
  - serialize the optional value on `codex_turn_event`
  - cover both the turn metadata source and turn event serialization
  
  The `workspace_kind` tells us whether a thread had a project attached vs
  projectless. this is an indicator for who is adopting Codex for
  knowledge work outside of coding
  
  ## Testing
  - `env UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just fmt`
  - `env PATH=/private/tmp/cargo-tools/bin:$PATH
  CARGO_HOME=/private/tmp/cargo-home UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just test -p codex-analytics`
  - `env PATH=/private/tmp/cargo-tools/bin:$PATH
  CARGO_HOME=/private/tmp/cargo-home UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just test -p codex-core turn_metadata`
  
  Paired with openai/openai#970661, which keeps forwarding the same
  metadata key through Responses API headers.

  knittel-openai · 2026-06-02 12:46:14 -07:00
  b794182ea7
• Fix Windows running thread resume path normalization (#25509)

  ## Why
  
  Fixes #24944.
  
  On Windows, app-server resume could reject an active running thread when
  the requested session path used normal `C:\...` form and the
  already-running path used verbatim `\\?\C:\...` form. The paths point at
  the same JSONL file, but the resume stale-path guard compared raw
  `PathBuf`s, so desktop resume and heartbeat flows could fail with a
  mismatched-path error.
  
  ## What Changed
  
  - Compare requested and active rollout paths with
  `path_utils::paths_match_after_normalization`.
  - Extend the existing running-thread mismatched-path test with a
  Windows-only same-file resume case before the stale-path rejection.
  
  ## Verification
  
  - `just test -p codex-app-server
  thread_resume_rejects_mismatched_path_for_running_thread_id`

  Eric Traut · 2026-06-02 12:42:42 -07:00
  ad355d4c96
• Propagate permission approval environment id (#25862)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. This PR (#25862) - Propagate permission approval environment id:
  carries the selected environment id through approval events, app-server
  requests, TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  This PR is stacked on #25858, and #25867 is stacked on this PR.
  
  ## Why
  
  PR2 lets the model bind a `request_permissions` call to a selected
  environment, but the approval event and client-facing request still
  needed to carry that binding. For CCA, the user-facing prompt and
  delegated approval path should know which environment the grant applies
  to instead of relying on cwd alone.
  
  ## What Changed
  
  - Added optional `environmentId` to `RequestPermissionsEvent`.
  - Emit the selected environment id from core permission approval events.
  - Preserve the environment id through delegate forwarding, including
  cwd-based delegated requests.
  - Added `environmentId` to app-server permission approval params,
  generated schema/TypeScript artifacts, and README examples.
  - Preserve and display the environment id in TUI permission approval
  prompts.
  - Updated focused core, app-server protocol, and TUI conversion
  coverage.
  
  ## Testing
  
  Not run locally per instruction. Performed read-only `git diff --check`.

  jif · 2026-06-02 21:09:34 +02:00
  9de568372d
• Route standalone image generation through host finalization md (#25176)

  ## Why
  
  Standalone image-generation extensions emitted turn items through the
  low-level event path, bypassing host-owned finalization such as image
  persistence and contributor processing. At the same time, the
  generated-image save-path hint must remain visible to the model through
  the extension tool's `FunctionCallOutput`, rather than the legacy
  built-in developer-message path.
  
  ## What changed
  
  - Extended `ExtensionTurnItem` to support image-generation items while
  keeping the extension-facing emitter API limited to `emit_started` and
  `emit_completed`.
  - Routed extension completion through core `finalize_turn_item`, so
  standalone image-generation items receive host-owned processing and
  persisted `saved_path` values before publication.
  - Kept legacy built-in image generation on its existing
  developer-message hint path, while standalone image generation returns
  its deterministic saved-path hint in `FunctionCallOutput`.
  - Shared the image artifact path and output-hint formatting used by core
  and the image-generation extension.
  - Passed thread identity through extension tool calls so standalone
  image generation can construct the same intended artifact path as core.
  - Added an app-server integration test covering real standalone image
  generation, saved artifact publication, model-visible output hint
  wiring, and absence of the legacy developer-message hint.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-web-search-extension`
  - `just test -p codex-goal-extension`
  - `just test -p codex-memories-extension`
  - Targeted `codex-core` tests for image save history, extension
  completion finalization, and contributor execution
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`
  - `just fix -p codex-core`
  - `just fix -p codex-image-generation-extension`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  Won Park · 2026-06-02 12:00:04 -07:00
  57f337a8e9
• Add environmentId to request_permissions (#25858)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. This PR (#25858) - Add `environmentId` to `request_permissions`: lets
  the model target a selected environment and resolves relative permission
  paths against it.
  3. #25862 - Propagate permission approval environment id: carries the
  selected environment id through approval events, app-server requests,
  TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  This PR is stacked on #25850; #25862 and #25867 are stacked on this PR.
  
  ## Why
  
  PR1 made request-permission grants internally environment-keyed, but the
  model-facing `request_permissions` tool could still only target the
  primary environment. For CCA and multi-environment turns, the tool needs
  an explicit way to bind a permission request to a selected attached
  environment before resolving relative paths.
  
  ## What Changed
  
  - Added optional `environmentId` to `RequestPermissionsArgs`, with
  `environment_id` accepted as an alias.
  - Exposed `environmentId` in the `request_permissions` tool schema and
  description.
  - Resolve the selected environment before parsing filesystem permission
  paths, so relative paths bind to the selected environment cwd.
  - Route validated tool calls through
  `request_permissions_for_environment` directly instead of duplicating
  environment lookup in `Session::request_permissions`.
  - Reject unknown environment ids with a model-facing error.
  - Updated focused request-permissions and Guardian call sites for the
  new optional field.
  
  ## Testing
  
  Not run locally per instruction.

  jif · 2026-06-02 20:51:25 +02:00
  e29071e4c9
• [codex-analytics] Track CodexErr details in turn analytics (#25707)

  ## Summary
  - add analytics-only `CodexErr` telemetry to `codex_turn_event` while
  leaving existing `turn_error` unchanged
  - record terminal `CodexErr` facts from core immediately before the
  existing turn error event is sent
  - emit source-truth `codex_error_*` fields for downstream analytics,
  including the raw `CodexErr::InvalidRequest(String)` message as
  `codex_error_subreason`
  
  ## Validation
  - `just test -p codex-analytics`
  - attempted `just test -p codex-core`, but the local run timed out
  across unrelated integration suites in this environment and is not being
  used as validation

  rhan-oai · 2026-06-02 11:40:35 -07:00
  8e4b92d294
• Key request-permission grants by environment (#25850)

  ## Stack
  
  1. This PR (#25850) - Key request-permission grants by environment:
  stores and applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. #25862 - Propagate permission approval environment id: carries the
  selected environment id through approval events, app-server requests,
  TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  #25858, #25862, and #25867 are stacked on this PR and should be reviewed
  after it.
  
  ## Why
  
  Multi-environment CCA turns can attach both local and remote executors,
  but request-permission grants were still effectively cwd-only. Pending
  permission requests tracked a cwd, while stored turn/session grants had
  no environment identity, so sticky grants could be reused through the
  wrong executor context.
  
  This makes the first permission-grant step environment-aware without
  changing the external `request_permissions` payload shape: omitted
  environment targeting remains bound to the primary turn environment.
  
  ## What Changed
  
  - Store turn- and session-scoped request-permission grants by
  `environment_id`.
  - Keep the selected `TurnEnvironmentSelection` with pending
  `request_permissions` calls so approval responses normalize and record
  grants against the same environment.
  - Resolve relative `request_permissions` file paths against the primary
  turn environment cwd instead of deprecated `turn.cwd`.
  - Apply sticky grants in `shell`, `exec_command`, and `apply_patch` by
  selected environment id while still using the actual tool cwd for
  cwd-relative permission materialization.
  - Update Guardian and request-permissions coverage for the
  environment-keyed grant behavior.
  
  ## Testing
  
  Not run locally. Added or updated focused coverage for:
  
  - `request_permission_grants_are_environment_keyed`
  -
  `request_permissions_tool_resolves_relative_paths_against_primary_environment`
  - related Guardian/request-permissions sticky grant tests

  jif · 2026-06-02 20:16:57 +02:00
  503ec190a8
• [codex] Revert shared BuildBuddy Bazel wrapper (#25909)

  ## Why
  
  PR #25905 intentionally adds a failing `codex-core` unit test, but its
  [Bazel test on Windows
  check](https://github.com/openai/codex/actions/runs/26837526950/job/79135369259)
  passed. That shows the Bazel configuration introduced by #25156 is not
  behaving as expected, so revert it while the configuration can be
  investigated separately.
  
  ## What changed
  
  Revert #25156 in full, restoring the previous Bazel remote
  configuration, CI scripts, workflows, `rusty_v8` handling, and
  documentation. This removes the shared BuildBuddy wrapper and its tests.
  
  ## Validation
  
  Not run locally; this exact revert was prioritized for a fast rollback.

  Adam Perry @ OpenAI · 2026-06-02 11:06:01 -07:00
  9e3d5f29e2
• core: derive built-in permission profiles from raw policies (#25739)

  ## Why
  
  Permission profiles that extend a built-in profile should behave like
  other TOML inheritance: parent entries provide defaults, and child keys
  override matching fields before the profile is compiled.
  
  That was not true for `:workspace`. Previously, a profile with `extends
  = ":workspace"` seeded the compiled runtime
  `PermissionProfile::workspace_write()` policy and then appended child
  filesystem entries. A child override such as `":tmpdir" = "read"`
  therefore left the inherited `":tmpdir" = "write"` entry in the final
  policy. Since same-target `write` wins over `read` during runtime
  resolution, the child override was ineffective.
  
  This also needs a clear source of truth for the built-in profiles. The
  protocol-level sandbox policy constructors now define the raw built-in
  filesystem entries, and both `PermissionProfile` presets and
  config-profile inheritance derive from those same values.
  
  ## What Changed
  
  - Add a canonical `FileSystemSandboxPolicy::read_only()` constructor
  while keeping the read-only and workspace-write raw filesystem entries
  explicit and independent.
  - Derive `PermissionProfile::read_only()` from
  `FileSystemSandboxPolicy::read_only()`;
  `PermissionProfile::workspace_write()` continues to derive from
  `FileSystemSandboxPolicy::workspace_write()`.
  - Build extensible `:read-only` and `:workspace` parent profiles by
  projecting those canonical sandbox policies into
  `PermissionProfileToml`, then merge user overrides at the TOML layer
  before compilation.
  - Add config parsing support for `:slash_tmp` so the built-in
  `:workspace` parent can be expressed in the same TOML-shaped filesystem
  table as user profiles.
  - Document that `PermissionsToml::resolve_profile()` returns an
  already-merged `PermissionProfileToml`, and return that profile directly
  after removing the resolved-profile wrapper.
  - Extend the config test for `extends = ":workspace"` to assert that
  inherited `":slash_tmp" = "write"` is preserved and that a child
  `":tmpdir" = "read"` entry replaces the inherited `write` entry.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-protocol`
  - `just test -p codex-core
  permissions_profiles_resolve_extends_parent_first_with_child_overrides`
  - `just test -p codex-core
  default_permissions_profile_can_extend_builtin_workspace`
  - `just test -p codex-core`
    - Result: 2596 passed, 4 failed, 1 timed out.
  - The failures were existing sandbox/environment-sensitive tests
  unrelated to this permissions change:
  
  `suite::user_shell_cmd::user_shell_command_does_not_set_network_sandbox_env_var`,
  
  `suite::user_shell_cmd::user_shell_command_history_is_persisted_and_shared_with_model`,
  
  `suite::abort_tasks::interrupt_persists_turn_aborted_marker_in_next_request`,
      `suite::abort_tasks::interrupt_tool_records_history_entries`, and
  
  `thread_manager::tests::start_thread_uses_all_default_environments_from_codex_home`.

  Michael Bolin · 2026-06-02 10:57:35 -07:00
  593df8773d
• Route Bazel CI through shared BuildBuddy remote config wrapper (#25156)

  ## Why
  
  Bazel remote configuration was selected in several CI scripts and
  workflow steps. That made the BuildBuddy tenant policy easy to duplicate
  and harder to audit, especially for fork pull requests that must not use
  the OpenAI tenant.
  
  This builds on
  [sluongng/buildbuddy-ci-host-routing](https://github.com/openai/codex/compare/main...sluongng:codex:sluongng/buildbuddy-ci-host-routing)
  and consolidates the policy in one place.
  
  ## What to do if this breaks you
  
  See `codex-rs/docs/bazel.md` for details. TLDR:
  
  1. make a BuildBuddy API key and put it in `~/.bazelrc`
  2. if you're an OpenAI employee, add `common
  --config=buildbuddy-openai-rbe` to `user.bazelrc` in the repo root
  
  Run `just bazel-test` to ensure it works.
  
  Note that `just bazel-remote-test` no longer exists, you need to select
  a remote configuration as documented to use RBE.
  
  ## What changed
  
  - Add `.github/scripts/run_bazel_with_buildbuddy.py` as the shared Bazel
  wrapper and Python library. It selects the OpenAI host only for trusted
  upstream GitHub Actions runs, routes keyed fork runs to the generic
  host, and falls back to local Bazel execution when no key is available.
  - Move endpoint selection into explicit `.bazelrc` configurations and
  update Bazel CI, query helpers, and `rusty_v8` staging to use the shared
  policy. Loading-phase target-discovery queries remain local.
  - Add wrapper and `rusty_v8` unit coverage, plus `just test-scripts` for
  the `.github/scripts` Python tests.
  - Document local Bazel usage, `user.bazelrc` setup, BuildBuddy
  configurations, and CI behavior in `codex-rs/docs/bazel.md`.
  
  ## Validation
  
  - `just test-scripts`
  - `bash -n .github/scripts/run-bazel-ci.sh
  .github/scripts/run-bazel-query-ci.sh
  .github/scripts/run-argument-comment-lint-bazel.sh
  scripts/list-bazel-clippy-targets.sh`
  - `python3 -m py_compile .github/scripts/run_bazel_with_buildbuddy.py
  .github/scripts/test_run_bazel_with_buildbuddy.py
  .github/scripts/test_rusty_v8_bazel.py
  .github/scripts/rusty_v8_bazel.py`
  - `ruff check .github/scripts/run_bazel_with_buildbuddy.py
  .github/scripts/test_run_bazel_with_buildbuddy.py
  .github/scripts/test_rusty_v8_bazel.py
  .github/scripts/rusty_v8_bazel.py`

  Adam Perry @ OpenAI · 2026-06-02 09:56:20 -07:00
  ebb7980369
• Skip startup prewarm when websockets are disabled (#25868)

  ## Summary
  - skip startup websocket prewarm setup when the model client has
  Responses-over-WebSocket disabled
  - avoid making HTTP-only sessions build prewarm prompt/tool state that
  cannot produce a reusable websocket session
  
  ## Why
  Recent macOS timing flakes were timing out while waiting for first-turn
  events in HTTP-only core tests. Startup prewarm is only useful for
  websocket-capable providers, but it was scheduled for every session. For
  HTTP-only test providers this added unnecessary async startup work
  before the regular turn could reach the mocked response flow.
  
  ## Testing
  - bazel test //codex-rs/core:core-all-test
  --test_filter=suite::auto_review::remote_model_override_uses_catalog_model_for_strict_auto_review
  --test_output=errors
  - bazel test //codex-rs/core:core-all-test
  --test_filter=suite::request_permissions_tool::approved_folder_write_request_permissions_unblocks_later_apply_patch
  --test_output=errors

  jif · 2026-06-02 17:27:30 +02:00
  859dbe2761
• [app-server][core] Add connector-level Guardian reviewer overrides (#25167)

  Context: https://openai.slack.com/archives/C0B4JAF0Q2C/p1779912328647229
  
  ```
  approvals_reviewer = "auto_review"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "user"
  default_tools_approval_mode = "prompt"
  ```
  
  <img width="230" height="84" alt="Screenshot 2026-05-31 at 11 56 34 AM"
  src="https://github.com/user-attachments/assets/e319f8f7-0983-42a7-98cd-3302732fa406"
  />
  
  <img width="841" height="233" alt="Screenshot 2026-05-31 at 11 52 42 AM"
  src="https://github.com/user-attachments/assets/7ac76645-4e90-4d00-8242-f031146a22a5"
  />
  
  -------
  
  ```
  approvals_reviewer = "user"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "auto_review"
  default_tools_approval_mode = "prompt"
  ```
  <img width="195" height="83" alt="Screenshot 2026-05-31 at 12 02 27 PM"
  src="https://github.com/user-attachments/assets/3d374dc8-8aa2-466f-a13f-e4ed8567aa2e"
  />
  <img width="771" height="207" alt="Screenshot 2026-05-31 at 12 05 42 PM"
  src="https://github.com/user-attachments/assets/105c2575-68d6-4ca6-8e69-dc8c82da36a2"
  />
  
  
  
  ## Summary
  - add `apps.<connector_id>.approvals_reviewer` to override Guardian or
  user review routing per connected app
  - apply overrides across direct app MCP calls, delegated MCP prompts,
  and app-server MCP elicitation review while preserving global behavior
  for non-app MCP servers
  - expose and document the config through app-server v2 and generated
  schemas, while honoring global managed reviewer requirements
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Alex Zamoshchin · 2026-06-02 17:04:11 +02:00
  4d80d808b4
• Run Codex async main on a sized stack (#25847)

  ## Why
  
  `Runtime::block_on` executes the top-level future on the caller's OS
  thread, not on one of Tokio's worker threads. That matters for the
  interactive CLI because the Tokio runtime already configures larger
  worker stacks, while the process main thread can still have a smaller
  platform default stack.
  
  This showed up as a `/clear` crash on macOS: starting a fresh TUI thread
  reloads config, and the stack-heavy TOML deserialization path can
  overflow before the new session is actually started.
  
  ## What Changed
  
  - Run the regular `arg0_dispatch_or_else` async entrypoint on a named
  `codex-main` thread.
  - Give that thread the same `TOKIO_WORKER_STACK_SIZE_BYTES` stack budget
  already used for Tokio worker threads.
  - Keep `Arg0DispatchPaths` and the arg0 alias guard lifetime behavior
  the same.
  - Resume panics from the spawned main thread so panic behavior is
  preserved.
  
  ## Verification
  
  - `cargo check -p codex-cli` currently fails because the top-level
  CLI/TUI future is not `Send` under the new thread boundary.

  jif · 2026-06-02 16:34:48 +02:00
  3766941161
• flake: Keep plugin test homes alive (#25857)

  ## Summary
  
  Keep the full `TestCodex` harness alive in plugin integration tests
  instead of returning only the `CodexThread`.
  
  ## Why
  
  The helper was moving a temporary `codex_home` into `TestCodex`, then
  immediately dropping the harness and returning only the thread. For
  plugin MCP tests, the MCP server cwd is inside that temporary home. If
  the temp directory is removed while MCP startup is still racing, the
  server launch can fail with `No such file or directory`.
  
  Keeping the harness in scope keeps the temp home alive for the test
  duration and removes the lifetime race behind the recent
  `explicit_plugin_mentions_inject_plugin_guidance` flake.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core
  explicit_plugin_mentions_inject_plugin_guidance`

  jif · 2026-06-02 16:21:22 +02:00
  b9af5d1234
• Reduce stack pressure in session startup and config rebuilds (#25844)

  ## Why
  
  `/clear` starts a fresh thread with `InitialHistory::Cleared`, which
  re-enters the thread/session startup path. That path now builds large
  async futures through `ThreadManagerState::spawn_thread_with_source`,
  `Codex::spawn`, and `Session::new`. Separately, TUI config rebuilds for
  cwd and permission-profile changes build a similarly heavy
  `ConfigBuilder::build()` future inside the app task. In debug and Bazel
  runs, those call chains can put enough state on the caller stack to
  abort before startup or config refresh completes.
  
  This change keeps the behavior the same while moving the heaviest future
  frames off the caller stack.
  
  ## What changed
  
  - Box `Codex::spawn(...)` in `codex-rs/core/src/thread_manager.rs`
  before awaiting it from `spawn_thread_with_source`.
  - Box `Session::new(...)` in `codex-rs/core/src/session/mod.rs` before
  awaiting it from `Codex::spawn_internal`.
  - Route `ConfigBuilder::build()` through a small `tokio::spawn` helper
  in `codex-rs/tui/src/app/config_persistence.rs` so cwd and
  permission-profile config rebuilds run on a runtime worker stack while
  preserving error context.
  
  ## Verification
  
  CI is running on the PR.
  
  No new targeted tests were added. This is a mechanical stack-pressure
  reduction that keeps the existing behavior and error propagation intact.

  jif-oai · 2026-06-02 15:42:47 +02:00
  1dd731305a
• Test runtime selector before first turn (#25724)

  Stack split from #25708. Original PR intentionally left open. This fifth
  PR adds coverage that a remotely selected multi-agent runtime is applied
  when the model is selected before the first turn.

  jif-oai · 2026-06-02 15:01:10 +02:00
  33273e4258
• Test remote multi-agent runtime selector override (#25723)

  Stack split from #25708. Original PR intentionally left open. This
  fourth PR adds coverage that remote model multi-agent runtime selectors
  override local feature flag defaults.

  jif-oai · 2026-06-02 14:48:13 +02:00
  66991c949f
• fix: main oops (#25840)

  Fix main, comment is self-explainatory

  jif-oai · 2026-06-02 14:48:04 +02:00
  06e9a33d09