Commit Graph

1018 Commits

  • fix: add tui.alternate_screen config and --no-alt-screen CLI flag for Zellij scrollback (#8555)
    Fixes #2558
    
    Codex uses alternate screen mode (CSI 1049) which, per xterm spec,
    doesn't support scrollback. Zellij follows this strictly, so users can't
    scroll back through output.
    
    **Changes:**
    - Add `tui.alternate_screen` config: `auto` (default), `always`, `never`
    - Add `--no-alt-screen` CLI flag
    - Auto-detect Zellij and skip alt screen (uses existing `ZELLIJ` env var
    detection)
    
    **Usage:**
    ```bash
    # CLI flag
    codex --no-alt-screen
    
    # Or in config.toml
    [tui]
    alternate_screen = "never"
    ```
    
    With default `auto` mode, Zellij users get working scrollback without
    any config changes.
    
    ---------
    
    Co-authored-by: Josh McKinney <joshka@openai.com>
  • Add config to disable /feedback (#8909)
    Some enterprises do not want their users to be able to `/feedback`.
    
    <img width="395" height="325" alt="image"
    src="https://github.com/user-attachments/assets/2dae9c0b-20c3-4a15-bcd3-0187857ebbd8"
    />
    
    Adds to `config.toml`:
    
    ```toml
    [feedback]
    enabled = false
    ```
    
    I've deliberately decided to:
    1. leave other references to `/feedback` (e.g. in the interrupt message,
    tips of the day) unchanged. I think we should continue to promote the
    feature even if it is not usable currently.
    2. leave the `/feedback` menu item selectable and display an error
    saying it's disabled, rather than remove the menu item (which I believe
    would raise more questions).
    
    but happy to discuss these.
    
    This will be followed by a change to requirements.toml that admins can
    use to force the value of feedback.enabled.
  • fix(app-server): set originator header from initialize JSON-RPC request (#8873)
    **Motivation**
    The `originator` header is important for codex-backend’s Responses API
    proxy because it identifies the real end client (codex cli, codex vscode
    extension, codex exec, future IDEs) and is used to categorize requests
    by client for our enterprise compliance API.
    
    Today the `originator` header is set by either:
    - the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var (our VSCode extension
    does this)
    - calling `set_default_originator()` which sets a global immutable
    singleton (`codex exec` does this)
    
    For `codex app-server`, we want the `initialize` JSON-RPC request to set
    that header because it is a natural place to do so. Example:
    ```json
    {
      "method": "initialize",
      "id": 0,
      "params": {
        "clientInfo": {
          "name": "codex_vscode",
          "title": "Codex VS Code Extension",
          "version": "0.1.0"
        }
      }
    }
    ```
    and when app-server receives that request, it can call
    `set_default_originator()`. This is a much more natural interface than
    asking third party developers to set an env var.
    
    One hiccup is that `originator()` reads the global singleton and locks
    in the value, preventing a later `set_default_originator()` call from
    setting it. This would be fine but is brittle, since any codepath that
    calls `originator()` before app-server can process an `initialize`
    JSON-RPC call would prevent app-server from setting it. This was
    actually the case with OTEL initialization which runs on boot, but I
    also saw this behavior in certain tests.
    
    Instead, what we now do is:
    - [unchanged] If `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var is set,
    `originator()` would return that value and `set_default_originator()`
    with some other value does NOT override it.
    - [new] If no env var is set, `originator()` would return the default
    value which is `codex_cli_rs` UNTIL `set_default_originator()` is called
    once, in which case it is set to the new value and becomes immutable.
    Later calls to `set_default_originator()` returns
    `SetOriginatorError::AlreadyInitialized`.
    
    **Other notes**
    - I updated `codex_core::otel_init::build_provider` to accepts a service
    name override, and app-server sends a hardcoded `codex_app_server`
    service name to distinguish it from `codex_cli_rs` used by default (e.g.
    TUI).
    
    **Next steps**
    - Update VSCE to set the proper value for `clientInfo.name` on
    `initialize` and drop the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var.
    - Delete support for `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` in codex-rs.
  • [device-auth] When headless environment is detected, show device login flow instead. (#8756)
    When headless environment is detected, show device login flow instead.
  • Add 5s timeout to models list call + integration test (#8942)
    - Enforce a 5s timeout around the remote models refresh to avoid hanging
    /models calls.
  • fix: treat null MCP resource args as empty (#8917)
    Handle null tool arguments in the MCP resource handler so optional
    resource tools accept null without failing, preserving normal JSON
    parsing for non-null payloads and improving robustness when models emit
    null; this avoids spurious argument parse errors for list/read MCP
    resource calls.
  • Elevated sandbox NUX (#8789)
    Elevated Sandbox NUX:
    
    * prompt for elevated sandbox setup when agent mode is selected (via
    /approvals or at startup)
    * prompt for degraded sandbox if elevated setup is declined or fails
    * introduce /elevate-sandbox command to upgrade from degraded
    experience.
  • Attempt to reload auth as a step in 401 recovery (#8880)
    When authentication fails, first attempt to reload the auth from file
    and then attempt to refresh it.
  • feat: fork conversation/thread (#8866)
    ## Summary
    - add thread/conversation fork endpoints to the protocol (v1 + v2)
    - implement fork handling in app-server using thread manager and config
    overrides
    - add fork coverage in app-server tests and document `thread/fork` usage
  • Immutable CodexAuth (#8857)
    Historically we started with a CodexAuth that knew how to refresh it's
    own tokens and then added AuthManager that did a different kind of
    refresh (re-reading from disk).
    
    I don't think it makes sense for both `CodexAuth` and `AuthManager` to
    be mutable and contain behaviors.
    
    Move all refresh logic into `AuthManager` and keep `CodexAuth` as a data
    object.
  • Add read-only when backfilling requirements from managed_config (#8913)
    When a user has a managed_config which doesn't specify read-only, Codex
    fails to launch.
  • fix: preserve core env vars on Windows (#8897)
    This updates core shell environment policy handling to match Windows
    case-insensitive variable names and adds a Windows-only regression test,
    so Path/TEMP are no longer dropped when inherit=core.
  • config requirements: improve requirement error messages (#8843)
    **Before:**
    ```
    Error loading configuration: value `Never` is not in the allowed set [OnRequest]
    ```
    
    **After:**
    ```
    Error loading configuration: invalid value for `approval_policy`: `Never` is not in the
    allowed set [OnRequest] (set by MDM com.openai.codex:requirements_toml_base64)
    ```
    
    Done by introducing a new struct `ConfigRequirementsWithSources` onto
    which we `merge_unset_fields` now. Also introduces a pair of requirement
    value and its `RequirementSource` (inspired by `ConfigLayerSource`):
    
    ```rust
    pub struct Sourced<T> {
        pub value: T,
        pub source: RequirementSource,
    }
    ```
  • Avoid setpgid for inherited stdio on macOS (#8691)
    ## Summary
    - avoid setting a new process group when stdio is inherited (keeps child
    in foreground PG)
    - keep process-group isolation when stdio is redirected so killpg
    cleanup still works
    - prevents macOS job-control SIGTTIN stops that look like hangs after
    output
    
    ## Testing
    - `cargo build -p codex-cli`
    - `GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_NOSYSTEM=1
    CARGO_BIN_EXE_codex=/Users/denis/Code/codex/codex-rs/target/debug/codex
    /opt/homebrew/bin/timeout 30m cargo test -p codex-core -p codex-exec`
    
    ## Context
    This fixes macOS sandbox hangs for commands like `elixir -v` / `erl
    -noshell`, where the child was moved into a new process group while
    still attached to the controlling TTY. See issue #8690.
    
    ## Authorship & collaboration
    - This change and analysis were authored by **Codex** (AI coding agent).
    - Human collaborator: @seeekr provided repro environment, context, and
    review guidance.
    - CLI used: `codex-cli 0.77.0`.
    - Model: `gpt-5.2-codex (xhigh)`.
    
    Co-authored-by: Eric Traut <etraut@openai.com>
  • fix: include project instructions in /review subagent (#8899)
    Include project-level AGENTS.md and skills in /review sessions so the
    review sub-agent uses the same instruction pipeline as standard runs,
    keeping reviewer context aligned with normal sessions.
  • chore: drop metrics exporter config (#8892)
    Dropped for now as enterprises should not be able to use it
  • fix: stabilize list_dir pagination order (#8826)
    Sort list_dir entries before applying offset/limit so pagination matches
    the displayed order, update pagination/truncation expectations, and add
    coverage for sorted pagination. This ensures stable, predictable
    directory pages when list_dir is enabled.
  • feat: metrics capabilities (#8318)
    Add metrics capabilities to Codex. The `README.md` is up to date.
    
    This will not be merged with the metrics before this PR of course:
    https://github.com/openai/codex/pull/8350
  • Feat: appServer.requirementList for requirement.toml (#8800)
    ### Summary
    We are exposing requirements via `requirement/list` method from
    app-server so that we can conditionally disable the agent mode dropdown
    selection in VSCE and correctly setting the default value.
    
    ### Sample output
    #### `etc/codex/requirements.toml`
    <img width="497" height="49" alt="Screenshot 2026-01-06 at 11 32 06 PM"
    src="https://github.com/user-attachments/assets/fbd9402e-515f-4b9e-a158-2abb23e866a0"
    />
    
    #### App server response
    <img width="1107" height="79" alt="Screenshot 2026-01-06 at 11 30 18 PM"
    src="https://github.com/user-attachments/assets/c0d669cd-54ef-4789-a26c-adb2c41950af"
    />
  • Support symlink for skills discovery. (#8801)
    Skills discovery now follows symlink entries for SkillScope::User
    ($CODEX_HOME/skills) and SkillScope::Admin (e.g. /etc/codex/skills).
    
    Added cycle protection: directories are canonicalized and tracked in a
    visited set to prevent infinite traversal from circular links.
    
    Added per-root traversal limits to avoid accidentally scanning huge
    trees:
    - max depth: 6
    - max directories: 2000 (logs a warning if truncated)
    
    For now, symlink stat failures and traversal truncation are logged
    rather than surfaced as UI “invalid SKILL.md” warnings.
  • Clarify YAML frontmatter formatting in skill-creator (#8610)
    Fixes #8609
    
    # Summary
    
    Emphasize single-line name/description values and quoting when values
    could be interpreted as YAML syntax.
    
    # Testing
    
    Not run (skill-only change.)
  • Add feature for optional request compression (#8767)
    Adds a new feature
    `enable_request_compression` that will compress using zstd requests to
    the codex-backend. Currently only enabled for codex-backend so only enabled for openai providers when using chatgpt::auth even when the feature is enabled
    
    Added a new info log line too for evaluating the compression ratio and
    overhead off compressing before requesting. You can enable with
    `RUST_LOG=$RUST_LOG,codex_client::transport=info`
    
    ```
    2026-01-06T00:09:48.272113Z  INFO codex_client::transport: Compressed request body with zstd pre_compression_bytes=28914 post_compression_bytes=11485 compression_duration_ms=0
    ```
  • Override truncation policy at model info level (#8856)
    We used to override truncation policy by comparing model info vs config
    value in context manager. A better way to do it is to construct model
    info using the config value
  • fix: implement 'Allow this session' for apply_patch approvals (#8451)
    **Summary**
    This PR makes “ApprovalDecision::AcceptForSession / don’t ask again this
    session” actually work for `apply_patch` approvals by caching approvals
    based on absolute file paths in codex-core, properly wiring it through
    app-server v2, and exposing the choice in both TUI and TUI2.
    - This brings `apply_patch` calls to be at feature-parity with general
    shell commands, which also have a "Yes, and don't ask again" option.
    - This also fixes VSCE's "Allow this session" button to actually work.
    
    While we're at it, also split the app-server v2 protocol's
    `ApprovalDecision` enum so execpolicy amendments are only available for
    command execution approvals.
    
    **Key changes**
    - Core: per-session patch approval allowlist keyed by absolute file
    paths
    - Handles multi-file patches and renames/moves by recording both source
    and destination paths for `Update { move_path: Some(...) }`.
    - Extend the `Approvable` trait and `ApplyPatchRuntime` to work with
    multiple keys, because an `apply_patch` tool call can modify multiple
    files. For a request to be auto-approved, we will need to check that all
    file paths have been approved previously.
    - App-server v2: honor AcceptForSession for file changes
    - File-change approval responses now map AcceptForSession to
    ReviewDecision::ApprovedForSession (no longer downgraded to plain
    Approved).
    - Replace `ApprovalDecision` with two enums:
    `CommandExecutionApprovalDecision` and `FileChangeApprovalDecision`
    - TUI / TUI2: expose “don’t ask again for these files this session”
    - Patch approval overlays now include a third option (“Yes, and don’t
    ask again for these files this session (s)”).
        - Snapshot updates for the approval modal.
    
    **Tests added/updated**
    - Core:
    - Integration test that proves ApprovedForSession on a patch skips the
    next patch prompt for the same file
    - App-server:
    - v2 integration test verifying
    FileChangeApprovalDecision::AcceptForSession works properly
    
    **User-visible behavior**
    - When the user approves a patch “for session”, future patches touching
    only those previously approved file(s) will no longer prompt gain during
    that session (both via app-server v2 and TUI/TUI2).
    
    **Manual testing**
    Tested both TUI and TUI2 - see screenshots below.
    
    TUI:
    <img width="1082" height="355" alt="image"
    src="https://github.com/user-attachments/assets/adcf45ad-d428-498d-92fc-1a0a420878d9"
    />
    
    
    TUI2:
    <img width="1089" height="438" alt="image"
    src="https://github.com/user-attachments/assets/dd768b1a-2f5f-4bd6-98fd-e52c1d3abd9e"
    />
  • remove unnecessary todos (#8842)
    > // todo(aibrahim): why are we passing model here while it can change?
    
    we update it on each turn with `.with_model`
    
    > //TODO(aibrahim): run CI in release mode.
    
    although it's good to have, release builds take double the time tests
    take.
    
    > // todo(aibrahim): make this async function
    
    we figured out another way of doing this sync
  • Merge Modelfamily into modelinfo (#8763)
    - Merge ModelFamily into ModelInfo
    - Remove logic for adding instructions to apply patch
    - Add compaction limit and visible context window to `ModelInfo`
  • Move tests below auth manager (#8840)
    To simplify future diffs
  • chore: unify conversation with thread name (#8830)
    Done and verified by Codex + refactor feature of RustRover