65 Commits

• Code mode on v8 (#15276)

  Moves Code Mode to a new crate with no dependencies on codex. This
  create encodes the code mode semantics that we want for lifetime,
  mounting, tool calling.
  
  The model-facing surface is mostly unchanged. `exec` still runs raw
  JavaScript, `wait` still resumes or terminates a `cell_id`, nested tools
  are still available through `tools.*`, and helpers like `text`, `image`,
  `store`, `load`, `notify`, `yield_control`, and `exit` still exist.
  
  The major change is underneath that surface:
  
  - Old code mode was an external Node runtime.
  - New code mode is an in-process V8 runtime embedded directly in Rust.
  - Old code mode managed cells inside a long-lived Node runner process.
  - New code mode manages cells in Rust, with one V8 runtime thread per
  active `exec`.
  - Old code mode used JSON protocol messages over child stdin/stdout plus
  Node worker-thread messages.
  - New code mode uses Rust channels and direct V8 callbacks/events.
  
  This PR also fixes the two migration regressions that fell out of that
  substrate change:
  
  - `wait { terminate: true }` now waits for the V8 runtime to actually
  stop before reporting termination.
  - synchronous top-level `exit()` now succeeds again instead of surfacing
  as a script error.
  
  ---
  
  - `core/src/tools/code_mode/*` is now mostly an adapter layer for the
  public `exec` / `wait` tools.
  - `code-mode/src/service.rs` owns cell sessions and async control flow
  in Rust.
  - `code-mode/src/runtime/*.rs` owns the embedded V8 isolate and
  JavaScript execution.
  - each `exec` spawns a dedicated runtime thread plus a Rust
  session-control task.
  - helper globals are installed directly into the V8 context instead of
  being injected through a source prelude.
  - helper modules like `tools.js` and `@openai/code_mode` are synthesized
  through V8 module resolution callbacks in Rust.
  
  ---
  
  Also added a benchmark for showing the speed of init and use of a code
  mode env:
  ```
  $ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
  Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
       Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
  exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
  scenario       tools samples    warmups      iters      mean/exec       p95/exec       rssΔ p50       rssΔ max
  cold_exec          0      30          0          1         1.13ms         1.20ms        8.05MiB        8.06MiB
  warm_exec          0      30          1         25       473.43us       512.49us      912.00KiB        1.33MiB
  cold_exec         32      30          0          1         1.03ms         1.15ms        8.08MiB        8.11MiB
  warm_exec         32      30          1         25       509.73us       545.76us      960.00KiB        1.30MiB
  cold_exec        128      30          0          1         1.14ms         1.19ms        8.30MiB        8.34MiB
  warm_exec        128      30          1         25       575.08us       591.03us      736.00KiB      864.00KiB
  memory uses a fresh-process max RSS delta for each scenario
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Channing Conger · 2026-03-20 23:36:58 -07:00
  e4eedd6170
• Split features into codex-features crate (#15253)

  - Split the feature system into a new `codex-features` crate.
  - Cut `codex-core` and workspace consumers over to the new config and
  warning APIs.
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 20:12:07 -07:00
  2e22885e79
• Preserve background terminals on interrupt and rename cleanup command to /stop (#14602)

  ### Motivation
  - Interrupting a running turn (Ctrl+C / Esc) currently also terminates
  long‑running background shells, which is surprising for workflows like
  local dev servers or file watchers.
  - The existing cleanup command name was confusing; callers expect an
  explicit command to stop background terminals rather than a UI clear
  action.
  - Make background‑shell termination explicit and surface a clearer
  command name while preserving backward compatibility.
  
  ### Description
  - Renamed the background‑terminal cleanup slash command from `Clean`
  (`/clean`) to `Stop` (`/stop`) and kept `clean` as an alias in the
  command parsing/visibility layer, updated the user descriptions and
  command popup wiring accordingly.
  - Updated the unified‑exec footer text and snapshots to point to `/stop`
  (and trimmed corresponding snapshot output to match the new label).
  - Changed interrupt behavior so `Op::Interrupt` (Ctrl+C / Esc interrupt)
  no longer closes or clears tracked unified exec / background terminal
  processes in the TUI or core cleanup path; background shells are now
  preserved after an interrupt.
  - Updated protocol/docs to clarify that `turn/interrupt` (or
  `Op::Interrupt`) interrupts the active turn but does not terminate
  background terminals, and that `thread/backgroundTerminals/clean` is the
  explicit API to stop those shells.
  - Updated unit/integration tests and insta snapshots in the TUI and core
  unified‑exec suites to reflect the new semantics and command name.
  
  ### Testing
  - Ran formatting with `just fmt` in `codex-rs` (succeeded). 
  - Ran `cargo test -p codex-protocol` (succeeded). 
  - Attempted `cargo test -p codex-tui` but the build could not complete
  in this environment due to a native build dependency that requires
  `libcap` development headers (the `codex-linux-sandbox` vendored build
  step); install `libcap-dev` / make `libcap.pc` available in
  `PKG_CONFIG_PATH` to run the TUI test suite locally.
  - Updated and accepted the affected `insta` snapshots for the TUI
  changes so visual diffs reflect the new `/stop` wording and preserved
  interrupt behavior.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_69b39c44b6dc8323bd133ae206310fae)

  friel-openai · 2026-03-15 22:17:25 -07:00
  ba463a9dc7
• Add Smart Approvals guardian review across core, app-server, and TUI (#13860)

  ## Summary
  - add `approvals_reviewer = "user" | "guardian_subagent"` as the runtime
  control for who reviews approval requests
  - route Smart Approvals guardian review through core for command
  execution, file changes, managed-network approvals, MCP approvals, and
  delegated/subagent approval flows
  - expose guardian review in app-server with temporary unstable
  `item/autoApprovalReview/{started,completed}` notifications carrying
  `targetItemId`, `review`, and `action`
  - update the TUI so Smart Approvals can be enabled from `/experimental`,
  aligned with the matching `/approvals` mode, and surfaced clearly while
  reviews are pending or resolved
  
  ## Runtime model
  This PR does not introduce a new `approval_policy`.
  
  Instead:
  - `approval_policy` still controls when approval is needed
  - `approvals_reviewer` controls who reviewable approval requests are
  routed to:
    - `user`
    - `guardian_subagent`
  
  `guardian_subagent` is a carefully prompted reviewer subagent that
  gathers relevant context and applies a risk-based decision framework
  before approving or denying the request.
  
  The `smart_approvals` feature flag is a rollout/UI gate. Core runtime
  behavior keys off `approvals_reviewer`.
  
  When Smart Approvals is enabled from the TUI, it also switches the
  current `/approvals` settings to the matching Smart Approvals mode so
  users immediately see guardian review in the active thread:
  - `approval_policy = on-request`
  - `approvals_reviewer = guardian_subagent`
  - `sandbox_mode = workspace-write`
  
  Users can still change `/approvals` afterward.
  
  Config-load behavior stays intentionally narrow:
  - plain `smart_approvals = true` in `config.toml` remains just the
  rollout/UI gate and does not auto-set `approvals_reviewer`
  - the deprecated `guardian_approval = true` alias migration does
  backfill `approvals_reviewer = "guardian_subagent"` in the same scope
  when that reviewer is not already configured there, so old configs
  preserve their original guardian-enabled behavior
  
  ARC remains a separate safety check. For MCP tool approvals, ARC
  escalations now flow into the configured reviewer instead of always
  bypassing guardian and forcing manual review.
  
  ## Config stability
  The runtime reviewer override is stable, but the config-backed
  app-server protocol shape is still settling.
  
  - `thread/start`, `thread/resume`, and `turn/start` keep stable
  `approvalsReviewer` overrides
  - the config-backed `approvals_reviewer` exposure returned via
  `config/read` (including profile-level config) is now marked
  `[UNSTABLE]` / experimental in the app-server protocol until we are more
  confident in that config surface
  
  ## App-server surface
  This PR intentionally keeps the guardian app-server shape narrow and
  temporary.
  
  It adds generic unstable lifecycle notifications:
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`
  
  with payloads of the form:
  - `{ threadId, turnId, targetItemId, review, action? }`
  
  `review` is currently:
  - `{ status, riskScore?, riskLevel?, rationale? }`
  - where `status` is one of `inProgress`, `approved`, `denied`, or
  `aborted`
  
  `action` carries the guardian action summary payload from core when
  available. This lets clients render temporary standalone pending-review
  UI, including parallel reviews, even when the underlying tool item has
  not been emitted yet.
  
  These notifications are explicitly documented as `[UNSTABLE]` and
  expected to change soon.
  
  This PR does **not** persist guardian review state onto `thread/read`
  tool items. The intended follow-up is to attach guardian review state to
  the reviewed tool item lifecycle instead, which would improve
  consistency with manual approvals and allow thread history / reconnect
  flows to replay guardian review state directly.
  
  ## TUI behavior
  - `/experimental` exposes the rollout gate as `Smart Approvals`
  - enabling it in the TUI enables the feature and switches the current
  session to the matching Smart Approvals `/approvals` mode
  - disabling it in the TUI clears the persisted `approvals_reviewer`
  override when appropriate and returns the session to default manual
  review when the effective reviewer changes
  - `/approvals` still exposes the reviewer choice directly
  - the TUI renders:
  - pending guardian review state in the live status footer, including
  parallel review aggregation
    - resolved approval/denial state in history
  
  ## Scope notes
  This PR includes the supporting core/runtime work needed to make Smart
  Approvals usable end-to-end:
  - shell / unified-exec / apply_patch / managed-network / MCP guardian
  review
  - delegated/subagent approval routing into guardian review
  - guardian review risk metadata and action summaries for app-server/TUI
  - config/profile/TUI handling for `smart_approvals`, `guardian_approval`
  alias migration, and `approvals_reviewer`
  - a small internal cleanup of delegated approval forwarding to dedupe
  fallback paths and simplify guardian-vs-parent approval waiting (no
  intended behavior change)
  
  Out of scope for this PR:
  - redesigning the existing manual approval protocol shapes
  - persisting guardian review state onto app-server `ThreadItem`s
  - delegated MCP elicitation auto-review (the current delegated MCP
  guardian shim only covers the legacy `RequestUserInput` path)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-13 15:27:00 -07:00
  bc24017d64
• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• add fast mode toggle (#13212)

  - add a local Fast mode setting in codex-core (similar to how model id
  is currently stored on disk locally)
  - send `service_tier=priority` on requests when Fast is enabled
  - add `/fast` in the TUI and persist it locally
  - feature flag

  pash-openai · 2026-03-02 20:29:33 -08:00
  2f5b01abd6
• Allow clients not to send summary as an option (#12950)

  Summary is a required parameter on UserTurn. Ideally we'd like the core
  to decide the appropriate summary level.
  
  Make the summary optional and don't send it when not needed.

  pakrym-oai · 2026-02-26 14:37:38 -08:00
  951a389654
• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• Revert "feat: no timeout mode on ue" (#12256)

  Reverts openai/codex#12250

  jif-oai · 2026-02-19 19:02:29 +00:00
  928be5f515
• feat: no timeout mode on ue (#12250)
  jif-oai · 2026-02-19 18:58:13 +00:00
  9719dc502c
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• feat: do not close unified exec processes across turns (#10799)

  With this PR we do not close the unified exec processes (i.e. background
  terminals) at the end of a turn unless:
  * The user interrupt the turn
  * The user decide to clean the processes through `app-server` or
  `/clean`
  
  I made sure that `codex exec` correctly kill all the processes

  jif-oai · 2026-02-09 10:27:46 +00:00
  6cf61725d0
• feat(core) update Personality on turn (#9644)

  ## Summary
  Support updating Personality mid-Thread via UserTurn/OverwriteTurn. This
  is explicitly unused by the clients so far, to simplify PRs - app-server
  and tui implementations will be follow-ups.
  
  ## Testing
  - [x] added integration tests

  Dylan Hurd · 2026-01-22 12:04:23 -08:00
  8b3521ee77
• Add collaboration_mode override to turns (#9408)
  Ahmed Ibrahim · 2026-01-16 21:51:25 -08:00
  146d54cede
• chore: close pipe on non-pty processes (#9369)

  Closing the STDIN of piped process when starting them to avoid commands
  like `rg` to wait for content on STDIN and hangs for ever

  jif-oai · 2026-01-16 15:54:32 +01:00
  1668ca726f
• Add text element metadata to types (#9235)

  Initial type tweaking PR to make the diff of
  https://github.com/openai/codex/pull/9116 smaller
  
  This should not change any behavior, just adds some fields to types

  charley-oai · 2026-01-14 16:41:50 -08:00
  4a9c2bcc5a
• feat: adding piped process to replace PTY when needed (#8797)
  jif-oai · 2026-01-14 18:44:04 +00:00
  577e1fd1b2
• chore: clamp min yield time for empty write_stdin (#9156)

  After evals, 0 impact on performance

  jif-oai · 2026-01-14 16:25:40 +00:00
  32b1795ff4
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• remove get_responses_requests and get_responses_request_bodies to use in-place matcher (#8858)
  Ahmed Ibrahim · 2026-01-08 13:57:48 -08:00
  0d3e673019
• chore: rename unified exec sessions (#8822)

  Renaming done by Codex

  jif-oai · 2026-01-07 16:12:47 +00:00
  4cef89a122
• fix: flaky test 6 (#8175)
  jif-oai · 2025-12-17 11:59:13 +00:00
  2bf57674d6
• feat: close unified_exec at end of turn (#8052)
  jif-oai · 2025-12-16 12:16:43 +00:00
  ae57e18947
• fix: flaky tests 4 (#7875)
  jif-oai · 2025-12-11 14:26:27 +00:00
  d4554ce6c8
• feat: add shell snapshot for shell command (#7786)
  jif-oai · 2025-12-11 13:46:43 +00:00
  29381ba5c2
• make model optional in config (#7769)

  - Make Config.model optional and centralize default-selection logic in
  ModelsManager, including a default_model helper (with
  codex-auto-balanced when available) so sessions now carry an explicit
  chosen model separate from the base config.
  - Resolve `model` once in `core` and `tui` from config. Then store the
  state of it on other structs.
  - Move refreshing models to be before resolving the default model

  Ahmed Ibrahim · 2025-12-10 11:19:00 -08:00
  cb9a189857
• fix: flaky test 2 (#7818)
  jif-oai · 2025-12-10 16:35:28 +00:00
  463249eff3
• chore: rework unified exec events (#7775)
  jif-oai · 2025-12-10 10:30:38 +00:00
  0ad54982ae
• Do not emit start/end events for write stdin (#7561)
  pakrym-oai · 2025-12-08 15:23:02 -08:00
  ac5fa6baf8
• Fix unified_exec on windows (#7620)

  Fix unified_exec on windows
  
  Requires removal of PSUEDOCONSOLE_INHERIT_CURSOR flag so child processed
  don't attempt to wait for cursor position response (and timeout).
  
  
  https://github.com/wezterm/wezterm/compare/main...pakrym:wezterm:PSUEDOCONSOLE_INHERIT_CURSOR?expand=1
  
  ---------
  
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  Pavel Krymets · 2025-12-05 20:09:43 +00:00
  f48d88067e
• feat: update sandbox policy to allow TTY (#7580)

  **Change**: Seatbelt now allows file-ioctl on /dev/ttys[0-9]+ even
  without the sandbox extension so pre-created PTYs remain interactive
  (Python REPL, shells).
  
  **Risk**: A seatbelted process that already holds a PTY fd (including
  one it shouldn’t) could issue tty ioctls like TIOCSTI or termios changes
  on that fd. This doesn’t allow opening new PTYs or reading/writing them;
  it only broadens ioctl capability on existing fds.
  
  **Why acceptable**: We already hand the child its PTY for interactive
  use; restoring ioctls is required for isatty() and prompts to work. The
  attack requires being given or inheriting a sensitive PTY fd; by design
  we don’t hand untrusted processes other users’ PTYs (we don't hand them
  any PTYs actually), so the practical exposure is limited to the PTY
  intentionally allocated for the session.
  
  **Validation**:
  Running
  ```
  start a python interpreter and keep it running
  ```
  Followed by:
  * `calculate 1+1 using it` -> works as expected
  * `Use this Python session to run the command just fix in
  /Users/jif/code/codex/codex-rs` -> does not work as expected

  jif-oai · 2025-12-04 17:58:58 +00:00
  2b5d0b2935
• fix(unified_exec): use platform default shell when unified_exec shell… (#7486)

  # Unified Exec Shell Selection on Windows
  
  ## Problem
  
  reference issue #7466
  
  The `unified_exec` handler currently deserializes model-provided tool
  calls into the `ExecCommandArgs` struct:
  
  ```rust
  #[derive(Debug, Deserialize)]
  struct ExecCommandArgs {
      cmd: String,
      #[serde(default)]
      workdir: Option<String>,
      #[serde(default = "default_shell")]
      shell: String,
      #[serde(default = "default_login")]
      login: bool,
      #[serde(default = "default_exec_yield_time_ms")]
      yield_time_ms: u64,
      #[serde(default)]
      max_output_tokens: Option<usize>,
      #[serde(default)]
      with_escalated_permissions: Option<bool>,
      #[serde(default)]
      justification: Option<String>,
  }
  ```
  
  The `shell` field uses a hard-coded default:
  
  ```rust
  fn default_shell() -> String {
      "/bin/bash".to_string()
  }
  ```
  
  When the model returns a tool call JSON that only contains `cmd` (which
  is the common case), Serde fills in `shell` with this default value.
  Later, `get_command` uses that value as if it were a model-provided
  shell path:
  
  ```rust
  fn get_command(args: &ExecCommandArgs) -> Vec<String> {
      let shell = get_shell_by_model_provided_path(&PathBuf::from(args.shell.clone()));
      shell.derive_exec_args(&args.cmd, args.login)
  }
  ```
  
  On Unix, this usually resolves to `/bin/bash` and works as expected.
  However, on Windows this behavior is problematic:
  
  - The hard-coded `"/bin/bash"` is not a valid Windows path.
  - `get_shell_by_model_provided_path` treats this as a model-specified
  shell, and tries to resolve it (e.g. via `which::which("bash")`), which
  may or may not exist and may not behave as intended.
  - In practice, this leads to commands being executed under a non-default
  or non-existent shell on Windows (for example, WSL bash), instead of the
  expected Windows PowerShell or `cmd.exe`.
  
  The core of the issue is that **"model did not specify `shell`" is
  currently interpreted as "the model explicitly requested `/bin/bash`"**,
  which is both Unix-specific and wrong on Windows.
  
  ## Proposed Solution
  
  Instead of hard-coding `"/bin/bash"` into `ExecCommandArgs`, we should
  distinguish between:
  
  1. **The model explicitly specifying a shell**, e.g.:
  
     ```json
     {
       "cmd": "echo hello",
       "shell": "pwsh"
     }
     ```
  
  In this case, we *do* want to respect the model’s choice and use
  `get_shell_by_model_provided_path`.
  
  2. **The model omitting the `shell` field entirely**, e.g.:
  
     ```json
     {
       "cmd": "echo hello"
     }
     ```
  
  In this case, we should *not* assume `/bin/bash`. Instead, we should use
  `default_user_shell()` and let the platform decide.
  
  To express this distinction, we can:
  
  1. Change `shell` to be optional in `ExecCommandArgs`:
  
     ```rust
     #[derive(Debug, Deserialize)]
     struct ExecCommandArgs {
         cmd: String,
         #[serde(default)]
         workdir: Option<String>,
         #[serde(default)]
         shell: Option<String>,
         #[serde(default = "default_login")]
         login: bool,
         #[serde(default = "default_exec_yield_time_ms")]
         yield_time_ms: u64,
         #[serde(default)]
         max_output_tokens: Option<usize>,
         #[serde(default)]
         with_escalated_permissions: Option<bool>,
         #[serde(default)]
         justification: Option<String>,
     }
     ```
  
  Here, the absence of `shell` in the JSON is represented as `shell:
  None`, rather than a hard-coded string value.

  Robby He · 2025-12-02 21:49:25 -08:00
  f3989f6092
• feat: intercept apply_patch for unified_exec (#7446)
  jif-oai · 2025-12-02 17:54:02 +00:00
  72b95db12f
• feat: update process ID for event handling (#7261)
  jif-oai · 2025-11-25 14:21:05 -08:00
  28ff364c3a
• fix: don't store early exit sessions (#7263)
  jif-oai · 2025-11-24 21:14:24 +00:00
  fc2ff624ac
• fix: flaky test (#7257)
  jif-oai · 2025-11-24 18:45:41 +00:00
  35d89e820f
• feat: unified exec basic pruning strategy (#7239)

  LRU + exited sessions first

  jif-oai · 2025-11-24 17:22:32 +00:00
  b2cddec3d7
• Attempt to fix unified_exec_formats_large_output_summary flakiness (#7029)

  second attempt to fix this test after
  https://github.com/openai/codex/pull/6884. I think this flakiness is
  happening because yield_time is too small for a 10,000 step loop in
  python.

  Ahmed Ibrahim · 2025-11-20 14:38:04 -08:00
  54ee302a06
• Allow unified_exec to early exit (if the process terminates before yield_time_ms) (#6867)

  Thread through an `exit_notify` tokio `Notify` through to the
  `UnifiedExecSession` so that we can return early if the command
  terminates before `yield_time_ms`.
  
  As Codex review correctly pointed out below 🙌 we also need a
  `exit_signaled` flag so that commands which finish before we start
  waiting can also exit early.
  
  Since the default `yield_time_ms` is now 10s, this means that we don't
  have to wait 10s for trivial commands like ls, sed, etc (which are the
  majority of agent commands 😅)
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  hanson-openai · 2025-11-20 13:34:41 +01:00
  b5dd189067
• fix: don't truncate at new lines (#6907)
  Ahmed Ibrahim · 2025-11-19 17:05:48 +00:00
  d62cab9a06
• Move shell to use truncate_text (#6842)

  Move shell to use the configurable `truncate_text`
  
  ---------
  
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  Ahmed Ibrahim · 2025-11-19 01:56:08 -08:00
  efebc62fb7
• flaky-unified_exec_formats_large_output_summary (#6884)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2025-11-19 00:00:37 -08:00
  0440a3f105
• Add the utility to truncate by tokens (#6746)

  - This PR is to make it on path for truncating by tokens. This path will
  be initially used by unified exec and context manager (responsible for
  MCP calls mainly).
  - We are exposing new config `calls_output_max_tokens`
  - Use `tokens` as the main budget unit but truncate based on the model
  family by Introducing `TruncationPolicy`.
  - Introduce `truncate_text` as a router for truncation based on the
  mode.
  
  In next PRs:
  - remove truncate_with_line_bytes_budget
  - Add the ability to the model to override the token budget.

  Ahmed Ibrahim · 2025-11-18 11:36:23 -08:00
  3de8790714
• Update defaults to gpt-5.1 (#6652)

  ## Summary
  - update documentation, example configs, and automation defaults to
  reference gpt-5.1 / gpt-5.1-codex
  - bump the CLI and core configuration defaults, model presets, and error
  messaging to the new models while keeping the model-family/tool coverage
  for legacy slugs
  - refresh tests, fixtures, and TUI snapshots so they expect the upgraded
  defaults
  
  ## Testing
  - `cargo test -p codex-core
  config::tests::test_precedence_fixture_with_gpt5_profile`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6916c5b3c2b08321ace04ee38604fc6b)

  Ahmed Ibrahim · 2025-11-17 17:40:11 -08:00
  ddcc60a085
• Ignore unified_exec_respects_workdir_override (#6693)
  pakrym-oai · 2025-11-14 15:00:31 -08:00
  018a2d2e50
• feat: better UI for unified_exec (#6515)

  <img width="376" height="132" alt="Screenshot 2025-11-12 at 17 36 22"
  src="https://github.com/user-attachments/assets/ce693f0d-5ca0-462e-b170-c20811dcc8d5"
  />

  jif-oai · 2025-11-14 16:31:12 +01:00
  63c8c01f40
• Revert "Revert "Overhaul shell detection and centralize command generation for unified exec"" (#6607)

  Reverts openai/codex#6606

  pakrym-oai · 2025-11-13 16:45:17 -08:00
  7b027e7536
• Revert "Overhaul shell detection and centralize command generation for unified exec" (#6606)

  Reverts openai/codex#6577

  pakrym-oai · 2025-11-13 08:43:00 -08:00
  e6995174c1
• Overhaul shell detection and centralize command generation for unified exec (#6577)

  This fixes command display for unified exec. All `cd`s and `ls`es are
  now parsed.
  
  <img width="452" height="237" alt="image"
  src="https://github.com/user-attachments/assets/ce92d81f-f74c-485a-9b34-1eaa29290ec6"
  />
  
  Deletes a ton of tests that were doing nothing from shell.rs.
  
  ---------
  
  Co-authored-by: Pavel Krymets <pavel@krymets.com>

  pakrym-oai · 2025-11-13 08:28:09 -08:00
  d28e912214
• Use codex-linux-sandbox in unified exec (#6480)

  Unified exec isn't working on Linux because we don't provide the correct
  arg0.
  
  The library we use for pty management doesn't allow setting arg0
  separately from executable. Use the same aliasing strategy we use for
  `apply_patch` for `codex-linux-sandbox`.
  
  Use `#[ctor]` hack to dispatch codex-linux-sandbox calls.
  
  
  Addresses https://github.com/openai/codex/issues/6450

  pakrym-oai · 2025-11-10 17:17:09 -08:00
  6c36318bd8