Commit Graph

1495 Commits

  • [apps] Cache MCP actions from apps. (#10662)
    MCP actions take a long time to load for users with lots of apps
    installed. Adding a cache for these actions with 1hr expiration, given
    that they are almost always aren't going to change unless people install
    another app, which means they also need to restart codex to pick it up.
  • feat: add phase 1 mem db (#10634)
    - Schema: thread_id (PK, FK to threads.id with cascade delete),
    trace_summary, memory_summary, updated_at.
    - Migration: creates the table and an index on (updated_at DESC,
    thread_id DESC) for efficient recent-first reads.
      - Runtime API (DB-only):
          - `get_thread_memory(thread_id)`: fetch one memory row.
    - `upsert_thread_memory(thread_id, trace_summary, memory_summary)`:
    insert/update by thread id and always advance updated_at.
    - `get_last_n_thread_memories_for_cwd(cwd, n)`: join thread_memory with
    threads and return newest n rows for an exact cwd match.
    - Model layer: introduced ThreadMemory and row conversion types to keep
    query decoding typed and consistent with existing state models.
  • Persist pending input user events (#10656)
    - Persist user-message events for mid-turn injected input by emitting
    user message turn items when pending input is recorded.
  • feat(linux-sandbox): add bwrap support (#9938)
    ## Summary
    This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
    curent Linux sandbox path relies on in-process restrictions (including
    Landlock). Bubblewrap gives us a more uniform filesystem isolation
    model, especially explicit writable roots with the option to make some
    directories read-only and granular network controls.
    
    This is behind a feature flag so we can validate behavior safely before
    making it the default.
    
    - Added temporary rollout flag:
      - `features.use_linux_sandbox_bwrap`
    - Preserved existing default path when the flag is off.
    - In Bubblewrap mode:
    - Added internal retry without /proc when /proc mount is not permitted
    by the host/container.
  • Cloud Requirements: take precedence over MDM (#10633)
    Cloud Requirements should be applied before MDM requirements.
  • Add option to approve and remember MCP/Apps tool usage (#10584)
    This PR adds a new approval option for app/MCP tool calls: “Allow and
    remember” (session-scoped).
    When selected, Codex stores a temporary approval and auto-approves
    matching future calls for the rest of the session.
    
    Added a session-scoped approval key (`server`, `connector_id`,
    `tool_name`) and persisted it in `tool_approvals` as
    `ApprovedForSession`.
    On subsequent matching calls, approval is skipped and treated as
    accepted.
    - Updated the approval question options to conditionally include:
    - Accept
    - Allow and remember (conditional)
    - Decline
    - Cancel
    
    The new “Allow and remember” option is only shown when all of these are
    true:
    
    1. The call is routed through the Codex Apps MCP server (codex_apps).
    2. The tool requires approval based on annotations:
    - read_only_hint == false, and
    - destructive_hint == true or open_world_hint == true.
    3. The tool includes a connector_id in metadata (used to build the
    remembered approval key).
    
    If no `connector_id` is present, the prompt still appears (when approval
    is required), but only with the existing choices (Accept / Decline /
    Cancel). Approval prompting in this path has an explicit early return
    unless server == `codex_apps`.
  • Stop client from being state carrier (#10595)
    I'd like to make client session wide. This requires shedding all random
    state it has to carry.
  • feat: land unified_exec (#10641)
    Land `unified_exec` for all non-windows OS
  • Update tests to stop using sse_completed fixture (#10638)
    Summary:
    - replace the `sse_completed` fixture and related JSON template with
    direct `responses::ev_completed` payload builders
    - cascade the new SSE helpers through all affected core tests for
    consistency and clarity
    - remove legacy fixtures that were no longer needed once the helpers are
    in place
    
    Testing:
    - Not run (not requested)
  • Migrate state DB path helpers to versioned filename (#10623)
    Summary
    - add versioned state sqlite filename helpers and re-export them from
    the state crate
    - remove legacy state files when initializing the runtime and update
    consumers/tests to use the new helpers
    - tweak logs client description and database resolution to match the new
    path
  • Add a codex.rate_limits event for websockets (#10324)
    When communicating over websockets, we can't rely on headers to deliver
    rate limit information. This PR adds a `codex.rate_limits` event that
    the server can pass to the client to inform them about rate limit usage.
    The client parses this data the same way we parse rate limit headers in
    HTTP mode.
    
    This PR also wires up the etag and reasoning headers for websockets
  • chore: simplify user message detection (#10611)
    We don't check anymore the response item with `user` role as they may be
    instructions etc
  • Requirements: add source to constrained requirement values (#10568)
    If we want to build `/debug-config`, we'll need to know the requirements
    sources that supplied the values.
    
    This PR adds those sources such that we can render them in the UI.
  • Prefer state DB thread listings before filesystem (#10544)
    Summary
    - add Cursor/ThreadsPage conversions so state DB listings can be mapped
    back into the rollout list model
    - make recorder list helpers query the state DB first (archived flag
    included) and only fall back to file traversal if needed, along with
    populating head bytes lazily
    - add extensive tests to ensure the DB path is honored for active and
    archived threads and that the fallback works
    
    Testing
    - Not run (not requested)
    
    <img width="1196" height="693" alt="Screenshot 2026-02-03 at 20 42 33"
    src="https://github.com/user-attachments/assets/826b3c7a-ef11-4b27-802a-3c343695794a"
    />
  • Move metadata calculation out of client (#10589)
    Model client shouldn't be responsible for this.
  • feat: add APIs to list and download public remote skills (#10448)
    Add API to list / download from remote public skills
  • chore(arg0): advisory-lock janitor for codex tmp paths (#10039)
    ## Description
    
    ### What changed
    - Switch the arg0 helper root from `~/.codex/tmp/path` to
    `~/.codex/tmp/path2`
    - Add `Arg0PathEntryGuard` to keep both the `TempDir` and an exclusive
    `.lock` file alive for the process lifetime
    - Add a startup janitor that scans `path2` and deletes only directories
    whose lock can be acquired
    
    ### Tests
    - `cargo clippy -p codex-arg0`
    - `cargo clippy -p codex-core`
    - `cargo test -p codex-arg0`
    - `cargo test -p codex-core`
  • [codex] Default values from requirements if unset (#10531)
    If we don't set any explicit values for sandbox or approval policy,
    let's try to use a requirements-satisfying value.
  • [apps] Gateway MCP should be blocking. (#10289)
    Make Apps Gateway MCP blocking since otherwise app mentions may not work
    when apps are not loaded. Messages sent before apps become available
    will be queued.
    
    This only affects when `apps` feature is enabled.
  • Improve Default mode prompt (less confusion with Plan mode) (#10545)
    ## Summary
    
    This PR updates `request_user_input` behavior and Default-mode guidance
    to match current collaboration-mode semantics and reduce model
    confusion.
    
    ## Why
    
    - `request_user_input` should be explicitly documented as **Plan-only**.
    - Tool description and runtime availability checks should be driven by
    the **same centralized mode policy**.
    - Default mode prompt needed stronger execution guidance and explicit
    instruction that `request_user_input` is unavailable.
    - Error messages should report the **actual mode name** (not aliases
    that can read as misleading).
    
    ## What changed
    
    - Centralized `request_user_input` mode policy in `core` handler logic:
      - Added a single allowed-modes config (`Plan` only).
      - Reused that policy for:
        - runtime rejection messaging
        - tool description text
    - Updated tool description to include availability constraint:
      - `"This tool is only available in Plan mode."`
    - Updated runtime rejection behavior:
      - `Default` -> `"request_user_input is unavailable in Default mode"`
      - `Execute` -> `"request_user_input is unavailable in Execute mode"`
    - `PairProgramming` -> `"request_user_input is unavailable in Pair
    Programming mode"`
    - Strengthened Default collaboration prompt:
      - Added explicit execution-first behavior
      - Added assumptions-first guidance
      - Added explicit `request_user_input` unavailability instruction
      - Added concise progress-reporting expectations
    - Simplified formatting implementation:
      - Inlined allowed-mode name collection into `format_allowed_modes()`
    - Kept `format_allowed_modes()` output for 3+ modes as CSV style
    (`modes: a,b,c`)
  • fix(app-server): fix approval events in review mode (#10416)
    One of our partners flagged that they were seeing the wrong order of
    events when running `review/start` with command exec approvals:
    ```
    {"method":"item/commandExecution/requestApproval","id":0,"params":{"threadId":"019c0b6b-6a42-7c02-99c4-98c80e88ac27","turnId":"0","itemId":"0","reason":"`/bin/zsh -lc 'git show b7a92b4eacf262c575f26b1e1ed621a357642e55 --stat'` requires approval: Xcode-required approval: Require explicit user confirmation for all commands.","proposedExecpolicyAmendment":null}}
    
    {"method":"item/started","params":{"item":{"type":"commandExecution","id":"call_AEjlbHqLYNM7kbU3N6uw1CNi","command":"/bin/zsh -lc 'git show b7a92b4eacf262c575f26b1e1ed621a357642e55 --stat'","cwd":"/Users/devingreen/Desktop/SampleProject","processId":null,"status":"inProgress","commandActions":[{"type":"unknown","command":"git show b7a92b4eacf262c575f26b1e1ed621a357642e55 --stat"}],"aggregatedOutput":null,"exitCode":null,"durationMs":null},"threadId":"019c0b6b-6a42-7c02-99c4-98c80e88ac27","turnId":"0"}}
    ```
    
    **Key fix**: In the review sub‑agent delegate we were forwarding exec
    (and patch) approvals using the parent turn id (`parent_ctx.sub_id`) as
    the approval call_id. That made
    `item/commandExecution/requestApproval.itemId` differ from the actual
    `item/started` id. We now forward the sub‑agent’s `call_id` from the
    approval event instead, so the approval item id matches the
    commandExecution item id in review flows.
    
    Here’s the expected event order for an inline `review/start` that
    triggers an exec approval after this fix:
    1. Response to review/start (JSON‑RPC response)
    - Includes `turn` (status inProgress) and `review_thread_id` (same as
    parent thread for inline).
    2. `turn/started` notification
      - turnId is the review turn id (e.g., "0").
    3. `item/started` → EnteredReviewMode
      - item.id == turnId, marks entry into review mode.
    4. `item/started` → commandExecution
      - item.id == <call_id> (e.g., "review-call-1"), status: inProgress.
    5. `item/commandExecution/requestApproval` request
      - JSON‑RPC request (not a notification).
      - params.itemId == <call_id> and params.turnId == turnId.
    6. Client replies to approval request (Approved / Declined / etc).
    7. If approved:
      - Optional `item/commandExecution/outputDelta` notifications.
      - `item/completed` → commandExecution with status and exitCode.
    8. Review finishes:
      - `item/started` → ExitedReviewMode
      - `item/completed` → ExitedReviewMode
      - (Agent message items may also appear, depending on review output.)
    9. `turn/completed` notification
    
    The key being #4 and #5 are now in the proper order with the correct
    item id.
  • Inject CODEX_THREAD_ID into the terminal environment (#10096)
    Inject CODEX_THREAD_ID (when applicable) into the terminal environment
    so that the agent (and skills) can refer to the current thread / session
    ID.
    
    Discussion:
    https://openai.slack.com/archives/C095U48JNL9/p1769542492067109
  • Enable parallel shell tools (#10505)
    Summary
    - mark the shell-related tools as supporting parallel tool calls so
    exec_command, shell_command, etc. can run concurrently
    - update expectations in tool parallelism tests to reflect the new
    parallel behavior
    - drop the unused serial duration helper from the suite
    
    Testing
    - Not run (not requested)
  • Cleanup collaboration mode variants (#10404)
    ## Summary
    
    This PR simplifies collaboration modes to the visible set `default |
    plan`, while preserving backward compatibility for older partners that
    may still send legacy mode
    names.
    
    Specifically:
    - Renames the old Code behavior to **Default**.
    - Keeps **Plan** as-is.
    - Removes **Custom** mode behavior (fallbacks now resolve to Default).
    - Keeps `PairProgramming` and `Execute` internally for compatibility
    plumbing, while removing them from schema/API and UI visibility.
    - Adds legacy input aliasing so older clients can still send old mode
    names.
    
    ## What Changed
    
    1. Mode enum and compatibility
    - `ModeKind` now uses `Plan` + `Default` as active/public modes.
    - `ModeKind::Default` deserialization accepts legacy values:
      - `code`
      - `pair_programming`
      - `execute`
      - `custom`
    - `PairProgramming` and `Execute` variants remain in code but are hidden
    from protocol/schema generation.
    - `Custom` variant is removed; previous custom fallbacks now map to
    `Default`.
    
    2. Collaboration presets and templates
    - Built-in presets now return only:
      - `Plan`
      - `Default`
    - Template rename:
      - `core/templates/collaboration_mode/code.md` -> `default.md`
    - `execute.md` and `pair_programming.md` remain on disk but are not
    surfaced in visible preset lists.
    
    3. TUI updates
    - Updated user-facing naming and prompts from “Code” to “Default”.
    - Updated mode-cycle and indicator behavior to reflect only visible
    `Plan` and `Default`.
    - Updated corresponding tests and snapshots.
    
    4. request_user_input behavior
    - `request_user_input` remains allowed only in `Plan` mode.
    - Rejection messaging now consistently treats non-plan modes as
    `Default`.
    
    5. Schemas
    - Regenerated config and app-server schemas.
    - Public schema types now advertise mode values as:
      - `plan`
      - `default`
    
    ## Backward Compatibility Notes
    
    - Incoming legacy mode names (`code`, `pair_programming`, `execute`,
    `custom`) are accepted and coerced to `default`.
    - Outgoing/public schema surfaces intentionally expose only `plan |
    default`.
    - This allows tolerant ingestion of older partner payloads while
    standardizing new integrations on the reduced mode set.
    
    ## Codex author
    `codex fork 019c1fae-693b-7840-b16e-9ad38ea0bd00`
  • Add more detail to 401 error (#10508)
    Add the error.message if it exists, the body otherwise. Truncate body to
    1k characters. Print the cf-ray and the requestId.
    
    **Before:**
    <img width="860" height="305" alt="Screenshot 2026-02-03 at 13 15 28"
    src="https://github.com/user-attachments/assets/949d5a4d-2b51-488c-a723-c6deffde0353"
    />
    
    **After:**
    <img width="1523" height="373" alt="Screenshot 2026-02-03 at 13 15 38"
    src="https://github.com/user-attachments/assets/f96a747e-e596-4a7a-aae9-64210d805b26"
    />
  • fix: clarify deprecation message for features.web_search (#10406)
    clarify that the new `web_search` is not a feature flag under
    `[features]` in the deprecation CTA
  • Trim compaction input (#10374)
    Two fixes:
    
    1. Include trailing tool output in the total context size calculation.
    Otherwise when checking whether compaction should run we ignore newly
    added outputs.
    2. Trim trailing tool output/tool calls until we can fit the request
    into the model context size. Otherwise the compaction endpoint will fail
    to compact. We only trim items that can be reproduced again by the model
    (tool calls, tool call outputs).
  • [Codex][CLI] Gate image inputs by model modalities (#10271)
    ###### Summary
    
    - Add input_modalities to model metadata so clients can determine
    supported input types.
    - Gate image paste/attach in TUI when the selected model does not
    support images.
    - Block submits that include images for unsupported models and show a
    clear warning.
    - Propagate modality metadata through app-server protocol/model-list
    responses.
      - Update related tests/fixtures.
    
      ###### Rationale
    
      - Models support different input modalities.
    - Clients need an explicit capability signal to prevent unsupported
    requests.
    - Backward-compatible defaults preserve existing behavior when modality
    metadata is absent.
    
      ###### Scope
    
      - codex-rs/protocol, codex-rs/core, codex-rs/tui
      - codex-rs/app-server-protocol, codex-rs/app-server
      - Generated app-server types / schema fixtures
    
      ###### Trade-offs
    
    - Default behavior assumes text + image when field is absent for
    compatibility.
      - Server-side validation remains the source of truth.
    
      ###### Follow-up
    
    - Non-TUI clients should consume input_modalities to disable unsupported
    attachments.
    - Model catalogs should explicitly set input_modalities for text-only
    models.
    
      ###### Testing
    
      - cargo fmt --all
      - cargo test -p codex-tui
      - env -u GITHUB_APP_KEY cargo test -p codex-core --lib
      - just write-app-server-schema
    - cargo run -p codex-cli --bin codex -- app-server generate-ts --out
    app-server-types
      - test against local backend
      
    <img width="695" height="199" alt="image"
    src="https://github.com/user-attachments/assets/d22dd04f-5eba-4db9-a7c5-a2506f60ec44"
    />
    
    ---------
    
    Co-authored-by: Josh McKinney <joshka@openai.com>
  • chore: add phase to message responseitem (#10455)
    ### What
    
    add wiring for `phase` field on `ResponseItem::Message` to lay
    groundwork for differentiating model preambles and final messages.
    currently optional.
    
    follows pattern in #9698.
    
    updated schemas with `just write-app-server-schema` so we can see type
    changes.
    
    ### Tests
    Updated existing tests for SSE parsing and hydrating from history
  • feat: replace custom mcp-types crate with equivalents from rmcp (#10349)
    We started working with MCP in Codex before
    https://crates.io/crates/rmcp was mature, so we had our own crate for
    MCP types that was generated from the MCP schema:
    
    
    https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
    
    Now that `rmcp` is more mature, it makes more sense to use their MCP
    types in Rust, as they handle details (like the `_meta` field) that our
    custom version ignored. Though one advantage that our custom types had
    is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
    whereas the types in `rmcp` do not. As such, part of the work of this PR
    is leveraging the adapters between `rmcp` types and the serializable
    types that are API for us (app server and MCP) introduced in #10356.
    
    Note this PR results in a number of changes to
    `codex-rs/app-server-protocol/schema`, which merit special attention
    during review. We must ensure that these changes are still
    backwards-compatible, which is possible because we have:
    
    ```diff
    - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
    + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
    ```
    
    so `ContentBlock` has been replaced with the more general `JsonValue`.
    Note that `ContentBlock` was defined as:
    
    ```typescript
    export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
    ```
    
    so the deletion of those individual variants should not be a cause of
    great concern.
    
    Similarly, we have the following change in
    `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
    
    ```
    - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
    + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
    ```
    
    so:
    
    - `annotations?: ToolAnnotations` ➡️ `JsonValue`
    - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
    - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
    
    and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
    * #10357
    * __->__ #10349
    * #10356
  • make codex better at git (#10145)
    adds basic git context to the session prefix so the model can anchor git
    actions and be a bit more version-aware. structured it in a
    multiroot-friendly shape even though we only have one root today
  • feat: Read personal skills from .agents/skills (#10437)
    - Issue: https://github.com/agentskills/agentskills/issues/15
    - Follow-up to https://github.com/openai/codex/pull/10317 (for team/repo
    skills)
    - This change now also loads personal/user skills from
    `$HOME/.agents/skills` (or `~/.agents/skills`) in addition to loading
    from `.agents/skills` inside of git repos.
    - The location of `.system` skills remains unchanged.
    - Keeping backwards compatibility with `~/.codex/skills` for now until
    we fully deprecate.
    
    With skills in both personal folders:
    <img width="831" height="421" alt="image"
    src="https://github.com/user-attachments/assets/ad8ac918-bfe6-4a2d-8a8e-d608c9d3d701"
    />
    
    We load from both places:
    <img width="607" height="236" alt="image"
    src="https://github.com/user-attachments/assets/480f4db0-ae64-4dc1-bdf5-c5de98c16f5c"
    />
  • [feat] persist thread_dynamic_tools in db (#10252)
    Persist thread_dynamic_tools in sqlite and read first from it. Fall back
    to rollout files if it's not found. Persist dynamic tools to both sqlite
    and rollout files.
    
    Saw that new sessions get populated to db correctly & old sessions get
    backfilled correctly at startup:
    ```
    celia@com-92114 codex-rs % sqlite3 ~/.codex/state.sqlite \      "select thread_id, position,name,description,input_schema from thread_dynamic_tools;"
    019c0cad-ec0d-74b2-a787-e8b33a349117|0|geo_lookup|lookup a city|{"properties":{"city":{"type":"string"}},"required":["city"],"type":"object"}
    ....
    019c10ca-aa4b-7620-ae40-c0919fbd7ea7|0|geo_lookup|lookup a city|{"properties":{"city":{"type":"string"}},"required":["city"],"type":"object"}
    ```
  • emit a separate metric when the user cancels UAT during elevated setup (#10399)
    Currently this shows up as elevated setup failure, which isn't quite
    accurate.
  • fix: unsafe auto-approval of git commands (#10258)
    fixes https://github.com/openai/codex/issues/10160 and some more.
    
    ## Description
    
    Hardens Git command safety to prevent approval bypasses for destructive
    or write-capable invocations (branch delete, risky push forms,
    output/config-override flags), so these commands no longer auto-run as
    “safe.”
    
    - `git branch -d` variants (especially in worktrees / with global
    options like -C / -c)
    - `git show|diff|log --output` ... style file-write flags
    - risky Git config override flags (-c, --config-env) that can trigger
    external execution
    - dangerous push forms that weren’t fully caught (`--force*`,
    `--delete`, `+refspec`, `:refspec`)
    - grouped short-flag delete forms (e.g. stacked branch flags containing
    `d/D`)
    
    will fast follow with a common git policy to bring windows to parity.
    
    ---------
    
    Co-authored-by: Eric Traut <etraut@openai.com>