Commit Graph

63 Commits

  • Support Codex Apps auth elicitations (#19193)
    ## Summary
    
    - request URL-mode MCP elicitations when Codex Apps tool calls fail with
    connector auth metadata
    - route Codex Apps auth URL elicitations into the TUI app-link flow
    
    ## Test plan
    
    - `just fmt`
    - `cargo test -p codex-core mcp_tool_call::tests`
    - `cargo test -p codex-mcp`
    - `cargo test -p codex-tui bottom_pane::app_link_view::tests`
    - `just fix -p codex-core`
    - `just fix -p codex-mcp`
    - `just fix -p codex-tui`
    
    Also attempted broader local runs:
    
    - `cargo test -p codex-core` fails in unrelated
    config/request-permission/proxy-sensitive tests under the current Codex
    Desktop environment.
    - `cargo test -p codex-tui` fails in unrelated status
    snapshots/trust-default tests because the ambient environment renders
    workspace-write/network permission defaults.
  • feat: add remote compaction v2 Responses client path (#20773)
    ## Why
    
    This adds the `remote_compaction_v2` client path so remote compaction
    can run through the normal Responses stream and install a
    `context_compaction` item that trigger a compaction.
    
    The goal is to migrate some of the compaction logic on the client side
    
    We keeps the v2 transport behind a feature flag while letting follow-up
    requests reuse the compacted context instead of falling back to the
    legacy compaction item shape.
    
    ## What changed
    
    - add `ResponseItem::ContextCompaction` and refresh the generated
    app-server / schema / TypeScript fixtures that expose response items on
    the wire
    - add `core/src/compact_remote_v2.rs` to send compaction through the
    standard streamed Responses client, require exactly one
    `context_compaction` output item, and install that item into compacted
    history
    - route manual compact and auto-compaction through the v2 path when
    `remote_compaction_v2` is enabled, while keeping the existing remote
    compaction path as the fallback
    - preserve the new item type across history retention, follow-up request
    construction, telemetry, rollout persistence, and rollout-trace
    normalization
    - add targeted coverage for the feature flag, `context_compaction`
    serialization, rollout-trace normalization, and remote-compaction
    follow-up behavior
    
    ## Verification
    
    - added protocol tests for `context_compaction`
    serialization/deserialization in `protocol/src/models.rs`
    - added rollout-trace coverage for `context_compaction` normalization in
    `rollout-trace/src/reducer/conversation_tests.rs`
    - added remote compaction integration coverage for v2 follow-up reuse
    and mixed compaction output streams in
    `core/tests/suite/compact_remote.rs`
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • feat: export and replay effective config locks (#20405)
    ## Why
    
    For reproducibility. A hand-written `config.toml` is not enough to
    recreate what a Codex session actually ran with because layered config,
    CLI overrides, defaults, feature aliases, resolved feature config,
    prompt setup, and model-catalog/session values can all affect the final
    runtime behavior.
    
    This PR adds an effective config lockfile path: one run can export the
    resolved session config, and a later run can replay that lockfile and
    fail early if the regenerated effective config drifts.
    
    ## What Changed
    
    - Add a dedicated `ConfigLockfileToml` wrapper with top-level lockfile
    metadata plus the replayable config:
    
      ```toml
      version = 1
      codex_version = "..."
    
      [config]
      # effective ConfigToml fields
      ```
    
    - Keep lockfile metadata out of regular `ConfigToml`; replay loads
    `ConfigLockfileToml` and then uses its nested `config` as the
    authoritative config layer.
    - Add `debug.config_lockfile.export_dir` to write
    `<thread_id>.config.lock.toml` when a root session starts.
    - Add `debug.config_lockfile.load_path` to replay a saved lockfile and
    validate the regenerated session lockfile against it.
    - Add `debug.config_lockfile.allow_codex_version_mismatch` to optionally
    tolerate Codex binary version drift while still comparing the rest of
    the lockfile.
    - Add `debug.config_lockfile.save_fields_resolved_from_model_catalog` so
    lock creation can either save model-catalog/session-resolved fields or
    intentionally leave those fields dynamic.
    - Build lockfiles from the effective config plus resolved runtime values
    such as model selection, reasoning settings, prompts, service tier, web
    search mode, feature states/config, memories config, skill instructions,
    and agent limits.
    - Materialize feature aliases and custom feature config into the
    lockfile so replay compares canonical resolved behavior instead of
    user-authored alias shape.
    - Strip profile/debug/file-include/environment-specific inputs from
    generated lockfiles so they contain replayable values rather than the
    inputs that produced those values.
    - Surface JSON-RPC server error code/data in app-server client and TUI
    bootstrap errors so config-lock replay failures include the actual TOML
    diff.
    - Regenerate the config schema for the new debug config keys.
    
    ## Review Notes
    
    The main flow is split across these files:
    
    - `config/src/config_toml.rs`: lockfile/debug TOML shapes.
    - `core/src/config/mod.rs`: loading `debug.config_lockfile.*`, replaying
    a lockfile as a config layer, and preserving the expected lockfile for
    validation.
    - `core/src/session/config_lock.rs`: exporting the current session
    lockfile and materializing resolved session/config values.
    - `core/src/config_lock.rs`: lockfile parsing, metadata/version checks,
    replay comparison, and diff formatting.
    
    ## Usage
    
    Export a lockfile from a normal session:
    
    ```sh
    codex -c 'debug.config_lockfile.export_dir="/tmp/codex-locks"'
    ```
    
    Export a lockfile without saving model-catalog/session-resolved fields:
    
    ```sh
    codex -c 'debug.config_lockfile.export_dir="/tmp/codex-locks"' \
      -c 'debug.config_lockfile.save_fields_resolved_from_model_catalog=false'
    ```
    
    Replay a saved lockfile in a later session:
    
    ```sh
    codex -c 'debug.config_lockfile.load_path="/tmp/codex-locks/<thread_id>.config.lock.toml"'
    ```
    
    If replay resolves to a different effective config, startup fails with a
    TOML diff.
    
    To tolerate Codex binary version drift during replay:
    
    ```sh
    codex -c 'debug.config_lockfile.load_path="/tmp/codex-locks/<thread_id>.config.lock.toml"' \
      -c 'debug.config_lockfile.allow_codex_version_mismatch=true'
    ```
    
    ## Limitations
    
    This does not support custom rules/network policies.
    
    ## Verification
    
    - `cargo test -p codex-core config_lock`
    - `cargo test -p codex-config`
    - `cargo test -p codex-thread-manager-sample`
  • Alias codex_hooks feature as hooks (#20522)
    # Why
    
    The hooks feature flag should use the concise canonical name `hooks`,
    while existing configs that still use `codex_hooks` continue to work
    during the rename.
    
    # What
    
    - change the canonical `Feature::CodexHooks` key from `codex_hooks` to
    `hooks`
    - register `codex_hooks` through the existing legacy-alias path
    - update the config schema and canonical config fixtures to prefer
    `hooks`
    - add regression coverage that both `hooks` and `codex_hooks` resolve to
    `Feature::CodexHooks`
    
    # Verification
    
    - `cargo test -p codex-features`
    - `cargo test -p codex-core config::schema_tests`
    - `cargo test -p codex-core
    pre_tool_use_blocks_shell_when_defined_in_config_toml`
    - `cargo test -p codex-app-server
    hooks_list_uses_each_cwds_effective_feature_enablement`
  • [Codex] Add browser use external feature flag (#20245)
    ## Summary
    
    - Adds a separate feature control for external-browser Browser Use
    integrations.
    - Registers `browser_use_external` as a stable, default-enabled
    requirements-owned feature key.
    - Updates feature registry tests and regenerates the config schema.
    
    Codex validation:
    - `cargo fmt -- --config imports_granularity=Item`
    - `cargo run -p codex-core --bin codex-write-config-schema`
    - `cargo test -p codex-features`
    
    ## Addendum
    
    This gives enterprise policy a coarse control for Browser Use outside
    the Codex-managed in-app browser. The existing `browser_use` feature is
    the Browser Use control, while `browser_use_external` can gate
    extension/native integrations for external browsers as that surface
    grows
  • Mark goals feature as experimental (#20083)
    ## Why
    
    The `goals` feature flag is ready to move out of the hidden
    under-development bucket and into the user-facing experimental surface.
    Marking it experimental lets users discover it through the experimental
    features UI while still making clear that it is opt-in.
    
    ## What changed
    
    - Changed `goals` from `Stage::UnderDevelopment` to
    `Stage::Experimental` in `codex-rs/features/src/lib.rs`.
    - Added experimental menu metadata for the feature with the description
    `Set a persistent goal Codex can continue over time`.
    
    ## Verification
    
    - `cargo test -p codex-features`
  • [apps] Add apps MCP path override (#20231)
    Summary
    
    - Add `[features.apps_mcp_path_override]` config with a `path` field for
    overriding only the built-in apps MCP path.
    - Keep existing host/base URL derivation unchanged and append the
    configured path after that base.
    - Regenerate the config schema with the custom feature-config case.
    
    Test Plan
    
    - Not run for latest revision; only `just fmt` and `just
    write-config-schema` were run.
    - Earlier revision: `cargo test -p codex-features`
    - Earlier revision: `cargo test -p codex-mcp`
  • Discover hooks bundled with plugins (#19705)
    ## Why
    
    Plugins can bundle lifecycle hooks, but Codex previously only discovered
    hooks from user, project, and managed config layers. This adds the
    plugin discovery and runtime plumbing needed for plugin-bundled hooks
    while keeping execution behind the `plugin_hooks` feature flag.
    
    ## What
    
    - Discovers plugin hook sources from each plugin's default
    `hooks/hooks.json`.
    - Supports `plugin.json` manifest `hooks` entries as either relative
    paths or inline hook objects.
    - Plumbs discovered plugin hook sources through plugin loading into the
    hook runtime when `plugin_hooks` is enabled.
    - Marks plugin-originated hook runs as `HookSource::Plugin`.
    - Injects `PLUGIN_ROOT` and `CLAUDE_PLUGIN_ROOT` into plugin hook
    command environments.
    - Updates generated schemas and hook source metadata for the plugin hook
    source.
    
    ## Stack
    
    1. This PR - openai/codex#19705
    2. openai/codex#19778
    3. openai/codex#19840
    4. openai/codex#19882
    
    ## Reviewer Notes
    
    - Core logic is in `codex-rs/core-plugins/src/loader.rs` and
    `codex-rs/hooks/src/engine/discovery.rs`
    - Moved existing / adding new tests to
    `codex-rs/core-plugins/src/loader_tests.rs` hence the large diff there
    - Otherwise mostly plumbing and minor schema updates
    
    ### Core Changes
    
    The `codex-rs/core` changes are limited to wiring plugin hook support
    into existing core flows:
    
    - `core/src/session/session.rs` conditionally pulls effective plugin
    hook sources and plugin hook load warnings from `PluginsManager` when
    `plugin_hooks` is enabled, then passes them into `HooksConfig`.
    - `core/src/hook_runtime.rs` adds the `plugin` metric tag for
    `HookSource::Plugin`.
    - `core/config.schema.json` picks up the new `plugin_hooks` feature
    flag, and `core/src/plugins/manager_tests.rs` updates fixtures for the
    added plugin hook fields.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Make MultiAgentV2 wait minimum configurable (#20052)
    ## Why
    
    MultiAgentV2 `wait_agent` currently clamps short waits to a fixed 10
    second minimum. That default is still useful for preventing tight
    polling loops, but it is too rigid for environments that need faster
    mailbox wake-up checks or a larger minimum to discourage frequent
    polling.
    
    This PR makes the minimum wait timeout configurable from the existing
    MultiAgentV2 feature config section, so operators can tune the behavior
    without changing the legacy multi-agent tool surface.
    
    ## What Changed
    
    - Added `features.multi_agent_v2.min_wait_timeout_ms`.
    - Defaulted the new setting to the existing 10 second floor.
    - Validated the configured value as `1..=3600000`, matching the existing
    one hour maximum wait bound.
    - Applied the configured minimum to MultiAgentV2 `wait_agent` runtime
    clamping.
    - Plumbed the configured minimum into the `wait_agent` tool schema,
    including the effective default when the minimum is above the normal 30
    second default.
    - Regenerated `core/config.schema.json`.
    
    ## Verification
    
    - `cargo test -p codex-features`
    - `cargo test -p codex-tools`
    - `cargo test -p codex-core --lib multi_agent_v2`
    - `just fix -p codex-core`
  • Add MultiAgentV2 root and subagent context hints (#19805)
    ## Why
    
    MultiAgentV2 sessions need startup guidance that matches the role of the
    thread that is actually being created. Root agents and subagents have
    different responsibilities, and forked subagents can inherit parent
    rollout history. If the parent hint is carried into the child context,
    the child can see stale or conflicting developer guidance before its own
    session-specific context is added.
    
    ## What changed
    
    - Added `features.multi_agent_v2.root_agent_usage_hint_text` and
    `features.multi_agent_v2.subagent_usage_hint_text` config fields,
    including schema/config parsing support.
    - Injected the matching root or subagent hint into the initial context
    as its own developer message when `multi_agent_v2` is enabled.
    - Filtered configured MultiAgentV2 usage-hint developer messages out of
    forked parent history so a child thread receives fresh guidance for its
    own session source/config.
    - Added targeted coverage for config parsing, initial-context rendering,
    feature-config deserialization, and forked-history filtering.
    
    ## Context examples
    
    With this config:
    
    ```toml
    [features.multi_agent_v2]
    enabled = true
    root_agent_usage_hint_text = "Root guidance."
    subagent_usage_hint_text = "Subagent guidance."
    ```
    
    A root thread initial context renders the root hint as a standalone
    developer message:
    
    ```text
    [developer]
    <existing developer context, when present>
    
    [developer]
    Root guidance.
    ```
    
    A subagent thread initial context renders the subagent hint instead:
    
    ```text
    [developer]
    <existing developer context, when present>
    
    [developer]
    Subagent guidance.
    ```
    
    When a subagent forks parent history, any parent developer message whose
    text exactly matches the configured MultiAgentV2 root or subagent hint
    is omitted from the forked history before the child receives its fresh
    subagent hint.
  • Remove ghost snapshots (#19481)
    ## Summary
    - Remove `ghost_snapshot` / `GhostCommit` from the Responses API surface
    and generated SDK/schema artifacts.
    - Keep legacy config loading compatible, but make undo a no-op that
    reports the feature is unavailable.
    - Clean up core history, compaction, telemetry, rollout, and tests to
    stop carrying ghost snapshot items.
    
    ## Testing
    - Unit tests passed for `codex-protocol`, `codex-core` targeted undo and
    compaction flows, `codex-rollout`, and `codex-app-server-protocol`.
    - Regenerated config and app-server schemas plus Python SDK artifacts
    and verified they match the checked-in outputs.
  • Add MCP app feature flag (#19884)
    ## Summary
    - Add the `enable_mcp_apps` feature flag to the `codex-features`
    registry
    - Keep it under development and disabled by default
    
    ## Testing
    - Unit tests for `codex-features` passed
    - Formatting passed
  • multi_agent_v2: move thread cap into feature config (#19792)
    ## Why
    
    `features.multi_agent_v2.max_concurrent_threads_per_session` is meant to
    be the MultiAgentV2-specific session thread cap: it counts the root
    thread and all open subagent threads. The previous implementation kept
    this surface tied to `agents.max_threads`, which made it a global
    subagent-only cap and allowed the legacy setting to coexist with
    MultiAgentV2.
    
    ## What Changed
    
    - Added `max_concurrent_threads_per_session` to
    `[features.multi_agent_v2]` with default `4`.
    - Removed the `[agents] max_concurrent_threads_per_session` alias to
    `agents.max_threads`.
    - When MultiAgentV2 is enabled, reject `agents.max_threads` and derive
    the existing internal subagent slot limit as
    `max_concurrent_threads_per_session - 1`.
    - Regenerated `core/config.schema.json` and added coverage for the new
    config semantics.
    
    ## Result
    ```
    ➜  codex git:(jif/clean-multi-agent-v2-config) codex -c features.multi_agent_v2.enabled=true -c features.multi_agent_v2.max_concurrent_threads_per_session=3
    ╭────────────────────────────────────────────────────╮
    │ >_ OpenAI Codex (v0.0.0)                           │
    │                                                    │
    │ model:     gpt-5.5 xhigh   fast   /model to change │
    │ directory: ~/code/codex                            │
    ╰────────────────────────────────────────────────────╯
    
      Tip: Update Required - This version will no longer be supported starting May 8th. Please upgrade to the latest version (https://github.com/openai/codex/releases/latest) using your preferred package manager.
    
    › Can you try to spawn 4 agents
    
    
    • I’ll try to start four lightweight agents at once and report exactly what the runtime accepts.
    
    • Spawned Russell [no-apps] (gpt-5.5 xhigh)
      └ Spawn probe 1: reply briefly that you started, then wait for further instructions. Do not do any repo work.
    
    • Spawned Descartes [no-apps] (gpt-5.5 xhigh)
      └ Spawn probe 2: reply briefly that you started, then wait for further instructions. Do not do any repo work.
    
    • Agent spawn failed
      └ Spawn probe 3: reply briefly that you started, then wait for further instructions. Do not do any repo work.
    
    • Agent spawn failed
      └ Spawn probe 4: reply briefly that you started, then wait for further instructions. Do not do any repo work.
    
    • The runtime accepted the first two and rejected the next two with agent thread limit reached. I’m checking whether the two accepted probes have returned cleanly, then I’ll close them if needed.
    ```
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • fix(tui): reflow scrollback on terminal resize (#18575)
    Fixes multiple scrollback and terminal resize issues: #5538, #5576,
    #8352, #12223, #16165, and #15380.
    
    ## Why
    
    Codex writes finalized transcript output into terminal scrollback after
    wrapping it for the current viewport width. A later terminal resize
    could leave that scrollback shaped for the old width, so wider windows
    kept narrow output and narrower windows could show stale wrapping
    artifacts until enough new output replaced the visible area.
    
    This is also the foundation PR for responsive markdown tables. Table
    rendering needs finalized transcript content to be width-sensitive after
    insertion, not only while content is first streaming. Markdown table
    rendering itself stays in #18576.
    
    ## Stack
    
    - PR1: resize backlog reflow and interrupt cleanup
    - #18576: markdown table support
    
    ## What Changed
    
    - Rebuild source-backed transcript history when the terminal width
    changes. `terminal_resize_reflow` is introduced through the experimental
    feature system, but is enabled by default for this rollout so we can
    validate behavior across real terminals.
    - Preserve assistant and plan stream source so finalized streaming
    output can participate in resize reflow after consolidation.
    - Debounce resize work, but force a final source-backed reflow when a
    resize happened during active or unconsolidated streaming output.
    - Clear stale pending history lines on resize so old-width wrapped
    output is not emitted just before rebuilt scrollback.
    - Bound replay work with `[tui.terminal_resize_reflow].max_rows`:
    omitted uses terminal-specific defaults, `0` keeps all rendered rows,
    and a positive value sets an explicit cap. The cap applies both while
    initially replaying a resumed transcript into scrollback and when
    rebuilding scrollback after terminal resize.
    - Consolidate interrupted assistant streams before cleanup, then clear
    pending stream output and active-tail state consistently.
    - Move resize reflow and thread event buffering helpers out of `app.rs`
    into dedicated TUI modules.
    - Add focused coverage for resize reflow, feature-gated behavior,
    streaming source preservation, interrupted output cleanup,
    unicode-neutral text, terminal-specific row caps, and composer/layout
    stability.
    
    ## Runtime Bounds
    
    Resize reflow keeps only the most recent rendered rows when a row cap is
    active. The default is `auto`, which maps to the detected terminal's
    default scrollback size where Codex can identify it: VS Code `1000`,
    Windows Terminal `9001`, WezTerm `3500`, and Alacritty `10000`.
    Terminals without a dedicated mapping use the conservative fallback of
    `1000` rows. Users can override this with `[tui.terminal_resize_reflow]
    max_rows = N`, or set `max_rows = 0` to disable row limiting.
    
    ## Validation
    
    - `just fmt`
    - `git diff --check`
    - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui reflow`
    - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui
    transcript_reflow`
    - `just fix -p codex-tui`
    - PR CI in progress on the squashed branch
  • Enable unavailable dummy tools by default (#19459)
    ## Summary
    - Mark `unavailable_dummy_tools` as a stable feature and enable it by
    default
    - Update the feature registry test to match the new default state
    
    ## Testing
    - `just fmt`
    - `cargo test -p codex-features`
  • Add goal persistence foundation (1 / 5) (#18073)
    Adds the persisted goal foundation for the rest of the stack. This PR is
    intentionally limited to feature flag and state-layer behavior;
    app-server APIs, model tools, runtime continuation, and TUI UX are
    layered in later PRs.
    
    ## Why
    
    Goal mode needs durable thread-level state before clients or model tools
    can safely build on it. The state layer needs to know whether a goal
    exists, what objective it tracks, whether it is active, paused,
    budget-limited, or complete, and how much time/token usage has already
    been accounted.
    
    ## What changed
    
    - Added the `goals` feature flag and generated config schema entry.
    - Added the `thread_goals` state table and Rust model for persisted
    thread goals.
    - Added state runtime APIs for creating, replacing, updating, deleting,
    and accounting goal usage.
    - Added `goal_id`-based stale update protection so an old goal update
    cannot overwrite a replacement.
    - Kept this PR scoped to persistence and state runtime behavior, with no
    app-server, model-facing, continuation, or TUI behavior yet.
    
    ## Verification
    
    - Added state runtime coverage for goal creation, replacement, stale
    update protection, status transitions, token-budget behavior, and usage
    accounting.
  • Add computer_use feature requirement key (#19071)
    ## Summary
    - add the `computer_use` requirements-only feature key
    - include it in generated config schema output
    - cover the new key in feature metadata tests
    
    ## Testing
    - `cargo test -p codex-features`
    - `just write-config-schema`
    - `just fmt`
    - `just fix -p codex-features`
    
    cc @xl-openai
    
    ---------
    
    Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>
  • Mark codex_hooks stable (#19012)
    # Why
    
    Hooks are ready to graduate to GA in the next release!
    
    # What
    
    - Moves `Feature::CodexHooks` into the stable feature group.
    - Marks the `codex_hooks` feature spec as `Stage::Stable` and
    default-enabled.
  • chore(auto-review) feature => stable (#19063)
    ## Summary
    Turn on Auto Review
    
    ## Testing
    - [x] Update unit tests
  • [Codex] Register browser requirements feature keys (#18956)
    ## Summary
    - register `in_app_browser` and `browser_use` as stable feature keys
    - allow requirements/MDM feature requirements to pin those desktop
    browser controls
    - add coverage for browser requirements being accepted by config loading
    
    ## Testing
    - `cargo fmt --all` (`just fmt` unavailable locally; rustfmt warned
    about nightly-only `imports_granularity` config)
    - `cargo test -p codex-features`
    - `cargo test -p codex-core browser_feature_requirements_are_valid`
    - Tested manually by setting in `requirements.toml` and seeing after app
    restart state to reflect the setting was correct (at the time hiding the
    `Browser Use` setting when the enterprise setting was set to false
  • feat: Support remote plugin list/read. (#18452)
    Add a temporary internal remote_plugin feature flag that merges remote
    marketplaces into plugin/list and routes plugin/read through the remote
    APIs when needed, while keeping pure local marketplaces working as
    before.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • fix: fully revert agent identity runtime wiring (#18757)
    ## Summary
    
    This PR fully reverts the previously merged Agent Identity runtime
    integration from the old stack:
    https://github.com/openai/codex/pull/17387/changes
    
    It removes the Codex-side task lifecycle wiring, rollout/session
    persistence, feature flag plumbing, lazy `auth.json` mutation,
    background task auth paths, and request callsite changes introduced by
    that stack.
    
    This leaves the repo in a clean pre-AgentIdentity integration state so
    the follow-up PRs can reintroduce the pieces in smaller reviewable
    layers.
    
    ## Stack
    
    1. This PR: full revert
    2. https://github.com/openai/codex/pull/18871: move Agent Identity
    business logic into a crate
    3. https://github.com/openai/codex/pull/18785: add explicit
    AgentIdentity auth mode and startup task allocation
    4. https://github.com/openai/codex/pull/18811: migrate auth callsites
    through AuthProvider
    
    ## Testing
    
    Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.
  • feat: chronicle alias (#18651)
    Rename Telepathy to Chronicle and add an alias for backward
    compatibility
  • [codex] Add workspace owner usage nudge UI (#18221)
    ## Summary
    
    Third PR in the split from #17956. Stacked on #18220.
    
    - shows workspace-owner/member-specific rate-limit messages behind
    `workspace_owner_usage_nudge`
    - prompts workspace members to notify the owner or request a usage-limit
    increase
    - sends the confirmed nudge through the app-server API and renders
    completion feedback
    - adds focused TUI snapshot coverage for prompts and completion states
    - feature gate
    
    ## Validation
    
    - `cargo test -p codex-backend-client`
    - `cargo test -p codex-app-server-protocol`
    - `cargo test -p codex-app-server rate_limits`
    - `cargo test -p codex-tui workspace_`
    - `cargo test -p codex-tui status_`
    - `just fmt`
    - `just fix -p codex-backend-client`
    - `just fix -p codex-app-server-protocol`
    - `just fix -p codex-app-server`
    - `just fix -p codex-tui`
  • [TUI] add external config migration prompt when start TUI (#17891)
    - add a TUI startup migration prompt for external agent config
    - support migrating external configs including config, skills, AGENTS.md
    and plugins
    - gate the prompt behind features.external_migrate (default false)
    
    <img width="1037" height="480" alt="Screenshot 2026-04-14 at 9 29 14 PM"
    src="https://github.com/user-attachments/assets/6060849b-03cb-429a-9c13-c7bb46ad2e65"
    />
    <img width="713" height="183" alt="Screenshot 2026-04-14 at 9 29 26 PM"
    src="https://github.com/user-attachments/assets/d13f177e-d4c4-479c-8736-ef29636081e1"
    />
    
    ---------
    
    Co-authored-by: Eric Traut <etraut@openai.com>
  • Guardian -> Auto-Review (#18021)
    This PR is a user-facing change for our rebranding of guardian to
    auto-review.
  • add token-based tool deferral behind feature flag (#18097)
    add new `tool_search_always_defer_mcp_tools` feature flag that always
    defers all mcp tools rather than deferring once > 100 deferrable tools.
    
    add new tests, also move `mcp_exposure` tests into dedicated file rather
    than polluting `codex_tests`.
  • Stream apply_patch changes (#17862)
    Adds new events for streaming apply_patch changes from responses api.
    This is to enable clients to show progress during file writes.
    
    Caveat: This does not work with apply_patch in function call mode, since
    that required adding streaming json parsing.
  • fix: deprecate use_legacy_landlock feature flag (#17971)
    ## Summary
    - mark `features.use_legacy_landlock` as a deprecated feature flag
    - emit a startup deprecation notice when the flag is configured
    - add feature- and core-level regression coverage for the notice
    
    
    <img width="1288" height="93" alt="Screenshot 2026-04-15 at 11 14 00 PM"
    src="https://github.com/user-attachments/assets/fffc628b-614c-4521-9374-64e50a269252"
    />
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Launch image generation by default (#17153)
    ## Summary
    - Promote `image_generation` from under-development to stable
    - Enable image generation by default in the feature registry
    - Update feature coverage for the new launch-state expectation
    - Add the missing image-generation auth fixture field in a tool registry
    test
    
    ## Testing
    - `just fmt`
    - `cargo test -p codex-features`
    - `cargo test -p codex-tools` currently fails:
    `test_full_toolset_specs_for_gpt5_codex_unified_exec_web_search` needs
    its expected default tool list updated for `image_generation`
  • Update ToolSearch to be enabled by default (#17854)
    ## Summary
    - Promote `Feature::ToolSearch` to `Stable` and enable it in the default
    feature set
    - Update feature tests and tool registry coverage to match the new
    default
    - Adjust the search-tool integration test to assert the default-on path
    and explicit disable fallback
    
    ## Testing
    - `just fmt`
    - `cargo test -p codex-features`
    - `cargo test -p codex-core --test all search_tool`
    - `cargo test -p codex-tools`
  • [mcp] Add dummy tools for previously called but currently missing tools. (#17853)
    - [x] Add dummy tools for previously called but currently missing tools.
    Currently supporting MCP tools only.
  • chore(features) codex dependencies feat (#17960)
    ## Summary
    Setting this up
    
    ## Testing
    - [x] Unit tests pass
  • [codex-analytics] enable general analytics by default (#17389)
    ## Summary
    - Make GeneralAnalytics stable and enabled by default.
    - Update feature tests and app-server lifecycle fixtures for explicit
    general_analytics=false.
    - Keep app-server integration tests isolated from host managed config so
    explicit feature fixtures are deterministic.
    
    ## Validation
    - cargo test -p codex-features
    - cargo test -p codex-app-server general_analytics (matched 0 tests)
    - cargo test -p codex-app-server thread_start_
    - cargo test -p codex-app-server thread_fork_
    - cargo test -p codex-app-server thread_resume_
    - cargo test -p codex-app-server
    config_read_includes_system_layer_and_overrides
  • Always enable original image detail on supported models (#17665)
    ## Summary
    
    This PR removes `image_detail_original` as a runtime experiment and
    makes original image detail available whenever the selected model
    supports it.
    
    Concretely, this change:
    - drops the `image_detail_original` feature flag from the feature
    registry and generated config schema
    - makes tool-emitted image detail depend only on
    `ModelInfo.supports_image_detail_original`
    - updates `view_image` and `code_mode`/`js_repl` image emission to use
    that capability check directly
    - removes now-redundant experiment-specific tests and instruction
    coverage
    - keeps backward compatibility for existing configs by silently ignoring
    a stale `features.image_detail_original` entry
    
    The net effect is that `detail: "original"` is always available on
    supported models, without requiring an experiment toggle.
  • Configure multi_agent_v2 spawn agent hints (#17071)
    Allow multi_agent_v2 features to have its own temporary configuration
    under `[features.multi_agent_v2]`
    
    ```
    [features.multi_agent_v2]
    enabled = true
    usage_hint_enabled = false
    usage_hint_text = "Custom delegation guidance."
    hide_spawn_agent_metadata = true
    ```
    
    Absent `usage_hint_text` means use the default hint.
    
    ```
    [features]
    multi_agent_v2 = true
    ```
    
    still works as the boolean shorthand.
  • Refactor config types into a separate crate (#16962)
    Move config types into a separate crate because their macros expand into
    a lot of new code.