196 Commits

• feat(tui): restore composer history in app-server tui (#14945)

  ## Problem
  
  The app-server TUI (`tui_app_server`) lacked composer history support.
  Pressing Up/Down to recall previous prompts hit a stub that logged a
  warning and displayed "Not available in app-server TUI yet." New
  submissions were silently dropped from the shared history file, so
  nothing persisted for future sessions.
  
  ## Mental model
  
  Codex maintains a single, append-only history file
  (`$CODEX_HOME/history.jsonl`) shared across all TUI processes on the
  same machine. The legacy (in-process) TUI already reads/writes this file
  through `codex_core::message_history`. The app-server TUI delegates most
  operations to a separate process over RPC, but history is intentionally
  *not* an RPC concern — it's a client-local file.
  
  This PR makes the app-server TUI access the same history file directly,
  bypassing the app-server process entirely. The composer's Up/Down
  navigation and submit-time persistence now follow the same code paths as
  the legacy TUI, with the only difference being *where* the call is
  dispatched (locally in `App`, rather than inside `CodexThread`).
  
  The branch is rebuilt directly on top of `upstream/main`, so it keeps
  the
  existing app-server restore architecture intact.
  `AppServerStartedThread`
  still restores transcript history from the server `Thread` snapshot via
  `thread_snapshot_events`; this PR only adds composer-history support.
  
  ## Non-goals
  
  - Adding history support to the app-server protocol. History remains
  client-local.
  - Changing the on-disk format or location of `history.jsonl`.
  - Surfacing history I/O errors to the user (failures are logged and
  silently swallowed, matching the legacy TUI).
  
  ## Tradeoffs
  
  | Decision | Why | Risk |
  |----------|-----|------|
  | Widen `message_history` from `pub(crate)` to `pub` | Avoids
  duplicating file I/O logic; the module already has a clean, minimal API
  surface. | Other workspace crates can now call these functions — the
  contract is no longer crate-private. However, this is consistent with
  recent precedent: `590cfa617` exposed `mention_syntax` for TUI
  consumption, `752402c4f` exposed plugin APIs (`PluginsManager`), and
  `14fcb6645`/`edacbf7b6` widened internal core APIs for other crates.
  These were all narrow, intentional exposures of specific APIs — not
  broad "make internals public" moves. `1af2a37ad` even went the other
  direction, reducing broad re-exports to tighten boundaries. This change
  follows the same pattern: a small, deliberate API surface (3 functions)
  rather than a wholesale visibility change. |
  | Intercept `AddToHistory` / `GetHistoryEntryRequest` in `App` before
  RPC fallback | Keeps history ops out of the "unsupported op" error path
  without changing app-server protocol. | This now routes through a single
  `submit_thread_op` entry point, which is safer than the original
  duplicated dispatch. The remaining risk is organizational: future
  thread-op submission paths need to keep using that shared entry point. |
  | `session_configured_from_thread_response` is now `async` | Needs
  `await` on `history_metadata()` to populate real `history_log_id` /
  `history_entry_count`. | Adds an async file-stat + full-file newline
  scan to the session bootstrap path. The scan is bounded by
  `history.max_bytes` and matches the legacy TUI's cost profile, but
  startup latency still scales with file size. |
  
  ## Architecture
  
  ```
  User presses Up                     User submits a prompt
         │                                    │
         ▼                                    ▼
  ChatComposerHistory                 ChatWidget::do_submit_turn
    navigate_up()                       encode_history_mentions()
         │                                    │
         ▼                                    ▼
    AppEvent::CodexOp                  Op::AddToHistory { text }
    (GetHistoryEntryRequest)                  │
         │                                    ▼
         ▼                            App::try_handle_local_history_op
    App::try_handle_local_history_op    message_history::append_entry()
      spawn_blocking {                        │
        message_history::lookup()             ▼
      }                                $CODEX_HOME/history.jsonl
         │
         ▼
    AppEvent::ThreadEvent
    (GetHistoryEntryResponse)
         │
         ▼
    ChatComposerHistory::on_entry_response()
  ```
  
  ## Observability
  
  - `tracing::warn` on `append_entry` failure (includes thread ID).
  - `tracing::warn` on `spawn_blocking` lookup join error.
  - `tracing::warn` from `message_history` internals on file-open, lock,
  or parse failures.
  
  ## Tests
  
  - `chat_composer_history::tests::navigation_with_async_fetch` — verifies
  that Up emits `Op::GetHistoryEntryRequest` (was: checked for stub error
  cell).
  - `app::tests::history_lookup_response_is_routed_to_requesting_thread` —
  verifies multi-thread composer recall routes the lookup result back to
  the originating thread.
  -
  `app_server_session::tests::resume_response_relies_on_snapshot_replay_not_initial_messages`
  — verifies app-server session restore still uses the upstream
  thread-snapshot path.
  -
  `app_server_session::tests::session_configured_populates_history_metadata`
  — verifies bootstrap sets nonzero `history_log_id` /
  `history_entry_count` from the shared local history file.

  Felipe Coury · 2026-03-18 11:54:11 -06:00
  334164a6f7
• [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
• Prefer websockets when providers support them (#13592)

  Remove all flags and model settings.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-03-17 19:46:44 -07:00
  770616414a
• Add auth env observability (#14905)

  CXC-410 Emit Env Var Status with `/feedback` report
  
  Add more observability on top of #14611 
  
  [Unset](https://openai.sentry.io/issues/7340419168/?project=4510195390611458&query=019cfa8d-c1ba-7002-96fa-e35fc340551d&referrer=issue-stream)
  
  [Set](https://openai.sentry.io/issues/7340426331/?project=4510195390611458&query=019cfa91-aba1-7823-ab7e-762edfbc0ed4&referrer=issue-stream)
  <img width="1063" height="610" alt="image"
  src="https://github.com/user-attachments/assets/937ab026-1c2d-4757-81d5-5f31b853113e"
  />
  
  
  ###### Summary
  - Adds auth-env telemetry that records whether key auth-related env
  overrides were present on session start and request paths.
  - Threads those auth-env fields through `/responses`, websocket, and
  `/models` telemetry and feedback metadata.
  - Buckets custom provider `env_key` configuration to a safe
  `"configured"` value instead of emitting raw config text.
  - Keeps the slice observability-only: no raw token values or raw URLs
  are emitted.
  
  ###### Rationale (from spec findings)
  - 401 and auth-path debugging needs a way to distinguish env-driven auth
  paths from sessions with no auth env override.
  - Startup and model-refresh failures need the same auth-env diagnostics
  as normal request failures.
  - Feedback and Sentry tags need the same auth-env signal as OTel events
  so reports can be triaged consistently.
  - Custom provider config is user-controlled text, so the telemetry
  contract must stay presence-only / bucketed.
  
  ###### Scope
  - Adds a small `AuthEnvTelemetry` bundle for env presence collection and
  threads it through the main request/session telemetry paths.
  - Does not add endpoint/base-url/provider-header/geo routing attribution
  or broader telemetry API redesign.
  
  ###### Trade-offs
  - `provider_env_key_name` is bucketed to `"configured"` instead of
  preserving the literal configured env var name.
  - `/models` is included because startup/model-refresh auth failures need
  the same diagnostics, but broader parity work remains out of scope.
  - This slice keeps the existing telemetry APIs and layers auth-env
  fields onto them rather than redesigning the metadata model.
  
  ###### Client follow-up
  - Add the separate endpoint/base-url attribution slice if routing-source
  diagnosis is still needed.
  - Add provider-header or residency attribution only if auth-env presence
  proves insufficient in real reports.
  - Revisit whether any additional auth-related env inputs need safe
  bucketing after more 401 triage data.
  
  ###### Testing
  - `cargo test -p codex-core emit_feedback_request_tags -- --nocapture`
  - `cargo test -p codex-core
  collect_auth_env_telemetry_buckets_provider_env_key_name -- --nocapture`
  - `cargo test -p codex-core
  models_request_telemetry_emits_auth_env_feedback_tags_on_failure --
  --nocapture`
  - `cargo test -p codex-otel
  otel_export_routing_policy_routes_api_request_auth_observability --
  --nocapture`
  - `cargo test -p codex-otel
  otel_export_routing_policy_routes_websocket_connect_auth_observability
  -- --nocapture`
  - `cargo test -p codex-otel
  otel_export_routing_policy_routes_websocket_request_transport_observability
  -- --nocapture`
  - `cargo test -p codex-core --no-run --message-format short`
  - `cargo test -p codex-otel --no-run --message-format short`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Colin Young · 2026-03-17 14:26:27 -07:00
  0d2ff40a58
• 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
• feat: centralize package manager version (#14920)
  jif-oai · 2026-03-17 12:03:07 +00:00
  31648563c8
• Add auth 401 observability to client bug reports (#14611)

  CXC-392
  
    [With
    401](https://openai.sentry.io/issues/7333870443/?project=4510195390611458&query=019ce8f8-560c-7f10-a00a-c59553740674&referrer=issue-stream)
    <img width="1909" height="555" alt="401 auth tags in Sentry"
    src="https://github.com/user-attachments/assets/412ea950-61c4-4780-9697-15c270971ee3"
    />
  
  
    - auth_401_*: preserved facts from the latest unauthorized response snapshot
    - auth_*: latest auth-related facts from the latest request attempt
    - auth_recovery_*: unauthorized recovery state and follow-up result
  
  
    Without 401
    <img width="1917" height="522" alt="happy-path auth tags in Sentry"
    src="https://github.com/user-attachments/assets/3381ed28-8022-43b0-b6c0-623a630e679f"
    />
  
    ###### Summary
    - Add client-visible 401 diagnostics for auth attachment, upstream auth classification, and 401 request id / cf-ray correlation.
    - Record unauthorized recovery mode, phase, outcome, and retry/follow-up status without changing auth behavior.
    - Surface the highest-signal auth and recovery fields on uploaded client bug reports so they are usable in Sentry.
    - Preserve original unauthorized evidence under `auth_401_*` while keeping follow-up result tags separate.
  
    ###### Rationale (from spec findings)
    - The dominant bucket needed proof of whether the client attached auth before send or upstream still classified the request as missing auth.
    - Client uploads needed to show whether unauthorized recovery ran and what the client tried next.
    - Request id and cf-ray needed to be preserved on the unauthorized response so server-side correlation is immediate.
    - The bug-report path needed the same auth evidence as the request telemetry path, otherwise the observability would not be operationally useful.
  
    ###### Scope
    - Add auth 401 and unauthorized-recovery observability in `codex-rs/core`, `codex-rs/codex-api`, and `codex-rs/otel`, including feedback-tag surfacing.
    - Keep auth semantics, refresh behavior, retry behavior, endpoint classification, and geo-denial follow-up work out of this PR.
  
    ###### Trade-offs
    - This exports only safe auth evidence: header presence/name, upstream auth classification, request ids, and recovery state. It does not export token values or raw upstream bodies.
    - This keeps websocket connection reuse as a transport clue because it can help distinguish stale reused sessions from fresh reconnects.
    - Misroute/base-url classification and geo-denial are intentionally deferred to a separate follow-up PR so this review stays focused on the dominant auth 401 bucket.
  
    ###### Client follow-up
    - PR 2 will add misroute/provider and geo-denial observability plus the matching feedback-tag surfacing.
    - A separate host/app-server PR should log auth-decision inputs so pre-send host auth state can be correlated with client request evidence.
    - `device_id` remains intentionally separate until there is a safe existing source on the feedback upload path.
  
    ###### Testing
    - `cargo test -p codex-core refresh_available_models_sorts_by_priority`
    - `cargo test -p codex-core emit_feedback_request_tags_`
    - `cargo test -p codex-core emit_feedback_auth_recovery_tags_`
    - `cargo test -p codex-core auth_request_telemetry_context_tracks_attached_auth_and_retry_phase`
    - `cargo test -p codex-core extract_response_debug_context_decodes_identity_headers`
    - `cargo test -p codex-core identity_auth_details`
    - `cargo test -p codex-core telemetry_error_messages_preserve_non_http_details`
    - `cargo test -p codex-core --all-features --no-run`
    - `cargo test -p codex-otel otel_export_routing_policy_routes_api_request_auth_observability`
    - `cargo test -p codex-otel otel_export_routing_policy_routes_websocket_connect_auth_observability`
    - `cargo test -p codex-otel otel_export_routing_policy_routes_websocket_request_transport_observability`

  Colin Young · 2026-03-14 15:38:51 -07:00
  d692b74007
• Add openai_base_url config override for built-in provider (#12031)

  We regularly get bug reports from users who mistakenly have the
  `OPENAI_BASE_URL` environment variable set. This PR deprecates this
  environment variable in favor of a top-level config key
  `openai_base_url` that is used for the same purpose. By making it a
  config key, it will be more visible to users. It will also participate
  in all of the infrastructure we've added for layered and managed
  configs.
  
  Summary
  - introduce the `openai_base_url` top-level config key, update
  schema/tests, and route the built-in openai provider through it while
  - fall back to deprecated `OPENAI_BASE_URL` env var but warn user of
  deprecation when no `openai_base_url` config key is present
  - update CLI, SDK, and TUI code to prefer the new config path (with a
  deprecated env-var fallback) and document the SDK behavior change

  Eric Traut · 2026-03-13 20:12:25 -06:00
  4b9d5c8c1b
• Add plugin usage telemetry (#14531)

  adding metrics including: 
  * plugin used
  * plugin installed/uninstalled
  * plugin enabled/disabled

  alexsong-oai · 2026-03-12 19:22:30 -07:00
  1a363d5fcf
• [elicitation] User-friendly tool call messages. (#14403)

  - [x] Add a curated set of tool call messages and human-readable tool
  param names.

  Matthew Zeng · 2026-03-12 00:35:21 -07:00
  23e55d7668
• Let models opt into original image detail (#14175)

  ## Summary
  
  This PR narrows original image detail handling to a single opt-in
  feature:
  
  - `image_detail_original` lets the model request `detail: "original"` on
  supported models
  - Omitting `detail` preserves the default resized behavior
  
  The model only sees `detail: "original"` guidance when the active model
  supports it:
  
  - JS REPL instructions include the guidance and examples only on
  supported models
  - `view_image` only exposes a `detail` parameter when the feature and
  model can use it
  
  The image detail API is intentionally narrow and consistent across both
  paths:
  
  - `view_image.detail` supports only `"original"`; otherwise omit the
  field
  - `codex.emitImage(..., detail)` supports only `"original"`; otherwise
  omit the field
  - Unsupported explicit values fail clearly at the API boundary instead
  of being silently reinterpreted
  - Unsupported explicit `detail: "original"` requests fall back to normal
  behavior when the feature is disabled or the model does not support
  original detail

  Curtis 'Fjord' Hawthorne · 2026-03-11 15:25:07 -07:00
  8791f0ab9a
• add(core): arc_monitor (#13936)

  ## Summary
  - add ARC monitor support for MCP tool calls by serializing MCP approval
  requests into the ARC action shape and sending the relevant
  conversation/policy context to the `/api/codex/safety/arc` endpoint
  - route ARC outcomes back into MCP approval flow so `ask-user` falls
  back to a user prompt and `steer-model` blocks the tool call, with
  guardian/ARC tests covering the new request shape
  - update the TUI approval copy from “Approve Once” to “Allow” / “Allow
  for this session” and refresh the related
    snapshots
  
  ---------
  
  Co-authored-by: Fouad Matin <fouad@openai.com>
  Co-authored-by: Fouad Matin <169186268+fouad-openai@users.noreply.github.com>

  Matthew Zeng · 2026-03-11 12:33:08 -07:00
  f2d66fadd8
• chore: use @plugin instead of $plugin for plaintext mentions (#13921)

  change plaintext plugin-mentions from `$plugin` to `@plugin`, ensure TUI
  can correctly decode these from history.
  
  tested locally, added/updated tests.

  sayan-oai · 2026-03-08 01:36:39 +00:00
  590cfa6176
• Add guardian approval MVP (#13692)

  ## Summary
  - add the guardian reviewer flow for `on-request` approvals in command,
  patch, sandbox-retry, and managed-network approval paths
  - keep guardian behind `features.guardian_approval` instead of exposing
  a public `approval_policy = guardian` mode
  - route ordinary `OnRequest` approvals to the guardian subagent when the
  feature is enabled, without changing the public approval-mode surface
  
  ## Public model
  - public approval modes stay unchanged
  - guardian is enabled via `features.guardian_approval`
  - when that feature is on, `approval_policy = on-request` keeps the same
  approval boundaries but sends those approval requests to the guardian
  reviewer instead of the user
  - `/experimental` only persists the feature flag; it does not rewrite
  `approval_policy`
  - CLI and app-server no longer expose a separate `guardian` approval
  mode in this PR
  
  ## Guardian reviewer
  - the reviewer runs as a normal subagent and reuses the existing
  subagent/thread machinery
  - it is locked to a read-only sandbox and `approval_policy = never`
  - it does not inherit user/project exec-policy rules
  - it prefers `gpt-5.4` when the current provider exposes it, otherwise
  falls back to the parent turn's active model
  - it fail-closes on timeout, startup failure, malformed output, or any
  other review error
  - it currently auto-approves only when `risk_score < 80`
  
  ## Review context and policy
  - guardian mirrors `OnRequest` approval semantics rather than
  introducing a separate approval policy
  - explicit `require_escalated` requests follow the same approval surface
  as `OnRequest`; the difference is only who reviews them
  - managed-network allowlist misses that enter the approval flow are also
  reviewed by guardian
  - the review prompt includes bounded recent transcript history plus
  recent tool call/result evidence
  - transcript entries and planned-action strings are truncated with
  explicit `<guardian_truncated ... />` markers so large payloads stay
  bounded
  - apply-patch reviews include the full patch content (without
  duplicating the structured `changes` payload)
  - the guardian request layout is snapshot-tested using the same
  model-visible Responses request formatter used elsewhere in core
  
  ## Guardian network behavior
  - the guardian subagent inherits the parent session's managed-network
  allowlist when one exists, so it can use the same approved network
  surface while reviewing
  - exact session-scoped network approvals are copied into the guardian
  session with protocol/port scope preserved
  - those copied approvals are now seeded before the guardian's first turn
  is submitted, so inherited approvals are available during any immediate
  review-time checks
  
  ## Out of scope / follow-ups
  - the sandbox-permission validation split was pulled into a separate PR
  and is not part of this diff
  - a future follow-up can enable `serde_json` preserve-order in
  `codex-core` and then simplify the guardian action rendering further
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-07 05:40:10 -08:00
  e84ee33cc0
• app-server: Add streaming and tty/pty capabilities to command/exec (#13640)

  * Add an ability to stream stdin, stdout, and stderr
  * Streaming of stdout and stderr has a configurable cap for total amount
  of transmitted bytes (with an ability to disable it)
  * Add support for overriding environment variables
  * Add an ability to terminate running applications (using
  `command/exec/terminate`)
  * Add TTY/PTY support, with an ability to resize the terminal (using
  `command/exec/resize`)

  Ruslan Nigmatullin · 2026-03-06 17:30:17 -08:00
  e9bd8b20a1
• feat(otel, core): record turn TTFT and TTFM metrics in codex-core (#13630)

  ### Summary
  This adds turn-level latency metrics for the first model output and the
  first completed agent message.
  - `codex.turn.ttft.duration_ms` starts at turn start and records on the
  first output signal we see from the model. That includes normal
  assistant text, reasoning deltas, and non-text outputs like tool-call
  items.
  - `codex.turn.ttfm.duration_ms` also starts at turn start, but it
  records when the first agent message finishes streaming rather than when
  its first delta arrives.
  
  ### Implementation notes
  The timing is tracked in codex-core, not app-server, so the definition
  stays consistent across CLI, TUI, and app-server clients.
  
  I reused the existing turn lifecycle boundary that already drives
  `codex.turn.e2e_duration_ms`, stored the turn start timestamp in turn
  state, and record each metric once per turn.
  
  I also wired the new metric names into the OTEL runtime metrics summary
  so they show up in the same in-memory/debug snapshot path as the
  existing timing metrics.

  Owen Lin · 2026-03-06 10:23:48 -08:00
  3449e00bc9
• Refine realtime startup context formatting (#13560)

  ## Summary
  - group recent work by git repo when available, otherwise by directory
  - render recent work as bounded user asks with per-thread cwd context
  - exclude hidden files and directories from workspace trees

  Ahmed Ibrahim · 2026-03-05 16:31:20 -08:00
  6cf0ed4e79
• Remove Responses V1 websocket implementation (#13364)

  V2 is the way to go!

  pakrym-oai · 2026-03-03 11:32:53 -07:00
  69df12efb3
• app-server: Update thread/name/set to support not-loaded threads (#13282)

  Currently `thread/name/set` does only work for loaded threads.
  Expand the scope to also support persisted but not-yet-loaded ones for a
  more predictable API surface.
  This will make it possible to rename threads discovered via
  `thread/list` and similar operations.

  Ruslan Nigmatullin · 2026-03-02 15:13:18 -08:00
  14fcb6645c
• 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
• core: bundle settings diff updates into one dev/user envelope (#12417)

  ## Summary
  - bundle contextual prompt injection into at most one developer message
  plus one contextual user message in both:
    - per-turn settings updates
    - initial context insertion
  - preserve `<model_switch>` across compaction by rebuilding it through
  canonical initial-context injection, instead of relying on
  strip/reattach hacks
  - centralize contextual user fragment detection in one shared definition
  table and reuse it for parsing/compaction logic
  - keep `AGENTS.md` in its natural serialized format:
    - `# AGENTS.md instructions for {dirname}`
    - `<INSTRUCTIONS>...</INSTRUCTIONS>`
  - simplify related tests/helpers and accept the expected snapshot/layout
  updates from bundled multi-part messages
  
  ## Why
  The goal is to converge toward a simpler, more intentional prompt shape
  where contextual updates are consistently represented as one developer
  envelope plus one contextual user envelope, while keeping parsing and
  compaction behavior aligned with that representation.
  
  ## Notable details
  - the temporary `SettingsUpdateEnvelope` wrapper was removed; these
  paths now return `Vec<ResponseItem>` directly
  - local/remote compaction no longer rely on model-switch strip/restore
  helpers
  - contextual user detection is now driven by shared fragment definitions
  instead of ad hoc matcher assembly
  - AGENTS/user instructions are still the same logical context; only the
  synthetic `<user_instructions>` wrapper was replaced by the natural
  AGENTS text format
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-app-server
  codex_message_processor::tests::extract_conversation_summary_prefers_plain_user_messages
  -- --exact`
  - `cargo test -p codex-core
  compact::tests::collect_user_messages_filters_session_prefix_entries
  --lib -- --exact`
  - `cargo test -p codex-core --test all
  'suite::compact::snapshot_request_shape_pre_turn_compaction_strips_incoming_model_switch'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::compact_remote::snapshot_request_shape_remote_pre_turn_compaction_strips_incoming_model_switch'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_apps_guidance_as_developer_message_when_enabled'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_developer_instructions_message_in_request' --
  --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_user_instructions_message_in_request' --
  --exact`
  - `cargo test -p codex-core --test all
  'suite::client::resume_includes_initial_messages_and_sends_prior_items'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::review::review_input_isolated_from_parent_history' -- --exact`
  - `cargo test -p codex-exec --test all
  'suite::resume::exec_resume_last_respects_cwd_filter_and_all_flag' --
  --exact`
  - `cargo test -p core_test_support
  context_snapshot::tests::full_text_mode_preserves_unredacted_text --
  --exact`
  
  ## Notes
  - I also ran several targeted `compact`, `compact_remote`,
  `prompt_caching`, `model_visible_layout`, and `event_mapping` tests
  while iterating on prompt-shape changes.
  - I have not claimed a clean full-workspace `cargo test` from this
  environment because local sandbox/resource conditions have previously
  produced unrelated failures in large workspace runs.

  Charley Cunningham · 2026-02-26 00:12:08 -08:00
  07aefffb1f
• feat: adding stream parser (#12666)

  Add a stream parser to extract citations (and others) from a stream.
  This support cases where markers are split in differen tokens.
  
  Codex never manage to make this code work so everything was done
  manually. Please review correctly and do not touch this part of the code
  without a very clear understanding of it

  jif-oai · 2026-02-25 13:27:58 +00:00
  5441130e0a
• Support external agent config detect and import (#12660)

  Migration Behavior
  
  * Config
    *  Migrates settings.json into config.toml
  * Only adds fields when config.toml is missing, or when those fields are
  missing from the existing file
    *  Supported mappings:
      env -> shell_environment_policy
       sandbox.enabled = true -> sandbox_mode = "workspace-write"
  
  * Skills
    *  Copies home and repo .claude/skills into .agents/skills
    *  Existing skill directories are not overwritten
    *  SKILL.md content is rewritten from Claude-related terms to Codex
  
  * AgentsMd
    *  Repo only
    *  Migrates CLAUDE.md into AGENTS.md
  * Detect/import only proceed when AGENTS.md is missing or present but
  empty
    *  Content is rewritten from Claude-related terms to Codex

  alexsong-oai · 2026-02-25 02:11:51 -08:00
  6d6570d89d
• 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
• Prefer v2 websockets if available (#12428)

  And also cleanup settings flow to avoid reading many separate flags.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-02-21 20:08:04 +00:00
  b17148f13a
• 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
• chore: remove codex-core public protocol/shell re-exports (#12432)

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

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• Wire realtime api to core (#12268)

  - Introduce `RealtimeConversationManager` for realtime API management 
  - Add `op::conversation` to start conversation, insert audio, insert
  text, and close conversation.
  - emit conversation lifecycle and realtime events.
  - Move shared realtime payload types into codex-protocol and add core
  e2e websocket tests for start/replace/transport-close paths.
  
  Things to consider:
  - Should we use the same `op::` and `Events` channel to carry audio? I
  think we should try this simple approach and later we can create
  separate one if the channels got congested.
  - Sending text updates to the client: we can start simple and later
  restrict that.
  - Provider auth isn't wired for now intentionally

  Ahmed Ibrahim · 2026-02-20 19:06:35 -08:00
  6817f0be8a
• 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
• Use prompt-based co-author attribution with config override (#11617)
  gabec-openai · 2026-02-17 20:15:54 +00:00
  5341ad08f8
• 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
• Report syntax errors in rules file (#11686)

  Currently, if there are syntax errors detected in the starlark rules
  file, the entire policy is silently ignored by the CLI. The app server
  correctly emits a message that can be displayed in a GUI.
  
  This PR changes the CLI (both the TUI and non-interactive exec) to fail
  when the rules file can't be parsed. It then prints out an error message
  and exits with a non-zero exit code. This is consistent with the
  handling of errors in the config file.
  
  This addresses #11603

  Eric Traut · 2026-02-13 10:33:40 -08:00
  b98c810328
• [feat] add seatbelt permission files (#11639)

  Add seatbelt permission extension abstraction as permission files for
  seatbelt profiles. This should complement our current sandbox policy

  Celia Chen · 2026-02-12 23:30:22 +00:00
  dfd1e199a0
• add a slash command to grant sandbox read access to inaccessible directories (#11512)

  There is an edge case where a directory is not readable by the sandbox.
  In practice, we've seen very little of it, but it can happen so this
  slash command unlocks users when it does.
  
  Future idea is to make this a tool that the agent knows about so it can
  be more integrated.

  iceweasel-oai · 2026-02-12 12:48:36 -08:00
  5c3ca73914
• feat(app-server): experimental flag to persist extended history (#11227)

  This PR adds an experimental `persist_extended_history` bool flag to
  app-server thread APIs so rollout logs can retain a richer set of
  EventMsgs for non-lossy Thread > Turn > ThreadItems reconstruction (i.e.
  on `thread/resume`).
  
  ### Motivation
  Today, our rollout recorder only persists a small subset (e.g. user
  message, reasoning, assistant message) of `EventMsg` types, dropping a
  good number (like command exec, file change, etc.) that are important
  for reconstructing full item history for `thread/resume`, `thread/read`,
  and `thread/fork`.
  
  Some clients want to be able to resume a thread without lossiness. This
  lossiness is primarily a UI thing, since what the model sees are
  `ResponseItem` and not `EventMsg`.
  
  ### Approach
  This change introduces an opt-in `persist_full_history` flag to preserve
  those events when you start/resume/fork a thread (defaults to `false`).
  
  This is done by adding an `EventPersistenceMode` to the rollout
  recorder:
  - `Limited` (existing behavior, default)
  - `Extended` (new opt-in behavior)
  
  In `Extended` mode, persist additional `EventMsg` variants needed for
  non-lossy app-server `ThreadItem` reconstruction. We now store the
  following ThreadItems that we didn't before:
  - web search
  - command execution
  - patch/file changes
  - MCP tool calls
  - image view calls
  - collab tool outcomes
  - context compaction
  - review mode enter/exit
  
  For **command executions** in particular, we truncate the output using
  the existing `truncate_text` from core to store an upper bound of 10,000
  bytes, which is also the default value for truncating tool outputs shown
  to the model. This keeps the size of the rollout file and command
  execution items returned over the wire reasonable.
  
  And we also persist `EventMsg::Error` which we can now map back to the
  Turn's status and populates the Turn's error metadata.
  
  #### Updates to EventMsgs
  To truly make `thread/resume` non-lossy, we also needed to persist the
  `status` on `EventMsg::CommandExecutionEndEvent` and
  `EventMsg::PatchApplyEndEvent`. Previously it was not obvious whether a
  command failed or was declined (similar for apply_patch). These
  EventMsgs were never persisted before so I made it a required field.

  Owen Lin · 2026-02-12 19:34:22 +00:00
  efc8d45750
• Remove test-support feature from codex-core and replace it with explicit test toggles (#11405)

  ## Why
  
  `codex-core` was being built in multiple feature-resolved permutations
  because test-only behavior was modeled as crate features. For a large
  crate, those permutations increase compile cost and reduce cache reuse.
  
  ## Net Change
  
  - Removed the `test-support` crate feature and related feature wiring so
  `codex-core` no longer needs separate feature shapes for test consumers.
  - Standardized cross-crate test-only access behind
  `codex_core::test_support`.
  - External test code now imports helpers from
  `codex_core::test_support`.
  - Underlying implementation hooks are kept internal (`pub(crate)`)
  instead of broadly public.
  
  ## Outcome
  
  - Fewer `codex-core` build permutations.
  - Better incremental cache reuse across test targets.
  - No intended production behavior change.

  Michael Bolin · 2026-02-10 22:44:02 -08:00
  476c1a7160
• Remove deterministic_process_ids feature to avoid duplicate codex-core builds (#11393)

  ## Why
  
  `codex-core` enabled `deterministic_process_ids` through a self
  dev-dependency.
  That forced a second feature-resolved build of the same crate, which
  increased
  compile time and test latency.
  
  ## What Changed
  
  - Removed the `deterministic_process_ids` feature from
  `codex-rs/core/Cargo.toml`.
  - Removed the self dev-dependency on `codex-core` that enabled that
  feature.
  - Removed the Bazel `deterministic_process_ids` crate feature for
  `codex-core`.
  - Added a test-only `AtomicBool` override in unified exec process-id
  allocation.
  - Added a test-support setter for that override and re-exported it from
  `codex-core`.
  - Enabled deterministic process IDs in integration tests via
  `core_test_support` ctor.
  
  ## Behavior
  
  - Production behavior remains random process IDs.
  - Unit tests remain deterministic via `cfg(test)`.
  - Integration tests remain deterministic via explicit test-support
  initialization.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core unified_exec::`
  - `cargo test -p codex-core --test all unified_exec -- --test-threads=1`
  - `cargo tree -p codex-core -e features` (verified the removed feature
  path)

  Michael Bolin · 2026-02-10 19:07:01 -08:00
  b68a84ee8e
• chore: rename codex-command to codex-shell-command (#11378)

  This addresses some post-merge feedback on
  https://github.com/openai/codex/pull/11361:
  
  - crate rename
  - reuse `detect_shell_type()` utility

  Michael Bolin · 2026-02-10 17:03:46 -08:00
  d44f4205fb
• # Split command parsing/safety out of codex-core into new codex-command (#11361)

  `codex-core` had accumulated command parsing and command safety logic
  (`bash`, `powershell`, `parse_command`, and `command_safety`) that is
  logically cohesive but orthogonal to most core session/runtime logic.
  Keeping this code in `codex-core` made the crate increasingly monolithic
  and raised iteration cost for unrelated core changes.
  
  This change extracts that surface into a dedicated crate,
  `codex-command`, while preserving existing `codex_core::...` call sites
  via re-exports.
  
  ## Why this refactor
  
  During analysis, command parsing/safety stood out as a good first split
  because it has:
  
  - a clear domain boundary (shell parsing + safety classification)
  - relatively self-contained dependencies (notably `tree-sitter` /
  `tree-sitter-bash`)
  - a meaningful standalone test surface (`134` tests moved with the
  crate)
  - many downstream uses that benefit from independent compilation and
  caching
  
  The practical problem was build latency from a large `codex-core`
  compile/test graph. Clean-build timings before and after this split
  showed measurable wins:
  
  - `cargo check -p codex-core`: `57.08s` -> `53.54s` (~`6.2%` faster)
  - `cargo test -p codex-core --no-run`: `2m39.9s` -> `2m20s` (~`12.4%`
  faster)
  - `codex-core lib` compile unit: `57.18s` -> `49.67s` (~`13.1%` faster)
  - `codex-core lib(test)` compile unit: `60.87s` -> `53.21s` (~`12.6%`
  faster)
  
  This gives a concrete reduction in core build overhead without changing
  behavior.
  
  ## What changed
  
  ### New crate
  
  - Added `codex-rs/command` as workspace crate `codex-command`.
  - Added:
    - `command/src/lib.rs`
    - `command/src/bash.rs`
    - `command/src/powershell.rs`
    - `command/src/parse_command.rs`
    - `command/src/command_safety/*`
    - `command/src/shell_detect.rs`
    - `command/BUILD.bazel`
  
  ### Code moved out of `codex-core`
  
  - Moved modules from `core/src` into `command/src`:
    - `bash.rs`
    - `powershell.rs`
    - `parse_command.rs`
    - `command_safety/*`
  
  ### Dependency graph updates
  
  - Added workspace member/dependency entries for `codex-command` in
  `codex-rs/Cargo.toml`.
  - Added `codex-command` dependency to `codex-rs/core/Cargo.toml`.
  - Removed `tree-sitter` and `tree-sitter-bash` from `codex-core` direct
  deps (now owned by `codex-command`).
  
  ### API compatibility for callers
  
  To avoid immediate downstream churn, `codex-core` now re-exports the
  moved modules/functions:
  
  - `codex_command::bash`
  - `codex_command::powershell`
  - `codex_command::parse_command`
  - `codex_command::is_safe_command`
  - `codex_command::is_dangerous_command`
  
  This keeps existing `codex_core::...` paths working while enabling
  gradual migration to direct `codex-command` usage.
  
  ### Internal decoupling detail
  
  - Added `command::shell_detect` so moved `bash`/`powershell` logic no
  longer depends on core shell internals.
  - Adjusted PowerShell helper visibility in `codex-command` for existing
  core test usage (`UTF8` prefix helper + executable discovery functions).
  
  ## Validation
  
  - `just fmt`
  - `just fix -p codex-command -p codex-core`
  - `cargo test -p codex-command` (`134` passed)
  - `cargo test -p codex-core --no-run`
  - `cargo test -p codex-core shell_command_handler`
  
  ## Notes / follow-up
  
  This commit intentionally prioritizes boundary extraction and
  compatibility. A follow-up can migrate downstream crates to depend
  directly on `codex-command` (instead of through `codex-core` re-exports)
  to realize additional incremental build wins.

  Michael Bolin · 2026-02-10 14:43:16 -08:00
  d8f9bb65e2
• include sandbox (seatbelt, elevated, etc.) as in turn metadata header (#10946)

  This will help us understand retention/usage for folks who use the
  Windows (or any other) sandboxes

  iceweasel-oai · 2026-02-10 19:50:07 +00:00
  82f93a13b2
• fix(core): canonicalize wrapper approvals and support heredoc prefix … (#10941)

  ## Summary
  - Reduced repeated approvals for equivalent wrapper commands and fixed
  execpolicy matching for heredoc-style shell invocations, with minimal
  behavior change and fail-closed defaults.
  
  ## Fixes
  1. Canonicalized approval matching for wrappers so equivalent commands
  map to the same approval intent.
  2. Added heredoc-aware prefix extraction for execpolicy so commands like
  `python3 <<'PY' ... PY` match rules such as `prefix_rule(["python3"],
  ...)`.
  3. Kept fallback behavior conservative: if parsing is ambiguous,
  existing prompt behavior is preserved.
  
  ## Edge Cases Covered
  - Wrapper path/name differences: `/bin/bash` vs `bash`, `/bin/zsh` vs
  `zsh`.
  - Shell modes: `-c` and `-lc`.
  - Heredoc forms: quoted delimiter (`<<'PY'`) and unquoted delimiter (`<<
  PY`).
  - Multi-command heredoc scripts are rejected by the fallback
  - Non-heredoc redirections (`>`, etc.) are not treated as heredoc prefix
  matches.
  - Complex scripts still fall back to prior behavior rather than
  expanding permissions.
  
  ---------
  
  Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>

  viyatb-oai · 2026-02-10 11:46:40 -08:00
  62d0f302fd
• 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
• memories: add extraction and prompt module foundation (#11200)

  ## Summary
  - add the new `core/src/memories` module (phase-one parsing, rollout
  filtering, storage, selection, prompts)
  - add Askama-backed memory templates for stage-one input/system and
  consolidation prompts
  - add module tests for parsing, filtering, path bucketing, and summary
  maintenance
  
  ## Testing
  - just fmt
  - cargo test -p codex-core --lib memories::

  jif-oai · 2026-02-10 10:10:24 +00:00
  6049ff02a0
• [apps] Add gated instructions for Apps. (#10924)

  - [x] Add gated instructions for Apps.

  Matthew Zeng · 2026-02-09 14:48:09 -08:00
  d90df4761b
• chore: reverse the codex-network-proxy -> codex-core dependency (#11121)
  Michael Bolin · 2026-02-08 17:03:24 -08:00
  ff74aaae21
• feat(app-server): turn/steer API (#10821)

  This PR adds a dedicated `turn/steer` API for appending user input to an
  in-flight turn.
  
  ## Motivation
  Currently, steering in the app is implemented by just calling
  `turn/start` while a turn is running. This has some really weird quirks:
  - Client gets back a new `turn.id`, even though streamed
  events/approvals remained tied to the original active turn ID.
  - All the various turn-level override params on `turn/start` do not
  apply to the "steer", and would only apply to the next real turn.
  - There can also be a race condition where the client thinks the turn is
  active but the server has already completed it, so there might be bugs
  if the client has baked in some client-specific behavior thinking it's a
  steer when in fact the server kicked off a new turn. This is
  particularly possible when running a client against a remote app-server.
  
  Having a dedicated `turn/steer` API eliminates all those quirks.
  
  `turn/steer` behavior:
  - Requires an active turn on threadId. Returns a JSON-RPC error if there
  is no active turn.
  - If expectedTurnId is provided, it must match the active turn (more
  useful when connecting to a remote app-server).
  - Does not emit `turn/started`.
  - Does not accept turn overrides (`cwd`, `model`, `sandbox`, etc.) or
  `outputSchema` to accurately reflect that these are not applied when
  steering.

  Owen Lin · 2026-02-06 00:35:04 +00:00
  0d8b2b74c4
• chore: rm web-search-eligible header (#10660)

  default-enablement of web_search is now client-side, no need to send
  eligibility headers to backend.
  
  Tested locally, headers no longer sent.
  
  will wait for corresponding backend change to deploy before merging

  sayan-oai · 2026-02-05 11:48:34 -08:00
  5fdf6f5efa
• 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
• adding fork information (UI) when forking (#10246)

  - shows `/fork` command that ran in prev session
  - shows `session forked from name (uuid) || uuid (if name is not set)` as an event in new session

  pap-openai · 2026-02-05 13:24:55 +00:00
  b2424cb635
• 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