93 Commits

• Move environment abstraction into exec server (#15125)

  The idea is that codex-exec exposes an Environment struct with services
  on it. Each of those is a trait.
  
  Depending on construction parameters passed to Environment they are
  either backed by local or remote server but core doesn't see these
  differences.

  pakrym-oai · 2026-03-19 08:31:14 -07:00
  dee03da508
• fix(subagents) share execpolicy by default (#13702)

  ## Summary
  If a subagent requests approval, and the user persists that approval to
  the execpolicy, it should (by default) propagate. We'll need to rethink
  this a bit in light of coming Permissions changes, though I think this
  is closer to the end state that we'd want, which is that execpolicy
  changes to one permissions profile should be synced across threads.
  
  ## Testing
  - [x] Added integration test
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-03-18 06:42:26 +00:00
  84f4e7b39d
• [hooks] userpromptsubmit - hook before user's prompt is executed (#14626)

  - this allows blocking the user's prompts from executing, and also
  prevents them from entering history
  - handles the edge case where you can both prevent the user's prompt AND
  add n amount of additionalContexts
  - refactors some old code into common.rs where hooks overlap
  functionality
  - refactors additionalContext being previously added to user messages,
  instead we use developer messages for them
  - handles queued messages correctly
  
  Sample hook for testing - if you write "[block-user-submit]" this hook
  will stop the thread:
  
  example run
  ```
  › sup
  
  
  • Running UserPromptSubmit hook: reading the observatory notes
  
  UserPromptSubmit hook (completed)
    warning: wizard-tower UserPromptSubmit demo inspected: sup
    hook context: Wizard Tower UserPromptSubmit demo fired. For this reply only, include the exact
  phrase 'observatory lanterns lit' exactly once near the end.
  
  • Just riding the cosmic wave and ready to help, my friend. What are we building today? observatory
    lanterns lit
  
  
  › and [block-user-submit]
  
  
  • Running UserPromptSubmit hook: reading the observatory notes
  
  UserPromptSubmit hook (stopped)
    warning: wizard-tower UserPromptSubmit demo blocked the prompt on purpose.
    stop: Wizard Tower demo block: remove [block-user-submit] to continue.
  ```
  
  .codex/config.toml
  ```
  [features]
  codex_hooks = true
  ```
  
  .codex/hooks.json
  ```
  {
    "hooks": {
      "UserPromptSubmit": [
        {
          "hooks": [
            {
              "type": "command",
              "command": "/usr/bin/python3 .codex/hooks/user_prompt_submit_demo.py",
              "timeoutSec": 10,
              "statusMessage": "reading the observatory notes"
            }
          ]
        }
      ]
    }
  }
  ```
  
  .codex/hooks/user_prompt_submit_demo.py
  ```
  #!/usr/bin/env python3
  
  import json
  import sys
  from pathlib import Path
  
  
  def prompt_from_payload(payload: dict) -> str:
      prompt = payload.get("prompt")
      if isinstance(prompt, str) and prompt.strip():
          return prompt.strip()
  
      event = payload.get("event")
      if isinstance(event, dict):
          user_prompt = event.get("user_prompt")
          if isinstance(user_prompt, str):
              return user_prompt.strip()
  
      return ""
  
  
  def main() -> int:
      payload = json.load(sys.stdin)
      prompt = prompt_from_payload(payload)
      cwd = Path(payload.get("cwd", ".")).name or "wizard-tower"
  
      if "[block-user-submit]" in prompt:
          print(
              json.dumps(
                  {
                      "systemMessage": (
                          f"{cwd} UserPromptSubmit demo blocked the prompt on purpose."
                      ),
                      "decision": "block",
                      "reason": (
                          "Wizard Tower demo block: remove [block-user-submit] to continue."
                      ),
                  }
              )
          )
          return 0
  
      prompt_preview = prompt or "(empty prompt)"
      if len(prompt_preview) > 80:
          prompt_preview = f"{prompt_preview[:77]}..."
  
      print(
          json.dumps(
              {
                  "systemMessage": (
                      f"{cwd} UserPromptSubmit demo inspected: {prompt_preview}"
                  ),
                  "hookSpecificOutput": {
                      "hookEventName": "UserPromptSubmit",
                      "additionalContext": (
                          "Wizard Tower UserPromptSubmit demo fired. "
                          "For this reply only, include the exact phrase "
                          "'observatory lanterns lit' exactly once near the end."
                      ),
                  },
              }
          )
      )
      return 0
  
  
  if __name__ == "__main__":
      raise SystemExit(main())
  ```

  Andrei Eternal · 2026-03-17 22:09:22 -07:00
  6fef421654
• Add FS abstraction and use in view_image (#14960)

  Adds an environment crate and environment + file system abstraction.
  
  Environment is a combination of attributes and services specific to
  environment the agent is connected to:
  File system, process management, OS, default shell.
  
  The goal is to move most of agent logic that assumes environment to work
  through the environment abstraction.

  pakrym-oai · 2026-03-17 17:36:23 -07:00
  83a60fdb94
• fix(core): prevent hanging turn/start due to websocket warming issues (#14838)

  ## Description
  
  This PR fixes a bad first-turn failure mode in app-server when the
  startup websocket prewarm hangs. Before this change, `initialize ->
  thread/start -> turn/start` could sit behind the prewarm for up to five
  minutes, so the client would not see `turn/started`, and even
  `turn/interrupt` would block because the turn had not actually started
  yet.
  
  Now, we:
  - set a (configurable) timeout of 15s for websocket startup time,
  exposed as `websocket_startup_timeout_ms` in config.toml
  - `turn/started` is sent immediately on `turn/start` even if the
  websocket is still connecting
  - `turn/interrupt` can be used to cancel a turn that is still waiting on
  the websocket warmup
  - the turn task will wait for the full 15s websocket warming timeout
  before falling back
  
  ## Why
  
  The old behavior made app-server feel stuck at exactly the moment the
  client expects turn lifecycle events to start flowing. That was
  especially painful for external clients, because from their point of
  view the server had accepted the request but then went silent for
  minutes.
  
  ## Configuring the websocket startup timeout
  Can set it in config.toml like this:
  ```
  [model_providers.openai]
  supports_websockets = true
  websocket_connect_timeout_ms = 15000
  ```

  Owen Lin · 2026-03-17 10:07:46 -07:00
  6ea041032b
• fix: move inline codex-rs/core unit tests into sibling files (#14444)

  ## Why
  PR #13783 moved the `codex.rs` unit tests into `codex_tests.rs`. This
  applies the same extraction pattern across the rest of `codex-rs/core`
  so the production modules stay focused on runtime code instead of large
  inline test blocks.
  
  Keeping the tests in sibling files also makes follow-up edits easier to
  review because product changes no longer have to share a file with
  hundreds or thousands of lines of test scaffolding.
  
  ## What changed
  - replaced each inline `mod tests { ... }` in `codex-rs/core/src/**`
  with a path-based module declaration
  - moved each extracted unit test module into a sibling `*_tests.rs`
  file, using `mod_tests.rs` for `mod.rs` modules
  - preserved the existing `cfg(...)` guards and module-local structure so
  the refactor remains structural rather than behavioral
  
  ## Testing
  - `cargo test -p codex-core --lib` (`1653 passed; 0 failed; 5 ignored`)
  - `just fix -p codex-core`
  - `cargo fmt --check`
  - `cargo shear`

  Michael Bolin · 2026-03-12 08:16:36 -07:00
  0c8a36676a
• Support waiting for code_mode sessions (#14295)

  ## Summary
  - persist the code mode runner process in the session-scoped code mode
  store
  - switch the runner protocol from `init` to `start` with explicit
  session ids
  - handle runner-side session processing without the init waiter queue
  
  ## Validation
  - just fmt
  - cargo check -p codex-core
  - node --check codex-rs/core/src/tools/code_mode_runner.cjs

  pakrym-oai · 2026-03-11 23:13:54 -07:00
  f6c6128fc7
• feat: search_tool migrate to bring you own tool of Responses API (#14274)

  ## Why
  
  to support a new bring your own search tool in Responses
  API(https://developers.openai.com/api/docs/guides/tools-tool-search#client-executed-tool-search)
  we migrating our bm25 search tool to use official way to execute search
  on client and communicate additional tools to the model.
  
  ## What
  - replace the legacy `search_tool_bm25` flow with client-executed
  `tool_search`
  - add protocol, SSE, history, and normalization support for
  `tool_search_call` and `tool_search_output`
  - return namespaced Codex Apps search results and wire namespaced
  follow-up tool calls back into MCP dispatch

  Anton Panasenko · 2026-03-11 17:51:51 -07:00
  77b0c75267
• Add store/load support for code mode (#14259)

  adds support for transferring state across code mode invocations.

  pakrym-oai · 2026-03-11 12:33:09 -07:00
  83b22bb612
• start of hooks engine (#13276)

  (Experimental)
  
  This PR adds a first MVP for hooks, with SessionStart and Stop
  
  The core design is:
  
  - hooks live in a dedicated engine under codex-rs/hooks
  - each hook type has its own event-specific file
  - hook execution is synchronous and blocks normal turn progression while
  running
  - matching hooks run in parallel, then their results are aggregated into
  a normalized HookRunSummary
  
  On the AppServer side, hooks are exposed as operational metadata rather
  than transcript-native items:
  
  - new live notifications: hook/started, hook/completed
  - persisted/replayed hook results live on Turn.hookRuns
  - we intentionally did not add hook-specific ThreadItem variants
  
  Hooks messages are not persisted, they remain ephemeral. The context
  changes they add are (they get appended to the user's prompt)

  Andrei Eternal · 2026-03-10 04:11:31 +00:00
  244b2d53f4
• feat(core) Persist request_permission data across turns (#14009)

  ## Summary
  request_permissions flows should support persisting results for the
  session.
  
  Open Question: Still deciding if we need within-turn approvals - this
  adds complexity but I could see it being useful
  
  ## Testing
  - [x] Updated unit tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-03-09 14:36:38 -07:00
  d241dc598c
• Add request permissions tool (#13092)

  Adds a built-in `request_permissions` tool and wires it through the
  Codex core, protocol, and app-server layers so a running turn can ask
  the client for additional permissions instead of relying on a static
  session policy.
  
  The new flow emits a `RequestPermissions` event from core, tracks the
  pending request by call ID, forwards it through app-server v2 as an
  `item/permissions/requestApproval` request, and resumes the tool call
  once the client returns an approved subset of the requested permission
  profile.

  Jack Mousseau · 2026-03-08 20:23:06 -07:00
  e6b93841c5
• chore(otel): rename OtelManager to SessionTelemetry (#13808)

  ## Summary
  This is a purely mechanical refactor of `OtelManager` ->
  `SessionTelemetry` to better convey what the struct is doing. No
  behavior change.
  
  ## Why
  
  `OtelManager` ended up sounding much broader than what this type
  actually does. It doesn't manage OTEL globally; it's the session-scoped
  telemetry surface for emitting log/trace events and recording metrics
  with consistent session metadata (`app_version`, `model`, `slug`,
  `originator`, etc.).
  
  `SessionTelemetry` is a more accurate name, and updating the call sites
  makes that boundary a lot easier to follow.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-otel`
  - `cargo test -p codex-core`

  Owen Lin · 2026-03-06 16:23:30 -08:00
  289ed549cf
• [elicitations] Switch to use MCP style elicitation payload for mcp tool approvals. (#13621)

  - [x] Switch to use MCP style elicitation payload for mcp tool
  approvals.
  - [ ] TODO: Update the UI to support the full spec.

  Matthew Zeng · 2026-03-06 01:50:26 -08:00
  98dca99db7
• feat: external artifacts builder (#13485)

  This PR reverts the built-in artifact render while a decision is being
  reached. No impact expected on any features

  jif-oai · 2026-03-04 20:22:34 +00:00
  2322e49549
• feat: add metric for per-turn tool count and add tmp_mem flag (#13456)
  jif-oai · 2026-03-04 11:25:58 +00:00
  e07eaff0d3
• add metric for per-turn token usage (#13454)
  jif-oai · 2026-03-04 10:17:25 +00:00
  49634b7f9c
• feat: wire spreadsheet artifact (#13362)
  jif-oai · 2026-03-03 15:27:37 +00:00
  8159f05dfd
• feat: presentation artifact p1 (#13341)

  Part 1 of presentation tool artifact

  jif-oai · 2026-03-03 11:38:03 +00:00
  4874b9291a
• Record realtime close marker on replacement (#13058)

  ## Summary
  - record a realtime close developer message when a new realtime session
  replaces an active one
  - assert the replacement marker through the mocked responses request
  path
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Charles Cunningham <ccunningham@openai.com>

  Ahmed Ibrahim · 2026-03-01 13:54:12 -08:00
  0aeb55bf08
• feat: load from plugins (#12864)

  Support loading plugins.
  
  Plugins can now be enabled via [plugins.<name>] in config.toml. They are
  loaded as first-class entities through PluginsManager, and their default
  skills/ and .mcp.json contributions are integrated into the existing
  skills and MCP flows.

  xl-openai · 2026-03-01 10:50:56 -08:00
  752402c4fe
• Revert "Add skill approval event/response (#12633)" (#12811)

  This reverts commit https://github.com/openai/codex/pull/12633. We no
  longer need this PR, because we favor sending normal exec command
  approval server request with `additional_permissions` of skill
  permissions instead

  Celia Chen · 2026-02-26 01:02:42 +00:00
  4f45668106
• 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
• 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
• 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
• 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
• Send warmup request (#11258)

  Send a request with `generate: falls` but a full set of tools and
  instructions to pre-warm inference.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-02-24 08:15:47 -08:00
  97d0068658
• Add skill approval event/response (#12633)

  Set the stage for skill-level permission approval in addition to
  command-level.
  
  Behind a feature flag.

  pakrym-oai · 2026-02-23 22:28:58 -08:00
  58763afa0f
• Fix compaction context reinjection and model baselines (#12252)

  ## Summary
  - move regular-turn context diff/full-context persistence into
  `run_turn` so pre-turn compaction runs before incoming context updates
  are recorded
  - after successful pre-turn compaction, rely on a cleared
  `reference_context_item` to trigger full context reinjection on the
  follow-up regular turn (manual `/compact` keeps replacement history
  summary-only and also clears the baseline)
  - preserve `<model_switch>` when full context is reinjected, and inject
  it *before* the rest of the full-context items
  - scope `reference_context_item` and `previous_model` to regular user
  turns only so standalone tasks (`/compact`, shell, review, undo) cannot
  suppress future reinjection or `<model_switch>` behavior
  - make context-diff persistence + `reference_context_item` updates
  explicit in the regular-turn path, with clearer docs/comments around the
  invariant
  - stop persisting local `/compact` `RolloutItem::TurnContext` snapshots
  (only regular turns persist `TurnContextItem` now)
  - simplify resume/fork previous-model/reference-baseline hydration by
  looking up the last surviving turn context from rollout lifecycle
  events, including rollback and compaction-crossing handling
  - remove the legacy fallback that guessed from bare `TurnContext`
  rollouts without lifecycle events
  - update compaction/remote-compaction/model-visible snapshots and
  compact test assertions (including remote compaction mock response
  shape)
  
  ## Why
  We were persisting incoming context items before spawning the regular
  turn task, which let pre-turn compaction requests accidentally include
  incoming context diffs without the new user message. Fixing that exposed
  follow-on baseline issues around `/compact`, resume/fork, and standalone
  tasks that could cause duplicate context injection or suppress
  `<model_switch>` instructions.
  
  This PR re-centers the invariants around regular turns:
  - regular turns persist model-visible context diffs/full reinjection and
  update the `reference_context_item`
  - standalone tasks do not advance those regular-turn baselines
  - compaction clears the baseline when replacement history may have
  stripped the referenced context diffs
  
  ## Follow-ups (TODOs left in code)
  - `TODO(ccunningham)`: fix rollback/backtracking baseline handling more
  comprehensively
  - `TODO(ccunningham)`: include pending incoming context items in
  pre-turn compaction threshold estimation
  - `TODO(ccunningham)`: inject updated personality spec alongside
  `<model_switch>` so some model-switch paths can avoid forced full
  reinjection
  - `TODO(ccunningham)`: review task turn lifecycle
  (`TurnStarted`/`TurnComplete`) behavior and emit task-start context
  diffs for task types that should have them (excluding `/compact`)
  
  ## Validation
  - `just fmt`
  - CI should cover the updated compaction/resume/model-visible snapshot
  expectations and rollout-hydration behavior
  - I did **not** rerun the full local test suite after the latest
  resume-lookup / rollout-persistence simplifications

  Charley Cunningham · 2026-02-20 23:13:08 -08:00
  bb0ac5be70
• Move previous turn context tracking into ContextManager history (#12179)

  ## Summary
  - add `previous_context_item: Option<TurnContextItem>` to
  `ContextManager`
  - expose session/state accessors for reading and updating the stored
  previous context item
  - switch settings diffing to use `TurnContextItem` instead of
  `TurnContext`
  - remove submission-loop local `previous_context` and persist the
  previous context item in history
  
  ## Testing
  - `just fmt`
  - `just fix -p codex-core`
  - `cargo test -p codex-core --test all model_switching::`
  - `cargo test -p codex-core --test all collaboration_instructions::`
  - `cargo test -p codex-core --test all personality::`
  - `cargo test -p codex-core --test all
  permissions_messages::permissions_message_not_added_when_no_change`

  Charley Cunningham · 2026-02-19 09:56:20 -08:00
  f2d5842ed1
• feat(core): zsh exec bridge (#12052)

  zsh fork PR stack:
  - https://github.com/openai/codex/pull/12051 
  - https://github.com/openai/codex/pull/12052 👈 
  
  ### Summary
  This PR introduces a feature-gated native shell runtime path that routes
  shell execution through a patched zsh exec bridge, removing MCP-specific
  behavior from the shell hot path while preserving existing
  CommandExecution lifecycle semantics.
  
  When shell_zsh_fork is enabled, shell commands run via patched zsh with
  per-`execve` interception through EXEC_WRAPPER. Core receives wrapper
  IPC requests over a Unix socket, applies existing approval policy, and
  returns allow/deny before the subcommand executes.
  
  ### What’s included
  **1) New zsh exec bridge runtime in core**
  - Wrapper-mode entrypoint (maybe_run_zsh_exec_wrapper_mode) for
  EXEC_WRAPPER invocations.
  - Per-execution Unix-socket IPC handling for wrapper requests/responses.
  - Approval callback integration using existing core approval
  orchestration.
  - Streaming stdout/stderr deltas to existing command output event
  pipeline.
  - Error handling for malformed IPC, denial/abort, and execution
  failures.
  
  **2) Session lifecycle integration**
  SessionServices now owns a `ZshExecBridge`.
  Session startup initializes bridge state; shutdown tears it down
  cleanly.
  
  **3) Shell runtime routing (feature-gated)**
  When `shell_zsh_fork` is enabled:
  - Build execution env/spec as usual.
  - Add wrapper socket env wiring.
  - Execute via `zsh_exec_bridge.execute_shell_request(...)` instead of
  the regular shell path.
  - Non-zsh-fork behavior remains unchanged.
  
  **4) Config + feature wiring**
  - Added `Feature::ShellZshFork` (under development).
  - Added config support for `zsh_path` (optional absolute path to patched
  zsh):
  - `Config`, `ConfigToml`, `ConfigProfile`, overrides, and schema.
  - Session startup validates that `zsh_path` exists/usable when zsh-fork
  is enabled.
  - Added startup test for missing `zsh_path` failure mode.
  
  **5) Seatbelt/sandbox updates for wrapper IPC**
  - Extended seatbelt policy generation to optionally allow outbound
  connection to explicitly permitted Unix sockets.
  - Wired sandboxing path to pass wrapper socket path through to seatbelt
  policy generation.
  - Added/updated seatbelt tests for explicit socket allow rule and
  argument emission.
  
  **6) Runtime entrypoint hooks**
  - This allows the same binary to act as the zsh wrapper subprocess when
  invoked via `EXEC_WRAPPER`.
  
  **7) Tool selection behavior**
  - ToolsConfig now prefers ShellCommand type when shell_zsh_fork is
  enabled.
  - Added test coverage for precedence with unified-exec enabled.

  Owen Lin · 2026-02-17 20:19:53 -08:00
  edacbf7b6e
• feat: persist and restore codex app's tools after search (#11780)

  ### What changed
  1. Removed per-turn MCP selection reset in `core/src/tasks/mod.rs`.
  2. Added `SessionState::set_mcp_tool_selection(Vec<String>)` in
  `core/src/state/session.rs` for authoritative restore behavior (deduped,
  order-preserving, empty clears).
  3. Added rollout parsing in `core/src/codex.rs` to recover
  `active_selected_tools` from prior `search_tool_bm25` outputs:
     - tracks matching `call_id`s
     - parses function output text JSON
     - extracts `active_selected_tools`
     - latest valid payload wins
     - malformed/non-matching payloads are ignored
  4. Applied restore logic to resumed and forked startup paths in
  `core/src/codex.rs`.
  5. Updated instruction text to session/thread scope in
  `core/templates/search_tool/tool_description.md`.
  6. Expanded tests in `core/tests/suite/search_tool.rs`, plus unit
  coverage in:
     - `core/src/codex.rs`
     - `core/src/state/session.rs`
  
  ### Behavior after change
  1. Search activates matched tools.
  2. Additional searches union into active selection.
  3. Selection survives new turns in the same thread.
  4. Resume/fork restores selection from rollout history.
  5. Separate threads do not inherit selection unless forked.

  Anton Panasenko · 2026-02-15 19:18:41 -08:00
  02abd9a8ea
• feat(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• Parse first order skill/connector mentions (#11547)

  This PR introduces a skill-expansion mechanism for mentions so nested or
  skill or connection mentions are expanded if present in skills invoked
  by the user. This keeps behavior aligned with existing mention handling
  while extending coverage to deeper scenarios. With these changes, users
  can create skills that invoke connectors, and skills that invoke other
  skills.
  
  Replaces #10863, which is not needed with the addition of
  [search_tool_bm25](https://github.com/openai/codex/issues/10657)

  canvrno-oai · 2026-02-12 10:55:22 -08:00
  22fa283511
• fix: stop inheriting rate-limit limit_name (#11557)

  When we carry over values from partial rate-limit, we should only do so
  for the same limit_id.

  xl-openai · 2026-02-12 00:17:48 -08:00
  6ca9b4327b
• Hydrate previous model across resume/fork/rollback/task start (#11497)

  - Replace pending resume model state with persistent previous_model and
  hydrate it on resume, fork, rollback, and task end in spawn_task

  Ahmed Ibrahim · 2026-02-11 16:45:18 -08:00
  bb5dfd037a
• feat: support multiple rate limits (#11260)

  Added multi-limit support end-to-end by carrying limit_name in
  rate-limit snapshots and handling multiple buckets instead of only
  codex.
  Extended /usage client parsing to consume additional_rate_limits
  Updated TUI /status and in-memory state to store/render per-limit
  snapshots
  Extended app-server rate-limit read response: kept rate_limits and added
  rate_limits_by_name.
  Adjusted usage-limit error messaging for non-default codex limit buckets

  xl-openai · 2026-02-10 20:09:31 -08:00
  fdd0cd1de9
• Extract hooks into dedicated crate (#11311)

  Summary
  - move `core/src/hooks` implementation into a new `codex-hooks` crate
  with its own manifest
  - update `codex-rs` workspace and `codex-core` crate to depend on the
  extracted `hooks` crate and wire up the shared APIs
  - ensure references, modules, and lockfile reflect the new crate layout
  
  Testing
  - Not run (not requested)

  jif-oai · 2026-02-10 13:42:17 +00:00
  d735df1f50
• feat: retain NetworkProxy, when appropriate (#11207)

  As of this PR, `SessionServices` retains a
  `Option<StartedNetworkProxy>`, if appropriate.
  
  Now the `network` field on `Config` is `Option<NetworkProxySpec>`
  instead of `Option<NetworkProxy>`.
  
  Over in `Session::new()`, we invoke `NetworkProxySpec::start_proxy()` to
  create the `StartedNetworkProxy`, which is a new struct that retains the
  `NetworkProxy` as well as the `NetworkProxyHandle`. (Note that `Drop` is
  implemented for `NetworkProxyHandle` to ensure the proxies are shutdown
  when it is dropped.)
  
  The `NetworkProxy` from the `StartedNetworkProxy` is threaded through to
  the appropriate places.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/11207).
  * #11285
  * __->__ #11207

  Michael Bolin · 2026-02-10 02:09:23 -08:00
  44ebf4588f
• feat: tie shell snapshot to cwd (#11231)

  Fix for this: https://github.com/openai/codex/issues/11223
  
  Basically we tie the shell snapshot to a `cwd` to handle `cwd`-based env
  setups

  jif-oai · 2026-02-09 22:14:39 +00:00
  ffd4bd345c
• feat: search_tool (#10657)

  **Why We Did This**
  - The goal is to reduce MCP tool context pollution by not exposing the
  full MCP tool list up front
  - It forces an explicit discovery step (`search_tool_bm25`) so the model
  narrows tool scope before making MCP calls, which helps relevance and
  lowers prompt/tool clutter.
  
  **What It Changed**
  - Added a new experimental feature flag `search_tool` in
  `core/src/features.rs:90` and `core/src/features.rs:430`.
  - Added config/schema support for that flag in
  `core/config.schema.json:214` and `core/config.schema.json:1235`.
  - Added BM25 dependency (`bm25`) in `Cargo.toml:129` and
  `core/Cargo.toml:23`.
  - Added new tool handler `search_tool_bm25` in
  `core/src/tools/handlers/search_tool_bm25.rs:18`.
  - Registered the handler and tool spec in
  `core/src/tools/handlers/mod.rs:11` and `core/src/tools/spec.rs:780` and
  `core/src/tools/spec.rs:1344`.
  - Extended `ToolsConfig` to carry `search_tool` enablement in
  `core/src/tools/spec.rs:32` and `core/src/tools/spec.rs:56`.
  - Injected dedicated developer instructions for tool-discovery workflow
  in `core/src/codex.rs:483` and `core/src/codex.rs:1976`, using
  `core/templates/search_tool/developer_instructions.md:1`.
  - Added session state to store one-shot selected MCP tools in
  `core/src/state/session.rs:27` and `core/src/state/session.rs:131`.
  - Added filtering so when feature is enabled, only selected MCP tools
  are exposed on the next request (then consumed) in
  `core/src/codex.rs:3800` and `core/src/codex.rs:3843`.
  - Added E2E suite coverage for
  enablement/instructions/hide-until-search/one-turn-selection in
  `core/tests/suite/search_tool.rs:72`,
  `core/tests/suite/search_tool.rs:109`,
  `core/tests/suite/search_tool.rs:147`, and
  `core/tests/suite/search_tool.rs:218`.
  - Refactored test helper utilities to support config-driven tool
  collection in `core/tests/suite/tools.rs:281`.
  
  **Net Behavioral Effect**
  - With `search_tool` **off**: existing MCP behavior (tools exposed
  normally).
  - With `search_tool` **on**: MCP tools start hidden, model must call
  `search_tool_bm25`, and only returned `selected_tools` are available for
  the next model call.

  Anton Panasenko · 2026-02-09 12:53:50 -08:00
  becc3a0424
• Move warmup to the task level (#11216)

  Instead of storing a special connection on the client level make the
  regular task responsible for establishing a normal client session and
  open a connection on it.
  
  Then when the turn is started we pass in a pre-established session.

  pakrym-oai · 2026-02-09 10:57:52 -08:00
  ccd17374cb
• Add hooks implementation and wire up to notify (#9691)

  This introduces a `Hooks` service. It registers hooks from config and
  dispatches hook events at runtime.
  
  N.B. The hook config is not wired up to this yet. But for legacy
  reasons, we wire up `notify` from config and power it using hooks now.
  Nothing about the `notify` interface has changed.
  
  I'd start by reviewing `hooks/types.rs`
  
  Some things to note:
    - hook names subject to change
    - no hook result yet
    - stopping semantics yet to be introduced
    - additional hooks yet to be introduced

  gt-oai · 2026-02-05 16:49:35 +00:00
  3b54fd7336
• fix(core,app-server) resume with different model (#10719)

  ## Summary
  When resuming with a different model, we should also append a developer
  message with the model instructions
  
  ## Testing
  - [x] Added unit tests

  Dylan Hurd · 2026-02-05 00:40:05 -08:00
  fe8b474acd
• Session-level model client (#10664)

  Make ModelClient a session-scoped object.
  Move state that is session level onto the client, and make state that is
  per-turn explicit on corresponding methods.
  Stop taking a huge Config object, instead only pass in values that are
  actually needed.
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  pakrym-oai · 2026-02-04 16:58:48 -08:00
  0e8d359da9
• Added support for live updates to skills (#10478)

  Add a centralized FileWatcher in codex-core (using notify) that watches
  skill roots from the config layer stack (recursive)
  
  Send `SkillsChanged` events when relevant file system changes are
  detected
  
  On `SkillsChanged`:
  * Invalidate the skills cache immediately in ThreadManager
  * Emit EventMsg::SkillsUpdateAvailable to active sessions
  ~~* Broadcast a new app-server notification:
  SkillsListUpdatedNotification~~
  
  This change does not inject new items into the event stream. That means
  the agent will not know about new skills, so it won't be able to
  implicitly invoke new skills. It also won't know about changes to
  existing skills, so if it has already read the contents of a modified
  skill, it will not honor the new behavior.
  
  This change also does not detect modifications to AGENTS.md.
  
  I plan to address these limitations in a follow-on PR modeled after
  #9985. Injection of new skills and AGENTS was deemed to risky, hence the
  need to split the feature into two stages. The changes in this PR were
  designed to easily accommodate the second stage once we have some other
  foundational changes in place.
  
  Testing: In addition to automated tests, I did manual testing to confirm
  that newly-created skills, deleted skills, and renamed skills are
  reflected in the TUI skill picker menu. Also confirmed that
  modifications to behaviors for explicitly-invoked skills are honored.
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  Eric Traut · 2026-02-04 15:25:03 -08:00
  7bcc552325
• feat: fire tracking events for skill invocation (#10120)
  alexsong-oai · 2026-01-31 18:06:26 -08:00
  b164ac6d1e
• Better handling skill depdenencies on ENV VAR. (#9017)

  An experimental flow for env var skill dependencies. Skills can now
  declare required env vars in SKILL.md; if missing, the CLI prompts the
  user to get the value, and Core will store it in memory (eventually to a
  local persistent store)
  <img width="790" height="169" alt="image"
  src="https://github.com/user-attachments/assets/cd928918-9403-43cb-a7e7-b8d59bcccd9a"
  />

  xl-openai · 2026-01-29 14:13:30 -05:00
  bdd8a7d58b
• Fall back to http when websockets fail (#10139)

  I expect not all proxies work with websockets, fall back to http if
  websockets fail.

  pakrym-oai · 2026-01-29 10:36:21 -08:00
  3b1cddf001
• feat: sqlite 1 (#10004)

  Add a `.sqlite` database to be used to store rollout metatdata (and
  later logs)
  This PR is phase 1:
  * Add the database and the required infrastructure
  * Add a backfill of the database
  * Persist the newly created rollout both in files and in the DB
  * When we need to get metadata or a rollout, consider the `JSONL` as the
  source of truth but compare the results with the DB and show any errors

  jif-oai · 2026-01-28 15:29:14 +01:00
  3878c3dc7c