489 Commits

• Support multimodal custom tool outputs (#12948)

  ## Summary
  
  This changes `custom_tool_call_output` to use the same output payload
  shape as `function_call_output`, so freeform tools can return either
  plain text or structured content items.
  
  The main goal is to let `js_repl` return image content from nested
  `view_image` calls in its own `custom_tool_call_output`, instead of
  relying on a separate injected message.
  
  ## What changed
  
  - Changed `custom_tool_call_output.output` from `string` to
  `FunctionCallOutputPayload`
  - Updated freeform tool plumbing to preserve structured output bodies
  - Updated `js_repl` to aggregate nested tool content items and attach
  them to the outer `js_repl` result
  - Removed the old `js_repl` special case that injected `view_image`
  results as a separate pending user image message
  - Updated normalization/history/truncation paths to handle multimodal
  `custom_tool_call_output`
  - Regenerated app-server protocol schema artifacts
  
  ## Behavior
  
  Direct `view_image` calls still return a `function_call_output` with
  image content.
  
  When `view_image` is called inside `js_repl`, the outer `js_repl`
  `custom_tool_call_output` now carries:
  - an `input_text` item if the JS produced text output
  - one or more `input_image` items from nested tool results
  
  So the nested image result now stays inside the `js_repl` tool output
  instead of being injected as a separate message.
  
  ## Compatibility
  
  This is intended to be backward-compatible for resumed conversations.
  
  Older histories that stored `custom_tool_call_output.output` as a plain
  string still deserialize correctly, and older histories that used the
  previous injected-image-message flow also continue to resume.
  
  Added regression coverage for resuming a pre-change rollout containing:
  - string-valued `custom_tool_call_output`
  - legacy injected image message history
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/12948

  Curtis 'Fjord' Hawthorne · 2026-02-26 18:17:46 -08:00
  7e980d7db6
• test: move unix_escalation tests into sibling file (#12957)

  ## Why
  
  `unix_escalation.rs` had a large inline `mod tests` block that made the
  implementation harder to scan. This change moves those tests into a
  sibling file while keeping them as a child module, so they can still
  exercise private items without widening visibility.
  
  ## What Changed
  
  - replaced the inline `#[cfg(test)] mod tests` block in
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs` with a
  path-based test module declaration
  - moved the existing unit tests into
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation_tests.rs`
  - kept the extracted tests using `super::...` imports so they continue
  to access private helpers and types from `unix_escalation.rs`
  
  ## Testing
  
  - `cargo test -p codex-core unix_escalation::tests`

  Michael Bolin · 2026-02-26 23:15:28 +00:00
  4cb086d96f
• feat: include sandbox config with escalation request (#12839)

  ## Why
  
  Before this change, an escalation approval could say that a command
  should be rerun, but it could not carry the sandbox configuration that
  should still apply when the escalated command is actually spawned.
  
  That left an unsafe gap in the `zsh-fork` skill path: skill scripts
  under `scripts/` that did not declare permissions could be escalated
  without a sandbox, and scripts that did declare permissions could lose
  their bounded sandbox on rerun or cached session approval.
  
  This PR extends the escalation protocol so approvals can optionally
  carry sandbox configuration all the way through execution. That lets the
  shell runtime preserve the intended sandbox instead of silently widening
  access.
  
  We likely want a single permissions type for this codepath eventually,
  probably centered on `Permissions`. For now, the protocol needs to
  represent both the existing `PermissionProfile` form and the fuller
  `Permissions` form, so this introduces a temporary disjoint union,
  `EscalationPermissions`, to carry either one.
  
  Further, this means that today, a skill either:
  
  - does not declare any permissions, in which case it is run using the
  default sandbox for the turn
  - specifies permissions, in which case the skill is run using that exact
  sandbox, which might be more restrictive than the default sandbox for
  the turn
  
  We will likely change the skill's permissions to be additive to the
  existing permissions for the turn.
  
  ## What Changed
  
  - Added `EscalationPermissions` to `codex-protocol` so escalation
  requests can carry either a `PermissionProfile` or a full `Permissions`
  payload.
  - Added an explicit `EscalationExecution` mode to the shell escalation
  protocol so reruns distinguish between `Unsandboxed`, `TurnDefault`, and
  `Permissions(...)` instead of overloading `None`.
  - Updated `zsh-fork` shell reruns to resolve `TurnDefault` at execution
  time, which keeps ordinary `UseDefault` commands on the turn sandbox and
  preserves turn-level macOS seatbelt profile extensions.
  - Updated the `zsh-fork` skill path so a skill with no declared
  permissions inherits the conversation's effective sandbox instead of
  escalating unsandboxed.
  - Updated the `zsh-fork` skill path so a skill with declared permissions
  reruns with exactly those permissions, including when a cached session
  approval is reused.
  
  ## Testing
  
  - Added unit coverage in
  `core/src/tools/runtimes/shell/unix_escalation.rs` for the explicit
  `UseDefault` / `RequireEscalated` / `WithAdditionalPermissions`
  execution mapping.
  - Added unit coverage in
  `core/src/tools/runtimes/shell/unix_escalation.rs` for macOS seatbelt
  extension preservation in both the `TurnDefault` and
  explicit-permissions rerun paths.
  - Added integration coverage in `core/tests/suite/skill_approval.rs` for
  permissionless skills inheriting the turn sandbox and explicit skill
  permissions remaining bounded across cached approval reuse.

  Michael Bolin · 2026-02-26 12:00:18 -08:00
  7fa9d9ae35
• Log js_repl nested tool responses in rollout history (#12837)

  ## Summary
  
  - add tracing-based diagnostics for nested `codex.tool(...)` calls made
  from `js_repl`
  - emit a bounded, sanitized summary at `info!`
  - emit the exact raw serialized response object or error string seen by
  JavaScript at `trace!`
  - document how to enable these logs and where to find them, especially
  for `codex app-server`
  
  ## Why
  
  Nested `codex.tool(...)` calls inside `js_repl` are a debugging
  boundary: JavaScript sees the tool result, but that result is otherwise
  hard to inspect from outside the kernel.
  
  This change adds explicit tracing for that path using the repo’s normal
  observability pattern:
  - `info` for compact summaries
  - `trace` for exact raw payloads when deep debugging is needed
  
  ## What changed
  
  - `js_repl` now summarizes nested tool-call results across the response
  shapes it can receive:
    - message content
    - function-call outputs
    - custom tool outputs
    - MCP tool results and MCP error results
    - direct error strings
  - each nested `codex.tool(...)` completion logs:
    - `exec_id`
    - `tool_call_id`
    - `tool_name`
    - `ok`
    - a bounded summary struct describing the payload shape
  - at `trace`, the same path also logs the exact serialized response
  object or error string that JavaScript received
  - docs now include concrete logging examples for `codex app-server`
  - unit coverage was added for multimodal function output summaries and
  error summaries
  
  ## How to use it
  
  ### Summary-only logging
  
  Set:
  
  ```sh
  RUST_LOG=codex_core::tools::js_repl=info
  ```
  
  For `codex app-server`, tracing output is written to the server process
  `stderr`.
  
  Example:
  
  ```sh
  RUST_LOG=codex_core::tools::js_repl=info \
  LOG_FORMAT=json \
  codex app-server \
  2> /tmp/codex-app-server.log
  ```
  
  This emits bounded summary lines for nested `codex.tool(...)` calls.
  
  ### Full raw debugging
  
  Set:
  
  ```sh
  RUST_LOG=codex_core::tools::js_repl=trace
  ```
  
  Example:
  
  ```sh
  RUST_LOG=codex_core::tools::js_repl=trace \
  LOG_FORMAT=json \
  codex app-server \
  2> /tmp/codex-app-server.log
  ```
  
  At `trace`, you get:
  - the same `info` summary line
  - a `trace` line with the exact serialized response object seen by
  JavaScript
  - or the exact error string if the nested tool call failed
  
  ### Where the logs go
  
  For `codex app-server`, these logs go to process `stderr`, so redirect
  or capture `stderr` to inspect them.
  
  Example:
  
  ```sh
  RUST_LOG=codex_core::tools::js_repl=trace \
  LOG_FORMAT=json \
  /Users/fjord/code/codex/codex-rs/target/debug/codex app-server \
  2> /tmp/codex-app-server.log
  ```
  
  Then inspect:
  
  ```sh
  rg "js_repl nested tool call" /tmp/codex-app-server.log
  ```
  
  Without an explicit `RUST_LOG` override, these `js_repl` nested
  tool-call logs are typically not visible.

  Curtis 'Fjord' Hawthorne · 2026-02-26 10:12:28 -08:00
  eb77db2957
• feat: fork thread multi agent (#12499)
  jif-oai · 2026-02-26 18:01:53 +00:00
  d3603ae5d3
• Use model catalog default for reasoning summary fallback (#12873)

  ## Summary
  - make `Config.model_reasoning_summary` optional so unset means use
  model default
  - resolve the optional config value to a concrete summary when building
  `TurnContext`
  - add protocol support for `default_reasoning_summary` in model metadata
  
  ## Validation
  - `cargo test -p codex-core --lib client::tests -- --nocapture`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-02-26 09:31:13 -08:00
  ba41e84a50
• Disable js_repl when Node is incompatible at startup (#12824)

  ## Summary
  - validate `js_repl` Node compatibility during session startup when the
  experiment is enabled
  - if Node is missing or too old, disable `js_repl` and
  `js_repl_tools_only` for the session before tools and instructions are
  built
  - surface that startup disablement to users through the existing startup
  warning flow instead of only logging it
  - reuse the same compatibility check in js_repl kernel startup so
  startup gating and runtime behavior stay aligned
  - add a regression test that verifies the warning is emitted and that
  the first advertised tool list omits `js_repl` and `js_repl_reset` when
  Node is incompatible
  
  ## Why
  Today `js_repl` can be advertised based only on the feature flag, then
  fail later when the kernel starts. That makes the available tool list
  inaccurate at the start of a conversation, and users do not get a clear
  explanation for why the tool is unavailable.
  
  This change makes tool availability reflect real startup checks, keeps
  the advertised tool set stable for the lifetime of the session, and
  gives users a visible warning when `js_repl` is disabled.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-core --test all
  js_repl_is_not_advertised_when_startup_node_is_incompatible`

  Curtis 'Fjord' Hawthorne · 2026-02-26 01:14:51 +00:00
  40ab71a985
• feat: include available decisions in command approval requests (#12758)

  Command-approval clients currently infer which choices to show from
  side-channel fields like `networkApprovalContext`,
  `proposedExecpolicyAmendment`, and `additionalPermissions`. That makes
  the request shape harder to evolve, and it forces each client to
  replicate the server's heuristics instead of receiving the exact
  decision list for the prompt.
  
  This PR introduces a mapping between `CommandExecutionApprovalDecision`
  and `codex_protocol::protocol::ReviewDecision`:
  
  ```rust
  impl From<CoreReviewDecision> for CommandExecutionApprovalDecision {
      fn from(value: CoreReviewDecision) -> Self {
          match value {
              CoreReviewDecision::Approved => Self::Accept,
              CoreReviewDecision::ApprovedExecpolicyAmendment {
                  proposed_execpolicy_amendment,
              } => Self::AcceptWithExecpolicyAmendment {
                  execpolicy_amendment: proposed_execpolicy_amendment.into(),
              },
              CoreReviewDecision::ApprovedForSession => Self::AcceptForSession,
              CoreReviewDecision::NetworkPolicyAmendment {
                  network_policy_amendment,
              } => Self::ApplyNetworkPolicyAmendment {
                  network_policy_amendment: network_policy_amendment.into(),
              },
              CoreReviewDecision::Abort => Self::Cancel,
              CoreReviewDecision::Denied => Self::Decline,
          }
      }
  }
  ```
  
  And updates `CommandExecutionRequestApprovalParams` to have a new field:
  
  ```rust
  available_decisions: Option<Vec<CommandExecutionApprovalDecision>>
  ```
  
  when, if specified, should make it easier for clients to display an
  appropriate list of options in the UI.
  
  This makes it possible for `CoreShellActionProvider::prompt()` in
  `unix_escalation.rs` to specify the `Vec<ReviewDecision>` directly,
  adding support for `ApprovedForSession` when approving a skill script,
  which was previously missing in the TUI.
  
  Note this results in a significant change to `exec_options()` in
  `approval_overlay.rs`, as the displayed options are now derived from
  `available_decisions: &[ReviewDecision]`.
  
  ## What Changed
  
  - Add `available_decisions` to
  [`ExecApprovalRequestEvent`](https://github.com/openai/codex/blob/de00e932dd9801de0a4faac0519162099753f331/codex-rs/protocol/src/approvals.rs#L111-L175),
  including helpers to derive the legacy default choices when older
  senders omit the field.
  - Map `codex_protocol::protocol::ReviewDecision` to app-server
  `CommandExecutionApprovalDecision` and expose the ordered list as
  experimental `availableDecisions` in
  [`CommandExecutionRequestApprovalParams`](https://github.com/openai/codex/blob/de00e932dd9801de0a4faac0519162099753f331/codex-rs/app-server-protocol/src/protocol/v2.rs#L3798-L3807).
  - Thread optional `available_decisions` through the core approval path
  so Unix shell escalation can explicitly request `ApprovedForSession` for
  session-scoped approvals instead of relying on client heuristics.
  [`unix_escalation.rs`](https://github.com/openai/codex/blob/de00e932dd9801de0a4faac0519162099753f331/codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs#L194-L214)
  - Update the TUI approval overlay to build its buttons from the ordered
  decision list, while preserving the legacy fallback when
  `available_decisions` is missing.
  - Update the app-server README, test client output, and generated schema
  artifacts to document and surface the new field.
  
  ## Testing
  
  - Add `approval_overlay.rs` coverage for explicit decision lists,
  including the generic `ApprovedForSession` path and network approval
  options.
  - Update `chatwidget/tests.rs` and app-server protocol tests to populate
  the new optional field and keep older event shapes working.
  
  ## Developers Docs
  
  - If we document `item/commandExecution/requestApproval` on
  [developers.openai.com/codex](https://developers.openai.com/codex), add
  experimental `availableDecisions` as the preferred source of approval
  choices and note that older servers may omit it.

  Michael Bolin · 2026-02-26 01:10:46 +00:00
  14116ade8d
• feat: scope execve session approvals by approved skill metadata (#12814)

  Previous to this change, `determine_action()` would
  
  1. check if `program` is associated with a skill
  2. if so, check if `program` is in `execve_session_approvals` to see
  whether the user needs to be prompted
  
  This PR flips the order of these checks to try to set us up so that
  "session approvals" are always consulted first (which should soon extend
  to include session approvals derived from `prefix_rule()`s, as well).
  
  Though to make the new ordering work, we need to record any relevant
  metadata to associate with the approval, which in the case of a
  skill-based approval is the `SkillMetadata` so that we can derive the
  `PermissionProfile` to include with the escalation. (Though as noted by
  the `TODO`, this `PermissionProfile` is not honored yet.)
  
  The new `ExecveSessionApproval` struct is used to retain the necessary
  metadata.
  
  ## What Changed
  
  - Replace the `execve_session_approvals` `HashSet` with a map that
  stores an `ExecveSessionApproval` alongside each approved `program`.
  - When a user chooses `ApprovedForSession` for a skill script, capture
  the matched `SkillMetadata` in the session approval entry.
  - Consult that cache before re-running `find_skill()`, and reuse the
  originally approved skill metadata and permission profile when allowing
  later execve callbacks in the same session.

  Michael Bolin · 2026-02-25 15:30:24 -08:00
  a6a5976c5a
• Enable request_user_input in Default mode (#12735)

  ## Summary
  - allow `request_user_input` in Default collaboration mode as well as
  Plan
  - update the Default-mode instructions to prefer assumptions first and
  use `request_user_input` only when a question is unavoidable
  - update request_user_input and app-server tests to match the new
  Default-mode behavior
  - refactor collaboration-mode availability plumbing into
  `CollaborationModesConfig` for future mode-related flags
  
  ## Codex author
  `codex resume 019c9124-ed28-7c13-96c6-b916b1c97d49`

  Charley Cunningham · 2026-02-25 15:20:46 -08:00
  2f4d6ded1d
• Revert "Ensure shell command skills trigger approval (#12697)" (#12721)

  This reverts commit daf0f03ac8.
  
  # 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.

  Celia Chen · 2026-02-25 22:49:53 +00:00
  b6d20748e0
• feat(app-server): add ThreadItem::DynamicToolCall (#12732)

  Previously, clients would call `thread/start` with dynamic_tools set,
  and when a model invokes a dynamic tool, it would just make the
  server->client `item/tool/call` request and wait for the client's
  response to complete the tool call. This works, but it doesn't have an
  `item/started` or `item/completed` event.
  
  Now we are doing this:
  - [new] emit `item/started` with `DynamicToolCall` populated with the
  call arguments
  - send an `item/tool/call` server request
  - [new] once the client responds, emit `item/completed` with
  `DynamicToolCall` populated with the response.
  
  Also, with `persistExtendedHistory: true`, dynamic tool calls are now
  reconstructable in `thread/read` and `thread/resume` as
  `ThreadItem::DynamicToolCall`.

  Owen Lin · 2026-02-25 12:00:10 -08:00
  a0fd94bde6
• fix: enforce sandbox envelope for zsh fork execution (#12800)

  ## Why
  Zsh fork execution was still able to bypass the `WorkspaceWrite` model
  in edge cases because the fork path reconstructed command execution
  without preserving sandbox wrappers, and command extraction only
  accepted shell invocations in a narrow positional shape. This can allow
  commands to run with broader filesystem access than expected, which
  breaks the sandbox safety model.
  
  ## What changed
  - Preserved the sandboxed `ExecRequest` produced by
  `attempt.env_for(...)` when entering the zsh fork path in
  [`unix_escalation.rs`](https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs).
  - Updated `CoreShellCommandExecutor` to execute the sandboxed command
  and working directory captured from `attempt.env_for(...)`, instead of
  re-running a freshly reconstructed shell command.
  - Made zsh-fork script extraction robust to wrapped invocations by
  scanning command arguments for `-c`/`-lc` rather than only matching the
  first positional form.
  - Added unit tests in `unix_escalation.rs` to lock in wrapper-tolerant
  parsing behavior and keep unsupported shell forms rejected.
  - Tightened the regression in
  [`skill_approval.rs`](https://github.com/openai/codex/blob/main/codex-rs/core/tests/suite/skill_approval.rs):
  - `shell_zsh_fork_still_enforces_workspace_write_sandbox` now uses an
  explicit `WorkspaceWrite` policy with `exclude_tmpdir_env_var: true` and
  `exclude_slash_tmp: true`.
  - The test attempts to write to `/tmp/...`, which is only reliably
  outside writable roots with those explicit exclusions set.
  
  ## Verification
  - Added and passed the new unit tests around `extract_shell_script`
  parsing behavior with wrapped command shapes.
    - `extract_shell_script_supports_wrapped_command_prefixes`
    - `extract_shell_script_rejects_unsupported_shell_invocation`
  - Verified the regression with the focused integration test:
  `shell_zsh_fork_still_enforces_workspace_write_sandbox`.
  
  ## Manual Testing
  
  Prior to this change, if I ran Codex via:
  
  ```
  just codex --config zsh_path=/Users/mbolin/code/codex2/codex-rs/app-server/tests/suite/zsh --enable shell_zsh_fork
  ```
  
  and asked:
  
  ```
  what is the output of /bin/ps
  ```
  
  it would run it, even though the default sandbox should prevent the
  agent from running `/bin/ps` because it is setuid on MacOS.
  
  But with this change, I now see the expected failure because it is
  blocked by the sandbox:
  
  ```
  /bin/ps exited with status 1 and produced no output in this environment.
  ```

  Michael Bolin · 2026-02-25 11:05:27 -08:00
  648a420cbf
• chore: unify max depth parameter (#12770)

  Users were confused

  jif-oai · 2026-02-25 15:20:24 +00:00
  01f25a7b96
• Display pending child-thread approvals in TUI (#12767)

  Summary
  - propagate approval policy from parent to spawned agents and drop the
  Never override so sub-agents respect the caller’s request
  - refresh the pending-approval list whenever events arrive or the active
  thread changes and surface the list above the composer for inactive
  threads
  - add widgets, helpers, and tests covering the new pending-thread
  approval UI state
  
  ![Uploading Screenshot 2026-02-25 at 11.02.18.png…]()

  jif-oai · 2026-02-25 11:40:11 +00:00
  bcd6e68054
• feat: record whether a skill script is approved for the session (#12756)

  ## Why
  
  `unix_escalation.rs` checks a session-scoped approval cache before
  prompting again for an execve-intercepted skill script. Without also
  recording `ReviewDecision::ApprovedForSession`, that cache never gets
  populated, so the same skill script can still trigger repeated approval
  prompts within one session.
  
  ## What Changed
  
  - Add `execve_session_approvals` to `SessionServices` so the session can
  track approved skill script paths.
  - Record the script path when a skill-script prompt returns
  `ReviewDecision::ApprovedForSession`, but only for the skill-script path
  rather than broader prefix-rule approvals.
  - Reuse the cached approval on later execve callbacks by treating an
  already-approved skill script as `Decision::Allow`.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/12756).
  * #12758
  * __->__ #12756

  Michael Bolin · 2026-02-25 10:17:22 +00:00
  93efcfd50d
• Surface skill permission profiles in zsh-fork exec approvals (#12753)

  ## Summary
  
  - Preserve each skill’s raw permissions block as a permission_profile on
  SkillMetadata during skill loading.
  - Keep compiling that same metadata into the existing runtime
  Permissions object, so current enforcement
      behavior stays intact.
  - When zsh-fork intercepts execution of a script that belongs to a
  skill, include the skill’s
      permission_profile in the exec approval request.
  - This lets approval UIs show the extra filesystem access the skill
  declared when prompting for approval.

  Celia Chen · 2026-02-25 01:23:10 -08:00
  6a3233da64
• fix: keep shell escalation exec paths absolute (#12750)

  ## Why
  
  In the `shell_zsh_fork` flow, `codex-shell-escalation` receives the
  executable path exactly as the shell passed it to `execve()`. That path
  is not guaranteed to be absolute.
  
  For commands such as `./scripts/hello-mbolin.sh`, if the shell was
  launched with a different `workdir`, resolving the intercepted `file`
  against the server process working directory makes policy checks and
  skill matching inspect the wrong executable. This change pushes that fix
  a step further by keeping the normalized path typed as `AbsolutePathBuf`
  throughout the rest of the escalation pipeline.
  
  That makes the absolute-path invariant explicit, so later code cannot
  accidentally treat the resolved executable path as an arbitrary
  `PathBuf`.
  
  ## What Changed
  
  - record the wrapper process working directory as an `AbsolutePathBuf`
  - update the escalation protocol so `workdir` is explicitly absolute
  while `file` remains the raw intercepted exec path
  - resolve a relative intercepted `file` against the request `workdir` as
  soon as the server receives the request
  - thread `AbsolutePathBuf` through `EscalationPolicy`,
  `CoreShellActionProvider`, and command normalization helpers so the
  resolved executable path stays type-checked as absolute
  - replace the `path-absolutize` dependency in `codex-shell-escalation`
  with `codex-utils-absolute-path`
  - add a regression test that covers a relative `file` with a distinct
  `workdir`
  
  ## Verification
  
  - `cargo test -p codex-shell-escalation`

  Michael Bolin · 2026-02-24 23:52:36 -08:00
  c4ec6be4ab
• feat: zsh-fork forces scripts/**/* for skills to trigger a prompt (#12730)

  Direct skill-script matches force `Decision::Prompt`, so skill-backed
  scripts require explicit approval before they run. (Note "allow for
  session" is not supported in this PR, but will be done in a follow-up.)
  
  In the process of implementing this, I fixed an important bug:
  `ShellZshFork` is supposed to keep ordinary allowed execs on the
  client-side `Run` path so later `execve()` calls are still intercepted
  and reviewed. After the shell-escalation port, `Decision::Allow` still
  mapped to `Escalate`, which moved `zsh` to server-side execution too
  early. That broke the intended flow for skill-backed scripts and made
  the approval prompt depend on the wrong execution path.
  
  ## What changed
  - In `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs`,
  `Decision::Allow` now returns `Run` unless escalation is actually
  required.
  - Removed the zsh-specific `argv[0]` fallback. With the `Allow -> Run`
  fix in place, zsh's later `execve()` of the script is intercepted
  normally, so the skill match happens on the script path itself.
  - Kept the skill-path handling in `determine_action()` focused on the
  direct `program` match path.
  
  ## Verification
  - Updated `shell_zsh_fork_prompts_for_skill_script_execution` in
  `codex-rs/core/tests/suite/skill_approval.rs` (gated behind `cfg(unix)`)
  to:
  - run under `SandboxPolicy::new_workspace_write_policy()` instead of
  `DangerFullAccess`
    - assert the approval command contains only the script path
  - assert the approved run returns both stdout and stderr markers in the
  shell output
  - Ran `cargo test -p codex-core
  shell_zsh_fork_prompts_for_skill_script_execution -- --nocapture`
  
  ## Manual Testing
  
  Run the dev build:
  
  ```
  just codex --config zsh_path=/Users/mbolin/code/codex2/codex-rs/app-server/tests/suite/zsh --enable shell_zsh_fork
  ```
  
  I have created `/Users/mbolin/.agents/skills/mbolin-test-skill` with:
  
  ```
  ├── scripts
  │   └── hello-mbolin.sh
  └── SKILL.md
  ```
  
  The skill:
  
  ```
  ---
  name: mbolin-test-skill
  description: Used to exercise various features of skills.
  ---
  
  When this skill is invoked, run the `hello-mbolin.sh` script and report the output.
  ```
  
  The script:
  
  ```
  set -e
  
  # Note this script will fail if run with network disabled.
  curl --location openai.com
  ```
  
  Use `$mbolin-test-skill` to invoke the skill manually and verify that I
  get prompted to run `hello-mbolin.sh`.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/12730).
  * #12750
  * __->__ #12730

  Michael Bolin · 2026-02-24 23:51:26 -08:00
  59398125f6
• tests(js_repl): remove node-related skip paths from js_repl tests (#12185)

  ## Summary
  Remove js_repl/node test-skip paths and make Node setup explicit in CI
  so js_repl tests always run instead of silently skipping.
  
  ## Why
  We had multiple “expediency” skip paths that let js_repl tests pass
  without actually exercising Node-backed behavior. This reduced CI signal
  and hid runtime/environment regressions.
  
  ## What changed
  
  ### CI
  - Added Node setup using `codex-rs/node-version.txt` in:
    - `.github/workflows/rust-ci.yml`
    - `.github/workflows/bazel.yml`
  - Added a Unix PATH copy step in Bazel workflow to expose the setup-node
  binary in common paths.
  
  ### js_repl test harness
  - Added explicit js_repl sandbox test configuration helpers in:
    - `codex-rs/core/src/tools/js_repl/mod.rs`
    - `codex-rs/core/src/tools/handlers/js_repl.rs`
  - Added Linux arg0 dispatch glue for js_repl tests so sandbox subprocess
  entrypoint behavior is correct under Linux test execution.
  
  ### Removed skip behavior
  - Deleted runtime guard function and early-return skips in js_repl tests
  (`can_run_js_repl_runtime_tests` and related per-test short-circuits).
  - Removed view_image integration test skip behavior:
    - dropped `skip_if_no_network!(Ok(()))`
  - removed “skip on Node missing/too old” branch after js_repl output
  inspection.
  
  ## Impact
  - js_repl/node tests now consistently execute and fail loudly when the
  environment is not correctly provisioned.
  - CI has stronger signal for js_repl regressions instead of false green
  from conditional skips.
  
  ## Testing
  - `cargo test -p codex-core` (locally) to validate js_repl
  unit/integration behavior with skips removed.
  - CI expected to surface any remaining environment/runtime gaps directly
  (rather than masking them).
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - ✅ `1` https://github.com/openai/codex/pull/12300
  - ✅ `2` https://github.com/openai/codex/pull/12275
  - ✅ `3` https://github.com/openai/codex/pull/12205
  - ✅ `4` https://github.com/openai/codex/pull/12407
  - ✅ `5` https://github.com/openai/codex/pull/12372
  - 👉 `6` https://github.com/openai/codex/pull/12185
  - ⏳ `7` https://github.com/openai/codex/pull/10673

  Curtis 'Fjord' Hawthorne · 2026-02-24 22:52:14 -08:00
  9501669a24
• tests(js_repl): stabilize CI runtime test execution (#12407)

  ## Summary
  
  Stabilize `js_repl` runtime test setup in CI and move tool-facing
  `js_repl` behavior coverage into integration tests.
  
  This is a test/CI change only. No production `js_repl` behavior change
  is intended.
  
  ## Why
  
  - Bazel test sandboxes (especially on macOS) could resolve a different
  `node` than the one installed by `actions/setup-node`, which caused
  `js_repl` runtime/version failures.
  - `js_repl` runtime tests depend on platform-specific
  sandbox/test-harness behavior, so they need explicit gating in a
  base-stability commit.
  - Several tests in the `js_repl` unit test module were actually
  black-box/tool-level behavior tests and fit better in the integration
  suite.
  
  ## Changes
  
  - Add `actions/setup-node` to the Bazel and Rust `Tests` workflows,
  using the exact version pinned in the repo’s Node version file.
  - In Bazel (non-Windows), pass `CODEX_JS_REPL_NODE_PATH=$(which node)`
  into test env so `js_repl` uses the `actions/setup-node` runtime inside
  Bazel tests.
  - Add a new integration test suite for `js_repl` tool behavior and
  register it in the core integration test suite module.
  - Move black-box `js_repl` behavior tests into the integration suite
  (persistence/TLA, builtin tool invocation, recursive self-call
  rejection, `process` isolation, blocked builtin imports).
  - Keep white-box manager/kernel tests in the `js_repl` unit test module.
  - Gate `js_repl` runtime tests to run only on macOS and only when a
  usable Node runtime is available (skip on other platforms / missing Node
  in this commit).
  
  ## Impact
  
  - Reduces `js_repl` CI failures caused by Node resolution drift in
  Bazel.
  - Improves test organization by separating tool-facing behavior tests
  from white-box manager/kernel tests.
  - Keeps the base commit stable while expanding `js_repl` runtime
  coverage.
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - ✅ `1` https://github.com/openai/codex/pull/12372
  - 👉 `2` https://github.com/openai/codex/pull/12407
  - ⏳ `3` https://github.com/openai/codex/pull/12185
  - ⏳ `4` https://github.com/openai/codex/pull/10673

  Curtis 'Fjord' Hawthorne · 2026-02-24 21:04:34 -08:00
  8f3f2c3c02
• chore: migrate additional permissions to PermissionProfile (#12731)

  This PR replaces the old `additional_permissions.fs_read/fs_write` shape
  with a shared `PermissionProfile`
  model and wires it through the command approval, sandboxing, protocol,
  and TUI layers. The schema is adopted from the
  `SkillManifestPermissions`, which is also refactored to use this unified
  struct. This helps us easily expose permission profiles in app
  server/core as a follow-up.

  Celia Chen · 2026-02-25 03:35:28 +00:00
  16ca527c80
• Fix js_repl view_image attachments in nested tool calls (#12725)

  ## Summary
  
  - Fix `js_repl` so `await codex.tool("view_image", { path })` actually
  attaches the image to the active turn when called from inside the JS
  REPL.
  - Restore the behavior expected by the existing `js_repl`
  image-attachment test.
  - This is a follow-up to
  [#12553](https://github.com/openai/codex/pull/12553), which changed
  `view_image` to return structured image content.
  
  ## Root Cause
  
  - [#12553](https://github.com/openai/codex/pull/12553) changed
  `view_image` from directly injecting a pending user image message to
  returning structured `function_call_output` content items.
  - The nested tool-call bridge inside `js_repl` serialized that tool
  response back to the JS runtime, but it did not mirror returned image
  content into the active turn.
  - As a result, `view_image` appeared to succeed inside `js_repl`, but no
  `input_image` was actually attached for the outer turn.
  
  ## What Changed
  
  - Updated the nested tool-call path in `js_repl` to inspect function
  tool responses for structured content items.
  - When a nested tool response includes `input_image` content, `js_repl`
  now injects a corresponding user `Message` into the active turn before
  returning the raw tool result back to the JS runtime.
  - Kept the normal JSON result flow intact, so `codex.tool(...)` still
  returns the original tool output object to JavaScript.
  
  ## Why
  
  - `js_repl` documentation and tests already assume that `view_image` can
  be used from inside the REPL to attach generated images to the model.
  - Without this fix, the nested call path silently dropped that
  attachment behavior.

  Curtis 'Fjord' Hawthorne · 2026-02-24 18:23:53 -08:00
  125fbec317
• feat: pass helper executable paths via Arg0DispatchPaths (#12719)

  ## Why
  
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs` previously
  located `codex-execve-wrapper` by scanning `PATH` and sibling
  directories. That lookup is brittle and can select the wrong binary when
  the runtime environment differs from startup assumptions.
  
  We already pass `codex-linux-sandbox` from `codex-arg0`;
  `codex-execve-wrapper` should use the same startup-driven path plumbing.
  
  ## What changed
  
  - Introduced `Arg0DispatchPaths` in `codex-arg0` to carry both helper
  executable paths:
    - `codex_linux_sandbox_exe`
    - `main_execve_wrapper_exe`
  - Updated `arg0_dispatch_or_else()` to pass `Arg0DispatchPaths` to
  top-level binaries and preserve helper paths created in
  `prepend_path_entry_for_codex_aliases()`.
  - Threaded `Arg0DispatchPaths` through entrypoints in `cli`, `exec`,
  `tui`, `app-server`, and `mcp-server`.
  - Added `main_execve_wrapper_exe` to core configuration plumbing
  (`Config`, `ConfigOverrides`, and `SessionServices`).
  - Updated zsh-fork shell escalation to consume the configured
  `main_execve_wrapper_exe` and removed path-sniffing fallback logic.
  - Updated app-server config reload paths so reloaded configs keep the
  same startup-provided helper executable paths.
  
  ## References
  
  - [`Arg0DispatchPaths`
  definition](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/arg0/src/lib.rs#L20-L24)
  - [`arg0_dispatch_or_else()` forwarding both
  paths](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/arg0/src/lib.rs#L145-L176)
  - [zsh-fork escalation using configured wrapper
  path](https://github.com/openai/codex/blob/e355b43d5c2a771f045296a6deae10d7c9c36ec6/codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs#L109-L150)
  
  ## Testing
  
  - `cargo check -p codex-arg0 -p codex-core -p codex-exec -p codex-tui -p
  codex-mcp-server -p codex-app-server`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core tools::runtimes::shell::unix_escalation:: --
  --nocapture`

  Michael Bolin · 2026-02-24 17:44:38 -08:00
  e88f74d140
• fix(js_repl): surface uncaught kernel errors and reset cleanly (#12636)

  ## Summary
  
  Improve `js_repl` behavior when the Node kernel hits a process-level
  failure (for example, an uncaught exception or unhandled Promise
  rejection).
  
  Instead of only surfacing a generic `js_repl kernel exited unexpectedly`
  after stdout EOF, `js_repl` now returns a clearer exec error for the
  active request, then resets the kernel cleanly.
  
  ## Why
  
  Some sandbox-denied operations can trigger Node errors that become
  process-level failures (for example, an unhandled EventEmitter `'error'`
  event). In that case:
  
  - the kernel process exits,
  - the host sees stdout EOF,
  - the user gets a generic kernel-exit error,
  - and the next request can briefly race with stale kernel state.
  
  This change improves that failure mode without monkeypatching Node APIs.
  
  ## Changes
  
  ### Kernel-side (`js_repl` Node process)
  - Add process-level handlers for:
    - `uncaughtException`
    - `unhandledRejection`
  - When one of these fires:
    - best-effort emit a normal `exec_result` error for the active exec
  - include actionable guidance to catch/handle async errors (including
  Promise rejections and EventEmitter `'error'` events)
    - exit intentionally so the host can reset/restart the kernel
  
  ### Host-side (`JsReplManager`)
  - Clear dead kernel state as soon as the stdout reader observes
  unexpected kernel exit/EOF.
  - This lets the next `js_repl` exec start a fresh kernel instead of
  hitting a stale broken-pipe path.
  
  ### Tests
  - Add regression coverage for:
  - uncaught async exception -> exec error + kernel recovery on next exec
  - Update forced-kernel-exit test to validate recovery behavior (next
  exec restarts cleanly)
  
  ## Impact
  
  - Better user-facing error for kernel crashes caused by
  uncaught/unhandled async failures.
  - Cleaner recovery behavior after kernel exit.
  
  ## Validation
  
  - `cargo test -p codex-core --lib
  tools::js_repl::tests::js_repl_uncaught_exception_returns_exec_error_and_recovers
  -- --exact`
  - `cargo test -p codex-core --lib
  tools::js_repl::tests::js_repl_forced_kernel_exit_recovers_on_next_exec
  -- --exact`
  - `just fmt`

  Curtis 'Fjord' Hawthorne · 2026-02-24 17:12:02 -08:00
  63c2ac96cd
• fix: make EscalateServer public and remove shell escalation wrappers (#12724)

  ## Why
  
  `codex-shell-escalation` exposed a `codex-core`-specific adapter layer
  (`ShellActionProvider`, `ShellPolicyFactory`, and `run_escalate_server`)
  that existed only to bridge `codex-core` to `EscalateServer`. That
  indirection increased API surface and obscured crate ownership without
  adding behavior.
  
  This change moves orchestration into `codex-core` so boundaries are
  clearer: `codex-shell-escalation` provides reusable escalation
  primitives, and `codex-core` provides shell-tool policy decisions.
  
  Admittedly, @pakrym rightfully requested this sort of cleanup as part of
  https://github.com/openai/codex/pull/12649, though this avoids moving
  all of `codex-shell-escalation` into `codex-core`.
  
  ## What changed
  
  - Made `EscalateServer` public and exported it from `shell-escalation`.
  - Removed the adapter layer from `shell-escalation`:
    - deleted `shell-escalation/src/unix/core_shell_escalation.rs`
  - removed exports for `ShellActionProvider`, `ShellPolicyFactory`,
  `EscalationPolicyFactory`, and `run_escalate_server`
  - Updated `core/src/tools/runtimes/shell/unix_escalation.rs` to:
    - create `Stopwatch`/cancellation in `codex-core`
    - instantiate `EscalateServer` directly
    - implement `EscalationPolicy` directly on `CoreShellActionProvider`
  
  Net effect: same escalation flow with fewer wrappers and a smaller
  public API.
  
  ## Verification
  
  - Manually reviewed the old vs. new escalation call flow to confirm
  timeout/cancellation behavior and approval policy decisions are
  preserved while removing wrapper types.

  Michael Bolin · 2026-02-24 16:20:08 -08:00
  3d356723c4
• Agent jobs (spawn_agents_on_csv) + progress UI (#10935)

  ## Summary
  - Add agent job support: spawn a batch of sub-agents from CSV, auto-run,
  auto-export, and store results in SQLite.
  - Simplify workflow: remove run/resume/get-status/export tools; spawn is
  deterministic and completes in one call.
  - Improve exec UX: stable, single-line progress bar with ETA; suppress
  sub-agent chatter in exec.
  
  ## Why
  Enables map-reduce style workflows over arbitrarily large repos using
  the existing Codex orchestrator. This addresses review feedback about
  overly complex job controls and non-deterministic monitoring.
  
  ## Demo (progress bar)
  ```
  ./codex-rs/target/debug/codex exec \
    --enable collab \
    --enable sqlite \
    --full-auto \
    --progress-cursor \
    -c agents.max_threads=16 \
    -C /Users/daveaitel/code/codex \
    - <<'PROMPT'
  Create /tmp/agent_job_progress_demo.csv with columns: path,area and 30 rows:
  path = item-01..item-30, area = test.
  
  Then call spawn_agents_on_csv with:
  - csv_path: /tmp/agent_job_progress_demo.csv
  - instruction: "Run `python - <<'PY'` to sleep a random 0.3–1.2s, then output JSON with keys: path, score (int). Set score = 1."
  - output_csv_path: /tmp/agent_job_progress_demo_out.csv
  PROMPT
  ```
  
  ## Review feedback addressed
  - Auto-start jobs on spawn; removed run/resume/status/export tools.
  - Auto-export on success.
  - More descriptive tool spec + clearer prompts.
  - Avoid deadlocks on spawn failure; pending/running handled safely.
  - Progress bar no longer scrolls; stable single-line redraw.
  
  ## Tests
  - `cd codex-rs && cargo test -p codex-exec`
  - `cd codex-rs && cargo build -p codex-cli`

  daveaitel-openai · 2026-02-24 21:00:19 +00:00
  dcab40123f
• Ensure shell command skills trigger approval (#12697)

  Summary
  - detect skill-invoking shell commands based on the original command
  string, request approvals when needed, and cache positive decisions per
  session
  - keep implicit skill invocation emitted after approval and keep skill
  approval decline messaging centralized to the shell handler
  - expand and adjust skill approval tests to cover shell-based skill
  scripts while matching the new detection expectations
  
  Testing
  - Not run (not requested)

  pakrym-oai · 2026-02-24 12:13:20 -08:00
  daf0f03ac8
• feat: run zsh fork shell tool via shell-escalation (#12649)

  ## Why
  
  This PR switches the `shell_command` zsh-fork path over to
  `codex-shell-escalation` so the new shell tool can use the shared
  exec-wrapper/escalation protocol instead of the `zsh_exec_bridge`
  implementation that was introduced in
  https://github.com/openai/codex/pull/12052. `zsh_exec_bridge` relied on
  UNIX domain sockets, which is not as tamper-proof as the FD-based
  approach in `codex-shell-escalation`.
  
  ## What Changed
  
  - Added a Unix zsh-fork runtime adapter in `core`
  (`core/src/tools/runtimes/shell/unix_escalation.rs`) that:
  - runs zsh-fork commands through
  `codex_shell_escalation::run_escalate_server`
    - bridges exec-policy / approval decisions into `ShellActionProvider`
  - executes escalated commands via a `ShellCommandExecutor` that calls
  `process_exec_tool_call`
  - Updated `ShellRuntime` / `ShellCommandHandler` / tool spec wiring to
  select a `shell_command` backend (`classic` vs `zsh-fork`) while leaving
  the generic `shell` tool path unchanged.
  - Removed the `zsh_exec_bridge`-based session service and deleted
  `core/src/zsh_exec_bridge/mod.rs`.
  - Moved exec-wrapper entrypoint dispatch to `arg0` by handling the
  `codex-execve-wrapper` arg0 alias there, and removed the old
  `codex_core::maybe_run_zsh_exec_wrapper_mode()` hooks from `cli` and
  `app-server` mains.
  - Added the needed `codex-shell-escalation` dependencies for `core` and
  `arg0`.
  
  ## Tests
  
  - `cargo test -p codex-core
  shell_zsh_fork_prefers_shell_command_over_unified_exec`
  - `cargo test -p codex-app-server turn_start_shell_zsh_fork --
  --nocapture`
  - verifies zsh-fork command execution and approval flows through the new
  backend
  - includes subcommand approve/decline coverage using the shared zsh
  DotSlash fixture in `app-server/tests/suite/zsh`
  - To test manually, I added the following to `~/.codex/config.toml`:
  
  ```toml
  zsh_path = "/Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh"
  
  [features]
  shell_zsh_fork = true
  ```
  
  Then I ran `just c` to run the dev build of Codex with these changes and
  sent it the message:
  
  ```
  run `echo $0`
  ```
  
  And it replied with:
  
  ```
    echo $0 printed:
  
    /Users/mbolin/code/codex3/codex-rs/app-server/tests/suite/zsh
  
    In this tool context, $0 reflects the script path used to invoke the shell, not just zsh.
  ```
  
  so the tool appears to be wired up correctly.
  
  ## Notes
  
  - The zsh subcommand-decline integration test now uses `rm` under a
  `WorkspaceWrite` sandbox. The previous `/usr/bin/true` scenario is
  auto-allowed by the new `shell-escalation` policy path, which no longer
  produces subcommand approval prompts.

  Michael Bolin · 2026-02-24 10:31:08 -08:00
  3ca0e7673b
• feat(core) Introduce Feature::RequestPermissions (#11871)

  ## Summary
  Introduces the initial implementation of Feature::RequestPermissions.
  RequestPermissions allows the model to request that a command be run
  inside the sandbox, with additional permissions, like writing to a
  specific folder. Eventually this will include other rules as well, and
  the ability to persist these permissions, but this PR is already quite
  large - let's get the core flow working and go from there!
  
  <img width="1279" height="541" alt="Screenshot 2026-02-15 at 2 26 22 PM"
  src="https://github.com/user-attachments/assets/0ee3ec0f-02ec-4509-91a2-809ac80be368"
  />
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally
  - [x] Feature

  Dylan Hurd · 2026-02-24 09:48:57 -08:00
  f6053fdfb3
• feat: mutli agents persist config overrides (#12667)

  Fix propagation of runtime config changes and `--yolo`

  jif-oai · 2026-02-24 11:33:00 +00:00
  8758db5d5b
• Support implicit skill invocation analytics events (#12049)

  - use `skills_for_cwd` lookup to scope allowed skills and build
  invocation context for downstream processing
  - add detection in `stream_events_utils` to classify tool calls as
  implicit skill invocations per the proposal (script runners, extensions,
  `scripts` dirs, and SKILL.md reads)
  - deduplicate invocations per turn and emit analytics/OTEL events on the
  same background queue as explicit invokes

  alexsong-oai · 2026-02-23 21:55:49 -08:00
  09a82f364f
• feat(core): persist network approvals in execpolicy (#12357)

  ## Summary
  Persist network approval allow/deny decisions as `network_rule(...)`
  entries in execpolicy (not proxy config)
  
  It adds `network_rule` parsing + append support in `codex-execpolicy`,
  including `decision="prompt"` (parse-only; not compiled into proxy
  allow/deny lists)
  - compile execpolicy network rules into proxy allow/deny lists and
  update the live proxy state on approval
  - preserve requirements execpolicy `network_rule(...)` entries when
  merging with file-based execpolicy
  - reject broad wildcard hosts (for example `*`) for persisted
  `network_rule(...)`

  viyatb-oai · 2026-02-23 21:37:46 -08:00
  c3048ff90a
• Use Arc-based ToolCtx in tool runtimes (#12583)

  ## Why
  Tool handlers and runtimes needed to pass the same turn/session context
  for shell and non-shell workflows without duplicative ownership churn.
  Using shared pointers avoids temporary lifetimes and keeps existing
  behavior unchanged while simplifying call sites.
  
  ## What changed
  - Converted `ToolCtx` to store shared context handles (`Arc`-based),
  including updates across shell, apply-patch, and unified-exec paths.
  - Updated orchestrator/runtime call sites to consume the shared context
  consistently and remove brittle move/borrow patterns.
  - Kept behavior unchanged while preparing the type surface for the new
  shell escalation integration in the next stack commit.
  
  ## Verification
  - Validated this commit stack point with `just clippy` and confirmed
  workspace compiles cleanly in this stack state.
  
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/12583).
  * #12584
  * __->__ #12583
  * #12556

  Michael Bolin · 2026-02-23 18:29:26 +00:00
  7f75e74201
• remove feature flag collaboration modes (#12028)

  All code should go in the direction that steer is enabled
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-02-23 09:06:08 -08:00
  6e60f724bc
• feat: role metrics multi-agent (#12579)

  add metrics for agent role

  jif-oai · 2026-02-23 15:55:48 +00:00
  2119532a81
• feat: agent nick names to model (#12575)
  jif-oai · 2026-02-23 13:44:37 +00:00
  cf0210bf22
• Return image content from view_image (#12553)

  Responses API supports image content

  pakrym-oai · 2026-02-22 23:00:08 -08:00
  335a4e1cbc
• feat: monitor role (#12364)
  jif-oai · 2026-02-22 14:13:56 +00:00
  4666a6e631
• core: preserve constrained approval/sandbox policies in TurnContext (#12473)
  Michael Bolin · 2026-02-21 14:40:24 -08:00
  66d5d34e6e
• fix: codex-arg0 no longer depends on codex-core (#12434)

  ## Why
  
  `codex-rs/arg0` only needed two things from `codex-core`:
  
  - the `find_codex_home()` wrapper
  - the special argv flag used for the internal `apply_patch`
  self-invocation path
  
  That made `codex-arg0` depend on `codex-core` for a very small surface
  area. This change removes that dependency edge and moves the shared
  `apply_patch` invocation flag to a more natural boundary
  (`codex-apply-patch`) while keeping the contract explicitly documented.
  
  ## What Changed
  
  - Moved the internal `apply_patch` argv[1] flag constant out of
  `codex-core` and into `codex-apply-patch`.
  - Renamed the constant to `CODEX_CORE_APPLY_PATCH_ARG1` and documented
  that it is part of the Codex core process-invocation contract (even
  though it now lives in `codex-apply-patch`).
  - Updated `arg0`, the core apply-patch runtime, and the `codex-exec`
  apply-patch test to import the constant from `codex-apply-patch`.
  - Updated `codex-rs/arg0` to call
  `codex_utils_home_dir::find_codex_home()` directly instead of
  `codex_core::config::find_codex_home()`.
  - Removed the `codex-core` dependency from `codex-rs/arg0` and added the
  needed direct dependency on `codex-utils-home-dir`.
  - Added `codex-apply-patch` as a dev-dependency for `codex-rs/exec`
  tests (the apply-patch test now imports the moved constant directly).
  
  ## Verification
  
  - `cargo test -p codex-apply-patch`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core --lib apply_patch`
  - `cargo test -p codex-exec
  test_standalone_exec_cli_can_use_apply_patch`
  - `cargo shear`

  Michael Bolin · 2026-02-21 00:20:42 -08:00
  2fe4be1aa9
• [apps] Implement apps configs. (#12086)

  - [x] Implement apps configs.

  Matthew Zeng · 2026-02-20 12:05:21 -08:00
  aa121a115e
• feat: add config allow_login_shell (#12312)
  jif-oai · 2026-02-20 20:02:24 +00:00
  5034d4bd89
• js_repl: remove codex.state helper references (#12275)

  ## Summary
  
  This PR removes `codex.state` from the `js_repl` helper surface and
  removes all corresponding documentation/instruction references.
  
  ## Motivation
  
  Top-level bindings in `js_repl` now persist across cells, so the extra
  `codex.state` helper is redundant and adds unnecessary API/docs surface.
  
  ## Changes
  
  - Removed the long-lived `state` object from the Node kernel helper
  wiring.
  - Stopped exposing `codex.state` (and `context.state`) during `js_repl`
  execution.
  - Updated user-facing `js_repl` docs to remove `codex.state`.
  - Updated generated instruction text and related test expectations to
  list only:
    - `codex.tmpDir`
    - `codex.tool(name, args?)`
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - ✅ `1` https://github.com/openai/codex/pull/12300
  - 👉 `2` https://github.com/openai/codex/pull/12275
  - ⏳ `3` https://github.com/openai/codex/pull/12205
  - ⏳ `4` https://github.com/openai/codex/pull/12185
  - ⏳ `5` https://github.com/openai/codex/pull/10673

  Curtis 'Fjord' Hawthorne · 2026-02-20 11:20:45 -08:00
  097620218d
• js_repl: block wrapped payload prefixes in grammar (#12300)

  ## Summary
  
  Tighten the `js_repl` freeform Lark grammar to block the most common
  malformed payload wrappers before they reach runtime validation.
  
  ## What Changed
  
  - Replaced the overly permissive `js_repl` freeform grammar (`start:
  /[\s\S]*/`) with a structured grammar that still supports:
    - plain JS source
    - optional first-line `// codex-js-repl:` pragma followed by JS source
  - Added grammar-level filtering for common bad payload shapes by
  rejecting inputs whose first significant token starts with:
    - `{` (JSON object wrapper like `{"code":"..."}`)
    - `"` (quoted code string)
    - `` ``` `` (markdown code fences)
  - Implemented the grammar without regex lookahead/lookbehind because the
  API-side Lark regex engine does not support look-around.
  - Added a unit test to validate the grammar shape and guard against
  reintroducing unsupported lookaround.
  
  ## Why
  
  `js_repl` is a freeform tool, but the model sometimes emits wrapped
  payloads (JSON, quoted strings, markdown fences) instead of raw
  JavaScript. We already reject those at runtime, but this change moves
  the constraint into the tool grammar so the model is less likely to
  generate invalid tool-call payloads in the first place.
  
  ## Testing
  
  - `cargo test -p codex-core
  js_repl_freeform_grammar_blocks_common_non_js_prefixes`
  - `cargo test -p codex-core parse_freeform_args_rejects_`
  
  ## Notes
  
  - This intentionally over-blocks a few uncommon valid JS starts (for
  example top-level `{ ... }` blocks or top-level quoted directives like
  `"use strict";`) in exchange for preventing the common wrapped-payload
  mistakes.
  
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/12300
  - ⏳ `2` https://github.com/openai/codex/pull/12275
  - ⏳ `3` https://github.com/openai/codex/pull/12205
  - ⏳ `4` https://github.com/openai/codex/pull/12185
  - ⏳ `5` https://github.com/openai/codex/pull/10673

  Curtis 'Fjord' Hawthorne · 2026-02-20 10:47:07 -08:00
  73fd939296
• Refactor network approvals to host/protocol/port scope (#12140)

  ## Summary
  Simplify network approvals by removing per-attempt proxy correlation and
  moving to session-level approval dedupe keyed by (host, protocol, port).
  Instead of encoding attempt IDs into proxy credentials/URLs, we now
  treat approvals as a destination policy decision.
  
  - Concurrent calls to the same destination share one approval prompt.
  - Different destinations (or same host on different ports) get separate
  prompts.
  - Allow once approves the current queued request group only.
  - Allow for session caches that (host, protocol, port) and auto-allows
  future matching requests.
  - Never policy continues to deny without prompting.
  
  Example:
  - 3 calls: 
    - a.com (line 443)
    - b.com (line 443)
    - a.com (line 443)
  => 2 prompts total (a, b), second a waits on the first decision.
  - a.com:80 is treated separately from a.com line 443
  
  ## Testing
  - `just fmt` (in `codex-rs`)
  - `cargo test -p codex-core tools::network_approval::tests`
  - `cargo test -p codex-core` (unit tests pass; existing
  integration-suite failures remain in this environment)

  viyatb-oai · 2026-02-20 10:39:55 -08:00
  e8afaed502
• feat: cleaner TUI for sub-agents (#12327)

  <img width="760" height="496" alt="Screenshot 2026-02-20 at 14 31 25"
  src="https://github.com/user-attachments/assets/1983b825-bb47-417e-9925-6f727af56765"
  />

  jif-oai · 2026-02-20 15:26:33 +00:00
  4d60c803ba
• Add MCP server context to otel tool_result logs (#12267)

  Summary
  - capture the origin for each configured MCP server and expose it via
  the connection manager
  - plumb MCP server name/origin into tool logging and emit
  codex.tool_result events with those fields
  - add unit coverage for origin parsing and extend OTEL tests to assert
  empty MCP fields for non-MCP tools
  - currently not logging full urls or url paths to prevent logging
  potentially sensitive data
  
  Testing
  - Not run (not requested)

  colby-oai · 2026-02-20 10:26:19 -05:00
  2036a5f5e0
• feat: add nick name to sub-agents (#12320)

  Adding random nick name to sub-agents. Used for UX
  
  At the same time, also storing and wiring the role of the sub-agent

  jif-oai · 2026-02-20 14:39:49 +00:00
  0f9eed3a6f
• chore: nit explorer (#12315)
  jif-oai · 2026-02-20 11:24:28 +00:00
  03ff04cd65