5752 Commits

This Branch

This Branch

All Branches

• Increase app-server WebSocket outbound buffer (#19246)

  Fixes #18203.
  
  ## Why
  
  Remote TUI clients connected through `codex app-server --listen
  ws://...` can receive short bursts of outbound turn and tool-output
  notifications. The WebSocket transport previously used the shared
  128-message channel capacity for its outbound writer queue, so a healthy
  client that briefly lagged during normal output streaming could fill the
  queue and be disconnected immediately.
  
  This is a smaller mitigation than #18265: instead of adding a new
  overflow/backpressure pipeline, keep the existing non-blocking router
  behavior and give WebSocket clients enough bounded headroom for
  realistic bursts.
  
  ## What Changed
  
  - Added a WebSocket-only outbound writer capacity of `64 * 1024`
  messages.
  - Used that larger capacity only for the WebSocket data writer queue in
  `codex-rs/app-server/src/transport/websocket.rs`.
  - Left the shared `CHANNEL_CAPACITY` and the existing disconnect-on-full
  behavior unchanged for internal/control channels and genuinely stuck
  clients.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  transport::tests::broadcast_does_not_block_on_slow_connection`
  - Manually retried the #18203 repro prompt against the remote TUI and
  confirmed it stayed connected.

  Eric Traut · 2026-04-23 18:47:28 -07:00
  72f757d144
• refactor: route Codex auth through AuthProvider (#18811)

  ## Summary
  
  This PR moves Codex backend request authentication from direct
  bearer-token handling to `AuthProvider`.
  
  The new `codex-auth-provider` crate defines the shared request-auth
  trait. `CodexAuth::provider()` returns a provider that can apply all
  headers needed for the selected auth mode.
  
  This lets ChatGPT token auth and AgentIdentity auth share the same
  callsite path:
  - ChatGPT token auth applies bearer auth plus account/FedRAMP headers
  where needed.
  - AgentIdentity auth applies AgentAssertion plus account/FedRAMP headers
  where needed.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Callsite Migration
  
  | Area | Change |
  | --- | --- |
  | backend-client | accepts an `AuthProvider` instead of a raw
  token/header |
  | chatgpt client/connectors | applies auth through
  `CodexAuth::provider()` |
  | cloud tasks | keeps Codex-backend gating, applies auth through
  provider |
  | cloud requirements | uses Codex-backend auth checks and provider
  headers |
  | app-server remote control | applies provider headers for backend calls
  |
  | MCP Apps/connectors | gates on `uses_codex_backend()` and keys caches
  from generic account getters |
  | model refresh | treats AgentIdentity as Codex-backend auth |
  | OpenAI file upload path | rejects non-Codex-backend auth before
  applying headers |
  | core client setup | keeps model-provider auth flow and allows
  AgentIdentity through provider-backed OpenAI auth |
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. This PR: migrate Codex backend auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-23 17:14:02 -07:00
  5882f3f95e
• ci: derive cache-stable Windows Bazel PATH (#19161)

  ## Why
  
  The BuildBuddy runs for PR #19086 and the later `main` build had the
  same source tree, but their Windows Bazel action and test cache keys did
  not line up. Comparing the downloaded execution logs showed the full
  GitHub-hosted Windows runner `PATH` had changed from
  `apache-maven-3.9.14` to `apache-maven-3.9.15`.
  
  This repo is not using Maven; the Maven entry was just ambient
  hosted-runner state. The problem was that Windows Bazel CI was still
  forwarding the whole runner `PATH` into Bazel via `--action_env=PATH`,
  `--host_action_env=PATH`, and `--test_env=PATH`, which made otherwise
  reusable cache entries sensitive to unrelated runner image churn.
  
  After discussion with the Bazel and BuildBuddy folks, the better shape
  for this change was to stop asking Bazel to inherit the ambient Windows
  `PATH` and instead compute one explicit cache-stable `PATH` in the
  Windows setup action that already prepares the CI toolchain environment.
  
  ## What
  
  - remove Windows `PATH` passthrough from `.bazelrc`
  - export `CODEX_BAZEL_WINDOWS_PATH` from
  `.github/actions/setup-bazel-ci/action.yml`
  - move the PATH derivation logic into
  `.github/scripts/compute-bazel-windows-path.ps1` so the allow-list is
  easier to review and document
  - keep only the Windows tool locations these Bazel jobs actually need:
  MSVC and SDK paths, Git, PowerShell, Node, DotSlash, and the standard
  Windows system directories
  - update `.github/scripts/run-bazel-ci.sh` to require that explicit
  value and forward it to Bazel action, host action, and test environments
  - log the derived `CODEX_BAZEL_WINDOWS_PATH` in the setup step to
  simplify cache-key debugging
  
  ## Verification
  
  - `bash -n .github/scripts/run-bazel-ci.sh`
  - `ruby -e 'require "yaml"; YAML.load_file(ARGV[0])'
  .github/actions/setup-bazel-ci/action.yml`
  - PowerShell parse check for
  `.github/scripts/compute-bazel-windows-path.ps1`
  - simulated a representative Windows `PATH` in PowerShell; the
  allow-list retained MSVC, Git, PowerShell, Node, Windows, and DotSlash
  entries while dropping Maven

  Michael Bolin · 2026-04-23 22:28:00 +00:00
  a9f75e5cda
• do not attempt ACLs on installed codex dir (#19214)

  We used to attempt a read-ACL on the same dir as `codex.exe` to grant
  the sandbox user the ability to invoke `codex-command-runner.exe`. That
  worked for the CLI case but it always fails for the installed desktop
  app.
  
  We have another solution already in place that copies
  `codex-command-runner.exe` to `CODEX_HOME/.sandbox-bin` so we don't even
  need this anymore. It causes a scary looking error in the logs that is a
  non-issue and is therefore confusing

  iceweasel-oai · 2026-04-23 22:21:48 +00:00
  867820ac7e
• guide Windows to use -WindowStyle Hidden for Start-Process calls (#19044)

  Sometimes codex runs `Start-Process` to start up a service or something
  similar, which launches a user-visible powershell window that probably
  doesn't get cleaned up. This instruction change encourages it to do so
  using a hidden window.
  
  This was reported in
  https://openai.slack.com/archives/C09K6H5DZC4/p1776741272870519
  
  One caveat is that this change won't do anything to cleanup these
  processes, but it will stop them from polluting the user's visible
  workspace
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  iceweasel-oai · 2026-04-23 21:36:17 +00:00
  2e228969be
• tests: isolate approval fixtures from host rules (#18288)

  ## Why
  
  Several approval-focused tests were unintentionally sensitive to
  host-level rule files. On machines with broader allowed command
  prefixes, commonly allowed commands such as `/bin/date` could bypass the
  approval path these tests were meant to exercise, making the fixtures
  depend on the developer or CI host configuration.
  
  ## What changed
  
  - Pins the approval matrix fixture to the explicit user reviewer so it
  does not inherit a host reviewer.
  - Changes OTel approval fixtures to request `/usr/bin/touch
  codex-otel-approval-test`, avoiding a command that may be pre-approved
  by local rules.
  - Clears the config layer stack for the permissions-message assertion
  that needs to compare only the permissions text under test.
  
  ## Verification
  
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED cargo test -p codex-core --test
  all approval_matrix_covers_all_modes -- --nocapture`
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED cargo test -p codex-core --test
  all permissions_messages -- --nocapture`

  Michael Bolin · 2026-04-23 14:12:09 -07:00
  040976b218
• Mark hooks schema fixtures as generated (#19194)

  ## Summary
  - mark generated hooks schema fixture JSON as linguist-generated
  - keep the app-server protocol generated schema marking unchanged
  
  ## Validation
  - `git check-attr linguist-generated --
  codex-rs/hooks/schema/generated/post-tool-use.command.output.schema.json`
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-23 14:11:16 -07:00
  dc5cf1ff78
• Stabilize plugin MCP tools test (#19191)

  ## Summary
  
  The plugin MCP tool-listing test could hide MCP startup failures by
  polling `ListMcpTools` until its own 30s deadline. If the plugin MCP
  server startup had already failed or timed out, the session-owned MCP
  manager would keep returning an empty tool list, so CI only reported
  `discovered tools: []` instead of the startup state that mattered.
  
  This makes the test synchronize on `McpStartupComplete` for the sample
  plugin MCP server before asserting listed tools, and gives the
  Bazel-launched test server a larger startup window.
  
  ## Notes
  
  Confidence is about 80%. The source path strongly supports the RCA: a
  failed MCP startup is represented as an empty tool list through
  `ListMcpTools`, so the old polling contract could not distinguish "not
  ready yet" from "startup already failed." I could not retrieve the CI
  execution-log artifact to confirm the exact hidden startup error, but
  the observed Ubuntu Bazel failure matches this path: repeated
  `ListMcpTools` responses with no tools until the test-local timeout
  fired.
  
  I think this is the right solution because it keeps plugin behavior
  unchanged and fixes only the test contract. Future startup failures
  should now report the `McpStartupComplete` failure/cancellation instead
  of timing out on an empty tool snapshot.
  
  This test was introduced in https://github.com/openai/codex/pull/12864.

  Eric Traut · 2026-04-23 14:08:40 -07:00
  a50cb205b7
• Fix /review interrupt and TUI exit wedges (#18921)

  Addresses #11267
  
  ## Summary
  `/review` can be interrupted while it is still spawning the review
  sub-agent. That spawn path lives in `codex-core` and did not observe the
  task cancellation token until after `Codex::spawn` returned, so an
  interrupted review could keep building a child session and leave the TUI
  in a wedged state.
  
  The TUI exit path also waited indefinitely for app-server
  `thread/unsubscribe`, which made Ctrl+C look broken if the app-server
  was already stuck. This makes interactive delegate startup
  cancellation-aware and bounds the TUI shutdown-first unsubscribe wait
  with a short UI escape-hatch timeout.
  
  ## Testing
  I reproed the hang using the steps in the bug report. Confirmed hang no
  longer exists after fix.

  Eric Traut · 2026-04-23 13:28:12 -07:00
  3f8c06e457
• Stabilize approvals popup disabled-row test (#19178)

  ## Summary
  
  The Windows Bazel job has been failing in
  `chatwidget::tests::permissions::approvals_popup_navigation_skips_disabled`
  because the test assumed a fixed approvals popup row order and shortcut
  for the disabled permissions option. The approvals popup can include
  platform-specific rows, so those assumptions made the test brittle.
  
  This updates the test to derive the disabled row shortcut from the
  rendered popup and assert navigation continues to skip disabled rows
  before checking that disabled numeric shortcuts do not close or accept
  the popup.

  Eric Traut · 2026-04-23 13:21:35 -07:00
  cccc1b618e
• use a version-specific suffix for command runner binary in .sandbox-bin (#19180)

  we copy `codex-command-runner.exe` into `CODEX_HOME/.sandbox-bin/` so
  that it can be executed by the sandbox user.
  We also detect if that version is stale and copy a new one in if so.
  
  This can fail when you are running multiple versions of the app - the
  file in `.sandbox-bin` can look stale because it comes from another app
  build.
  
  This change allows us to have multiple versions in there for different
  CLI versions, and it fallsback to a `size+mtime` hash in the filename
  for dev builds that don't report a real CLI version.

  iceweasel-oai · 2026-04-23 13:16:26 -07:00
  d169bb541e
• Add app-server marketplace upgrade RPC (#19074)

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

  xli-oai · 2026-04-23 13:00:46 -07:00
  0d6a90cd6b
• fix(exec-server): retain output until streams close (#18946)

  ## Why
  
  A Mac Bazel run hit a flake in
  `server::handler::tests::output_and_exit_are_retained_after_notification_receiver_closes`
  where the read path observed process exit but lost the expected buffered
  stdout (`first\nsecond\n`). See the [GitHub Actions
  job](https://github.com/openai/codex/actions/runs/24758468552/job/72436716505)
  and [BuildBuddy
  invocation](https://app.buildbuddy.io/invocation/37475a12-4ef2-45fb-ab8a-e49a2aba1d59).
  
  The underlying race is that process exit is not the same thing as
  stdout/stderr closure. If a child or grandchild inherits the pipe write
  end, or a process duplicates it with `dup2`, the watched process can
  exit while the stream is still open and more output can still arrive.
  The exec-server was starting exited-process retention cleanup from the
  exit event, so the process entry could be removed before the output
  streams had actually closed.
  
  While stress-testing the exec-server unit suite,
  `server::handler::tests::long_poll_read_fails_after_session_resume`
  exposed a separate test race: it started a short-lived command that
  could exit and wake the pending long-poll read before the session-resume
  assertion observed the resumed-session error. That test is intended to
  cover resume eviction, not process-exit delivery, so this change keeps
  the process alive and quiet while the second connection resumes the
  session.
  
  ## What changed
  
  - Keep exec-server process entries retained until stdout/stderr streams
  close, then start the post-exit retention timer from the closed event.
  - Wake long-poll readers when the closed event is emitted.
  - Add focused `local_process` unit coverage that proves late output is
  still retained after the short test retention interval has elapsed, and
  that closed process entries are eventually evicted.
  - Add a local and remote regression test where a parent exits while a
  child keeps inherited stdout open. The child waits on an explicit
  release file, so the test deterministically observes exit first,
  releases the child, then requires a nonzero-wait read from the exit
  sequence to receive the late output.
  - In `codex-rs/exec-server/src/server/handler/tests.rs`, make
  `long_poll_read_fails_after_session_resume` run a long-lived silent
  command instead of a short command that prints and exits. This isolates
  the test to session-resume behavior and prevents a normal process exit
  from satisfying the pending long-poll read first.
  
  ## Testing
  
  - `cargo test -p codex-exec-server
  exec_process_retains_output_after_exit_until_streams_close`
  - `cargo test -p codex-exec-server local_process::tests`
  - `cargo test -p codex-exec-server`
  - `just fix -p codex-exec-server`
  - `bazel test //codex-rs/exec-server:exec-server-unit-tests
  //codex-rs/exec-server:exec-server-exec_process-test
  //codex-rs/exec-server:exec-server-file_system-test
  //codex-rs/exec-server:exec-server-http_client-test
  //codex-rs/exec-server:exec-server-initialize-test
  //codex-rs/exec-server:exec-server-process-test
  //codex-rs/exec-server:exec-server-websocket-test`
  - `bazel test --runs_per_test=25
  //codex-rs/exec-server:exec-server-unit-tests`
  
  ## Documentation
  
  No docs update needed; this is an internal exec-server correctness fix.

  Michael Bolin · 2026-04-23 19:49:58 +00:00
  491a3058f6
• shell-escalation: carry resolved permission profiles (#18287)

  ## Why
  
  Shell escalation still has adapter code that expects a legacy sandbox
  policy, but command approvals should carry the resolved
  `PermissionProfile` so callers can reason about the granted permissions
  canonically.
  
  ## What changed
  
  This introduces profile-shaped resolved escalation permissions while
  retaining the derived legacy sandbox policy for the Unix escalation
  adapter. It updates approval types, the escalation server protocol, and
  tests that inspect escalated command permissions.
  
  ## Verification
  
  - `cargo test -p codex-core --test all handle_container_exec_ --
  --nocapture`
  - `cargo test -p codex-core --test all handle_sandbox_ -- --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18287).
  * #18288
  * __->__ #18287

  Michael Bolin · 2026-04-23 12:46:19 -07:00
  9c0eced391
• [rollout_trace] Trace tool and code-mode boundaries (#18878)

  ## Summary
  
  Extends rollout tracing across tool dispatch and code-mode runtime
  boundaries. This records canonical tool-call lifecycle events and links
  code-mode execution/wait operations back to the model-visible calls that
  caused them.
  
  ## Stack
  
  This is PR 3/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is about attribution. Reviewers should focus on whether direct
  tool calls, code-mode-originated tool calls, waits, outputs, and
  cancellation boundaries are recorded with enough source information for
  deterministic reduction without coupling the reducer to live runtime
  internals.
  
  The stack remains valid after this layer: tool and code-mode traces
  reduce through the existing crate model, while the broader session and
  multi-agent relationships are added in the next PR.

  cassirer-openai · 2026-04-23 12:22:11 -07:00
  6d09b6752d
• mcp: include permission profiles in sandbox state (#18286)

  ## Why
  
  MCP tool calls can receive a serialized `SandboxState` when a server
  declares the sandbox-state capability. That state is one of the places
  MCP runtimes learn what permissions Codex is operating under. As the
  permissions migration makes `PermissionProfile` the canonical
  representation, MCP consumers should be able to read that profile
  directly instead of reconstructing permissions from the legacy
  `SandboxPolicy`.
  
  ## What changed
  
  - Adds optional `permissionProfile` to `codex_mcp::SandboxState`, while
  keeping `sandboxPolicy` for existing MCP consumers.
  - Populates `permissionProfile` from the current `TurnContext` when
  serializing sandbox state for MCP tool calls.
  
  ## Verification
  
  - Current GitHub Actions for this PR are passing.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18286).
  * #18288
  * #18287
  * __->__ #18286

  Michael Bolin · 2026-04-23 12:21:26 -07:00
  ff22982d75
• tui: carry permission profiles on user turns (#18285)

  ## Why
  
  Per-turn permission overrides should use the same canonical profile
  abstraction as session configuration. That lets TUI submissions preserve
  exact configured permissions without round-tripping through legacy
  sandbox fields.
  
  ## What changed
  
  This adds `permission_profile` to user-turn operations, threads it
  through TUI/app-server submission paths, fills the new field in existing
  test fixtures, and adds coverage that composer submission includes the
  configured profile.
  
  ## Verification
  
  - `cargo test -p codex-tui permissions -- --nocapture`
  - `cargo test -p codex-core --test all permissions_messages --
  --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18285).
  * #18288
  * #18287
  * #18286
  * __->__ #18285

  Michael Bolin · 2026-04-23 11:54:17 -07:00
  f90cc0ee64
• Add remote thread config endpoint (#18908)

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

  Rasmus Rygaard · 2026-04-23 11:46:06 -07:00
  f11583b8f6
• Use Auto-review wording for fallback rationale (#19168)

  ## Why
  
  PR #18797 currently surfaces fallback rationale text that names Guardian
  directly.
  
  ## What changed
  
  - Updated the bare allow and bare deny fallback rationales in
  `codex-rs/core/src/guardian/prompt.rs` from Guardian to Auto-review.
  - Updated the existing bare allow parser test and added explicit bare
  deny parser coverage.
  
  ## Verification
  
  - `cargo test -p codex-core parse_guardian_assessment_treats_bare`

  maja-openai · 2026-04-23 11:42:43 -07:00
  cff337e4e3
• Move marketplace add/remove and startup sync out of core. (#19099)

  Move more things to core-plugins.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-23 11:27:17 -07:00
  198eddd25d
• ci: add macOS keychain entitlements (#19167)

  ## Summary
  
  - add macOS application and team identifiers to the release signing
  entitlements
  - add a Codex keychain access group for release-signed macOS binaries
  - keep the existing JIT entitlement unchanged
  
  ## Why
  
  Codex release binaries are signed with the OpenAI Developer ID team, but
  the current entitlements plist only grants JIT. macOS Keychain and
  Secure Enclave operations that create persistent keys can require the
  process to carry an application identifier and keychain access group.
  Adding these entitlements gives release-signed binaries a stable
  Keychain namespace for Codex-owned device keys.
  
  ## Validation
  
  - `plutil -lint
  .github/actions/macos-code-sign/codex.entitlements.plist`

  Ruslan Nigmatullin · 2026-04-23 11:20:58 -07:00
  e9165b9f40
• app-server: add Unix socket transport (#18255)

  ## Summary
  - add unix:// app-server transport backed by the shared codex-uds crate
  - reuse the websocket connection loop for axum and tungstenite-backed
  streams
  - add codex app-server proxy to bridge stdio clients to the control
  socket
  - tolerate Windows UDS backends that report a missing rendezvous path as
  connection refused before binding
  
  ## Tests
  - cargo test -p codex-app-server
  control_socket_acceptor_forwards_websocket_text_messages_and_pings
  - cargo test -p codex-app-server
  - just fmt
  - just fix -p codex-app-server
  - git -c core.fsmonitor=false diff --check

  Ruslan Nigmatullin · 2026-04-23 11:09:25 -07:00
  8a0ab3fc13
• Respect explicit untrusted project config (#18626)

  ## Why
  
  Fixes #18475. A `-c` override such as `projects.<cwd>.trust_level =
  "untrusted"` is meant to be a runtime config override, but app-server
  thread startup treated any non-trusted project as eligible for automatic
  trust persistence when a permissive sandbox/cwd was requested. That
  meant an explicit `untrusted` session override could still cause
  `config.toml` to be updated with `trusted`.
  
  ## What changed
  
  The app-server auto-trust path now runs only when the active project
  trust level is unknown. Explicit `trusted` and explicit `untrusted`
  values are both respected, regardless of whether they came from
  persisted config or session flags.
  
  A focused `thread/start` test now covers the explicit `untrusted` case
  with a permissive sandbox request.
  
  ## Verification
  
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server`

  Eric Traut · 2026-04-23 10:51:17 -07:00
  c2423f42d1
• [codex] Implement remote thread store methods (#19008)
  Tom · 2026-04-23 17:49:28 +00:00
  f1061d9d07
• [codex] Route live thread writes through ThreadStore (#18882)

  Begin migrating the thread write codepaths to ThreadStore.
  
  This starts using ThreadStore inside of core session code, not only in
  the app server code.
  
  Rework the interfaces around thread recording/persistence. We're left
  with the following:
  
  * `ThreadManager`: owns the process-level registry of loaded threads and
  handles cross-thread orchestration: start, resume, fork, lookup, remove,
  and route ops to running CodexThreads.
  * `CodexThread`: represents one loaded/running thread from the outside.
  It is the handle app-server and callers use to submit ops, inspect
  session metadata, and shut the thread down.
  * `LiveThread`: session-owned persistence lifecycle handle for one
  active thread. Core session code uses it to append rollout items,
  materialize lazy persistence, flush, shutdown, discard init-failed
  writers, and load that thread’s persisted history.
  * `ThreadStore`: storage backend abstraction. It answers “how are
  threads persisted, read, listed, updated, archived?” Local and remote
  implementations live behind this trait.
  * `LocalThreadStore`: local ThreadStore implementation. It owns the
  file/sqlite-specific details and keeps RolloutRecorder as a local
  implementation detail.
  
  This is a few too many Thread abstractions for my liking, but they do
  all represent different concepts / needs / layers.
  
  Migration note: in places where the core code explicitly requires a
  path, rather than a thread ID, throw an error if we're running with a
  remote store.
  
  Cover the new local live-writer lifecycle with focused tests and
  preserve app-server thread-start behavior, including ephemeral pathless
  sessions.

  Tom · 2026-04-23 10:17:09 -07:00
  f1923a38b1
• Add excludeTurns parameter to thread/resume and thread/fork (#19014)

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

  David de Regt · 2026-04-23 10:07:59 -07:00
  3d3028a5a9
• Add remote thread config loader protos (#18892)

  ## Why
  
  Thread-scoped config needs a stable boundary between the app/session
  owner and the config stack. Instead of having call sites manually copy
  thread config fields into individual overrides, this adds the proto and
  Rust plumbing needed for a `ThreadConfigLoader` implementation to return
  typed sources that can be translated into ordinary config layer entries.
  
  Keeping the remote payload typed also makes precedence easier to reason
  about: session-owned thread config maps back to the existing session
  config source, while user-owned thread config is represented separately
  without introducing a new config-layer source until it has TOML-backed
  fields.
  
  ## What changed
  
  - Added the `codex.thread_config.v1` protobuf service and generated Rust
  module for loading thread config sources.
  - Added `RemoteThreadConfigLoader`, which calls the gRPC service, parses
  `SessionThreadConfig` / `UserThreadConfig`, and validates provider
  fields such as `wire_api`, auth timeout, and absolute auth cwd.
  - Added proto generation tooling under
  `config/scripts/generate-proto.sh` and
  `config/examples/generate-proto.rs`.
  - Added `ThreadConfigLoader::load_config_layers`, plus static/no-op
  loader helpers, so tests and callers can use the same typed loader
  interface while config-layer translation stays centralized.
  
  ## Verification
  
  - `cargo test -p codex-config thread_config`

  Rasmus Rygaard · 2026-04-23 10:06:05 -07:00
  0b4f694347
• feat: drop spawned-agent context instructions (#19127)

  ## Why
  
  MultiAgentV2 children should not receive an extra model-visible
  developer fragment just because they were spawned. The parent/configured
  developer instructions should carry through normally, but the dedicated
  `<spawned_agent_context>` block is no longer desired.
  
  ## What changed
  
  - Removed the `SpawnAgentInstructions` context fragment and its
  `<spawned_agent_context>` wrapper.
  - Stopped appending spawned-agent instructions in
  `codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs`.
  - Updated subagent notification coverage to assert inherited parent
  developer instructions without expecting the spawned-agent wrapper.
  
  ## Verification
  
  - `cargo test -p codex-core --test all
  spawned_multi_agent_v2_child_inherits_parent_developer_context --
  --nocapture`
  - `cargo test -p codex-core --test all
  skills_toggle_skips_instructions_for_parent_and_spawned_child --
  --nocapture`
  - `cargo test -p codex-core --test all subagent_notifications --
  --nocapture`

  jif-oai · 2026-04-23 18:54:45 +02:00
  a2f868c9d6
• [codex] Fix plugin marketplace help usage (#18710)

  ## Summary
  - Updates generated CLI help for plugin marketplace commands to show the
  full `codex plugin marketplace ...` namespace.
  - Adds a regression test covering the marketplace command and its `add`,
  `upgrade`, and `remove` help pages.
  
  ## Root Cause
  The marketplace parser already lived under `codex plugin marketplace`,
  but Clap generated usage text from the child parser's standalone command
  name. That made help output show stale `codex marketplace ...`
  instructions even though the top-level `codex marketplace` command no
  longer parses.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-cli`
  - `./target/debug/codex plugin marketplace --help`

  xli-oai · 2026-04-23 09:48:37 -07:00
  e18bfeec91
• tui: sync session permission profiles (#18284)

  ## Why
  
  Once `SessionConfigured` carries the active `PermissionProfile`, the TUI
  must treat that as authoritative session state. Otherwise the widget can
  keep stale local permission details after a session is configured or
  resumed.
  
  The TUI also keeps a local `Config` copy used for later operations, so
  session-sourced profiles and subsequent local sandbox changes need to
  keep the derived split runtime permissions in sync. Because this PR may
  land before the follow-up user-turn profile plumbing, embedded
  app-server turns also need a standalone path for carrying local runtime
  sandbox overrides.
  
  ## What changed
  
  - Sync the chat widget runtime filesystem/network permissions from
  `SessionConfigured.permission_profile`, with the legacy `sandbox_policy`
  as the fallback.
  - Recompute split runtime permissions whenever the TUI applies or
  carries forward a local sandbox-policy override.
  - Mark feature-driven Auto-review sandbox changes as runtime sandbox
  overrides so the standalone embedded turn-start profile path is used
  even without the follow-up user-turn profile PR.
  - Send a turn-start `permissionProfile` for embedded,
  non-ExternalSandbox turns when the TUI has a runtime sandbox override;
  remote and ExternalSandbox turns keep using the legacy sandbox field.
  - Extend coverage for profile sync, local sandbox changes,
  ExternalSandbox fallback, feature-driven sandbox overrides, and
  turn-start permission override selection.
  
  ## Verification
  
  - `cargo test -p codex-tui
  update_feature_flags_enabling_guardian_selects_auto_review`
  - `cargo test -p codex-tui
  turn_start_permission_overrides_send_profiles_only_for_embedded_runtime_overrides`
  - `cargo test -p codex-tui permission_settings_sync`
  - `cargo test -p codex-tui
  session_configured_external_sandbox_keeps_external_runtime_policy`
  - `cargo test -p codex-tui
  session_configured_syncs_widget_config_permissions_and_cwd`
  - `just fix -p codex-tui`
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18284).
  * #18288
  * #18287
  * #18286
  * #18285
  * __->__ #18284

  Michael Bolin · 2026-04-23 09:47:53 -07:00
  5c239ad748
• Update safety check wording (#19149)

  Updates wording of cyber safety check.

  Eric Traut · 2026-04-23 08:53:25 -07:00
  1fda843fbc
• exec-server: wait for close after observed exit (#19130)

  ## Why
  
  Windows CI can flake in
  `server::handler::tests::output_and_exit_are_retained_after_notification_receiver_closes`
  after a process has exited but before both output streams have closed.
  `exec/read` returned immediately whenever `exited` was true, so callers
  that had already observed the exit event could spin instead of
  long-polling for the later `closed` state.
  
  ## What Changed
  
  - Keep returning immediately when a terminal exit event is newly
  observable.
  - Allow later reads, after the caller has advanced past that event, to
  wait for `closed` or new output until `wait_ms` expires.
  
  ## Verification
  
  - CI pending.

  jif-oai · 2026-04-23 16:50:17 +02:00
  45e1742030
• Reject agents.max_threads with multi_agent_v2 (#19129)

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

  jif-oai · 2026-04-23 13:31:54 +02:00
  d3b044938d
• Fix auto-review config compatibility across protocol and SDK (#19113)

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

  Won Park · 2026-04-23 03:12:56 -07:00
  17ae906048
• Support MCP tools in hooks (#18385)

  ## Summary
  
  Lifecycle hooks currently treat `PreToolUse`, `PostToolUse`, and
  `PermissionRequest` as Bash-only flows
  - hook schema constrains `tool_name` to `Bash`
  - hook input assumes a command-shaped `tool_input`
  - core hook dispatch path passes only shell command strings
  
  That means hooks cannot target MCP tools even though MCP tool names are
  model-visible and stable
  
  This change generalizes those hook paths so they can match and receive
  payloads for MCP tools while preserving the existing Bash behavior.
  
  ## Reviewer Notes
  
  I think these are the key files
  - `codex-rs/core/src/tools/handlers/mcp.rs`
  - `codex-rs/core/src/mcp_tool_call.rs`
  
  Otherwise the changes across apply_patch, shell, and unified_exec are
  mainly to rewire everything to be `tool_input` based instead of just
  `command` so that it'll make sense for MCP tools.
  
  ## Changes
  
  - Allow `PreToolUse`, `PostToolUse`, and `PermissionRequest` hook inputs
  to carry arbitrary `tool_name` and `tool_input` values instead of
  hard-coding `Bash` and command-only payloads.
  - Add MCP hook payload support through `McpHandler`, using the
  model-visible tool name from `ToolInvocation` and the raw MCP arguments
  as `tool_input`.
  - Include MCP tool responses in `PostToolUse` by serializing
  `McpToolOutput` into the hook response payload.
  - Run `PermissionRequest` hooks for MCP approval requests after
  remembered approval checks and before falling back to user-facing MCP
  elicitation.
  - Preserve exact matching for literal hook matchers like `Bash` and
  `mcp__memory__create_entities`, while keeping regex matcher support for
  patterns like `mcp__memory__.*` and `mcp__.*__write.*`.
  
  ---------
  
  Co-authored-by: Andrei Eternal <eternal@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-23 07:33:57 +00:00
  305825abd9
• app-server: include filesystem entries in permission requests (#19086)

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

  Michael Bolin · 2026-04-23 00:21:59 -07:00
  8bc667b07b
• Persist target default reasoning on model upgrade (#19085)

  ## Why
  
  When the TUI upgrade flow moves a user to a newer model, the accepted
  migration should also persist the target model's default reasoning
  effort. That keeps the upgraded model and reasoning setting aligned
  instead of carrying forward a stale previously saved effort from the old
  model.
  
  ## What changed
  
  - The accepted model migration path now updates in-memory config, TUI
  state, and persisted model selection with the target preset's
  `default_reasoning_effort`.
  - The upgrade destructuring keeps `reasoning_effort_mapping` explicitly
  unused because mappings are no longer consulted on accepted migrations.
  - Added a catalog test that starts with a pre-existing saved reasoning
  effort and verifies the accepted upgrade overwrites it with the target
  model default and emits the expected persistence events.
  - Rebasing onto current `main` also updates a TUI thread-session test
  helper for the latest `permission_profile` field and
  `ApprovalsReviewer::AutoReview` rename so CI compiles on the new base.
  
  ## Verification
  
  - `cargo test -p codex-tui model_catalog`
  - `cargo test -p codex-tui
  permission_settings_sync_updates_active_snapshot_without_rewriting_side_thread`

  Shijie Rao · 2026-04-22 23:36:15 -07:00
  993e3f407e
• Clarify cloud requirements error messages (#19078)

  ## Why
  The current cloud-requirements failures say `workspace-managed config`,
  which is ambiguous and can read like it refers to local managed config
  such as `managed_config.toml`.
  
  This code path only applies to cloud requirements, so the user-facing
  message should name that source directly.
  
  ## What changed
  - Updated the load failure in
  [`codex-rs/cloud-requirements/src/lib.rs`](https://github.com/openai/codex/blob/46e704d1f93054daa9a3b5a9100333c540c81d50/codex-rs/cloud-requirements/src/lib.rs)
  to say `failed to load cloud requirements (workspace-managed policies)`.
  - Updated the parse failure in the same file to use the same `cloud
  requirements (workspace-managed policies)` terminology.
  - Kept `workspace-managed` hyphenated because it is used as a compound
  modifier.
  - Updated the matching assertion in
  [`codex-rs/app-server/src/codex_message_processor.rs`](https://github.com/openai/codex/blob/46e704d1f93054daa9a3b5a9100333c540c81d50/codex-rs/app-server/src/codex_message_processor.rs).
  - Reused `CLOUD_REQUIREMENTS_LOAD_FAILED_MESSAGE` in the
  `codex-cloud-requirements` test where the test is asserting that
  crate-local contract directly.
  
  ## Testing
  `cargo test -p codex-cloud-requirements`

  Gav Verma · 2026-04-22 23:07:08 -07:00
  2ef2d675d6
• feat: Warn and continue on unknown feature requirements (#19038)

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

  xl-openai · 2026-04-22 22:50:44 -07:00
  951be1a8a1
• Use remote plugin IDs for detail reads and enlarge list pages (#19079)

  1. For remote plugin use plugin id (plugin name) directly for read
  plugin details;
  2. Request up to 200 remote plugins per directory list page.

  xl-openai · 2026-04-22 22:50:20 -07:00
  fb6308cf64
• Add computer_use feature requirement key (#19071)

  ## Summary
  - add the `computer_use` requirements-only feature key
  - include it in generated config schema output
  - cover the new key in feature metadata tests
  
  ## Testing
  - `cargo test -p codex-features`
  - `just write-config-schema`
  - `just fmt`
  - `just fix -p codex-features`
  
  cc @xl-openai
  
  ---------
  
  Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>

  Leo Shimonaka · 2026-04-22 22:49:26 -07:00
  7730fb3ab8
• TUI: preserve permission state after side conversations (#18924)

  Addresses #18854
  
  ## Why
  
  The `/permissions` selector updates the active TUI session state, but
  the cached session snapshot used when replaying a thread could still
  contain the old approval or sandbox settings. After opening and leaving
  `/side`, the main thread replay could restore those stale settings into
  the `ChatWidget`, so the UI and the next submitted turn could fall back
  to the old permission mode.
  
  ## What
  
  - Sync the active thread's cached `ThreadSessionState` whenever approval
  policy, sandbox policy, or approval reviewer changes.
  
  ## Verification
  
  Confirmed bug prior to fix and correct behavior after fix.

  Eric Traut · 2026-04-22 22:40:35 -07:00
  08b5e96678
• Mark codex_hooks stable (#19012)

  # Why
  
  Hooks are ready to graduate to GA in the next release!
  
  # What
  
  - Moves `Feature::CodexHooks` into the stable feature group.
  - Marks the `codex_hooks` feature spec as `Stage::Stable` and
  default-enabled.

  Abhinav · 2026-04-23 05:34:05 +00:00
  23afa173f4
• app-server: accept command permission profiles (#18283)

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

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

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

  Eric Traut · 2026-04-22 22:24:12 -07:00
  bbff4ee61a
• Default Fast service tier for eligible ChatGPT plans (#19053)

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

  Shijie Rao · 2026-04-22 21:54:44 -07:00
  02170996e6
• protocol: report session permission profiles (#18282)

  ## Why
  
  Clients that observe `SessionConfigured` need the same canonical
  permission view that app-server thread responses provide. Reporting the
  profile in protocol events lets clients keep their local state
  synchronized without reinterpreting legacy sandbox fields.
  
  ## What changed
  
  This adds `permission_profile` to `SessionConfigured` and propagates it
  through core, exec JSON output, MCP server messages, and TUI
  history/widget handling.
  
  ## Verification
  
  - `cargo test -p codex-tui permissions -- --nocapture`
  - `cargo test -p codex-core --test all permissions_messages --
  --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18282).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * __->__ #18282

  Michael Bolin · 2026-04-22 21:29:32 -07:00
  082fc4f632
• codex: support hooks in config.toml and requirements.toml (#18893)

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

  Andrei Eternal · 2026-04-22 21:20:09 -07:00
  2b2de3f38b
• tui: fix approvals popup disabled shortcut test (#19072)

  ## Why
  
  This regressed in #19063, which made `GuardianApproval` stable and
  enabled by default. That adds an enabled `Auto-review` row to the
  permissions popup, but `approvals_popup_navigation_skips_disabled` still
  assumed the disabled `Full Access` row lived behind a hard-coded numeric
  shortcut, so the test started selecting a different row and closing the
  popup instead of verifying disabled-row behavior.
  
  ## What
  
  - disable `GuardianApproval` in
  `approvals_popup_navigation_skips_disabled` so the popup layout matches
  the scenario the test is exercising
  - choose the hidden numeric shortcut for the disabled `Full Access` row
  by platform (`2` on non-Windows, `3` on Windows where `Read Only` is
  shown) before asserting that selecting the disabled row leaves the popup
  open
  
  ## Testing
  
  - `cargo test -p codex-tui --lib
  chatwidget::tests::permissions::approvals_popup_navigation_skips_disabled
  -- --exact --nocapture`
  - `cargo test -p codex-tui --lib chatwidget::tests::permissions --
  --nocapture`
  - `cargo test -p codex-tui`

  Michael Bolin · 2026-04-22 21:01:26 -07:00
  9955eacd22
• test: set Rust test thread stack size (#19067)

  ## Summary
  
  Set `RUST_MIN_STACK=8388608` for Rust test entry points so
  libtest-spawned test threads get an 8 MiB stack.
  
  The Windows BuildBuddy failure on #18893 showed
  `//codex-rs/tui:tui-unit-tests` exiting with a stack overflow in a
  `#[tokio::test]` even though later test binaries in the shard printed
  successful summaries. Default `#[tokio::test]` uses a current-thread
  Tokio runtime, which means the async test body is driven on libtest's
  std-spawned test thread. Increasing the test thread stack addresses that
  failure mode directly.
  
  To date, we have been fixing these stack-pressure problems with
  localized future-size reductions, such as #13429, and by adding
  `Box::pin()` in specific async wrapper chains. This gives us a baseline
  test-runner stack size instead of continuing to patch individual tests
  only after CI finds another large async future.
  
  ## What changed
  
  - Added `common --test_env=RUST_MIN_STACK=8388608` in `.bazelrc` so
  Bazel test actions receive the env var through Bazel's cache-keyed test
  environment path.
  - Set the same `RUST_MIN_STACK` value for Cargo/nextest CI entry points
  and `just test`.
  - Annotated the existing Windows Bazel linker stack reserve as 8 MiB so
  it stays aligned with the libtest thread stack size.
  
  ## Testing
  
  - `just --list`
  - parsed `.github/workflows/rust-ci.yml` and
  `.github/workflows/rust-ci-full.yml` with Ruby's YAML loader
  - compared `bazel aquery` `TestRunner` action keys before/after explicit
  `--test_env=RUST_MIN_STACK=...` and after moving the Bazel env to
  `.bazelrc`
  - `bazel test //codex-rs/tui:tui-unit-tests --test_output=errors`
  - failed locally on the existing sandbox-specific status snapshot
  permission mismatch, but loaded the Starlark changes and ran the TUI
  test shards

  Michael Bolin · 2026-04-22 19:51:49 -07:00
  e8ba912fcc