Commit Graph

59 Commits

  • feat(tui): switch to tree-sitter-highlight bash highlighting (#4666)
    use tree-sitter-highlight instead of custom logic over the tree-sitter
    tree to highlight bash.
  • [MCP] Upgrade rmcp to 0.8 (#4774)
    The version with the well-known discovery and my MCP client name change
    were just released
    
    https://github.com/modelcontextprotocol/rust-sdk/releases
  • Use assert_matches (#4756)
    assert_matches is soon to be in std but is experimental for now.
  • Fix oauth .well-known metadata discovery (#4677)
    This picks up https://github.com/modelcontextprotocol/rust-sdk/pull/459
    which is required for proper well-known metadata discovery for some MCPs
    such as Figma.
  • [MCP] Add support for MCP Oauth credentials (#4517)
    This PR adds oauth login support to streamable http servers when
    `experimental_use_rmcp_client` is enabled.
    
    This PR is large but represents the minimal amount of work required for
    this to work. To keep this PR smaller, login can only be done with
    `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp`
    or `codex mcp list` yet. Fingers crossed that this is the last large MCP
    PR and that subsequent PRs can be smaller.
    
    Under the hood, credentials are stored using platform credential
    managers using the [keyring crate](https://crates.io/crates/keyring).
    When the keyring isn't available, it falls back to storing credentials
    in `CODEX_HOME/.credentials.json` which is consistent with how other
    coding agents handle authentication.
    
    I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able
    to test the dbus store on linux but did verify that the fallback works.
    
    One quirk is that if you have credentials, during development, every
    build will have its own ad-hoc binary so the keyring won't recognize the
    reader as being the same as the write so it may ask for the user's
    password. I may add an override to disable this or allow
    users/enterprises to opt-out of the keyring storage if it causes issues.
    
    <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40"
    src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d"
    />
    <img width="745" height="486" alt="image"
    src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e"
    />
  • chore: refactor tool handling (#4510)
    # Tool System Refactor
    
    - Centralizes tool definitions and execution in `core/src/tools/*`:
    specs (`spec.rs`), handlers (`handlers/*`), router (`router.rs`),
    registry/dispatch (`registry.rs`), and shared context (`context.rs`).
    One registry now builds the model-visible tool list and binds handlers.
    - Router converts model responses to tool calls; Registry dispatches
    with consistent telemetry via `codex-rs/otel` and unified error
    handling. Function, Local Shell, MCP, and experimental `unified_exec`
    all flow through this path; legacy shell aliases still work.
    - Rationale: reduce per‑tool boilerplate, keep spec/handler in sync, and
    make adding tools predictable and testable.
    
    Example: `read_file`
    - Spec: `core/src/tools/spec.rs` (see `create_read_file_tool`,
    registered by `build_specs`).
    - Handler: `core/src/tools/handlers/read_file.rs` (absolute `file_path`,
    1‑indexed `offset`, `limit`, `L#: ` prefixes, safe truncation).
    - E2E test: `core/tests/suite/read_file.rs` validates the tool returns
    the requested lines.
    
    ## Next steps:
    - Decompose `handle_container_exec_with_params` 
    - Add parallel tool calls
  • canonicalize display of Agents.md paths on Windows. (#4577)
    Canonicalize path on Windows to 
    - remove unattractive path prefixes such as `\\?\`
    - simplify it (`../AGENTS.md` vs
    `C:\Users\iceweasel\code\coded\Agents.md`)
    before: <img width="1110" height="45" alt="Screenshot 2025-10-01 123520"
    src="https://github.com/user-attachments/assets/48920ae6-d89c-41b8-b4ea-df5c18fb5fad"
    />
    
    after: 
    <img width="585" height="46" alt="Screenshot 2025-10-01 123612"
    src="https://github.com/user-attachments/assets/70a1761a-9d97-4836-b14c-670b6f13e608"
    />
  • fix: remove mcp-types from app server protocol (#4537)
    We continue the separation between `codex app-server` and `codex
    mcp-server`.
    
    In particular, we introduce a new crate, `codex-app-server-protocol`,
    and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it
    `codex-rs/app-server-protocol/src/protocol.rs`.
    
    Because `ConversationId` was defined in `mcp_protocol.rs`, we move it
    into its own file, `codex-rs/protocol/src/conversation_id.rs`, and
    because it is referenced in a ton of places, we have to touch a lot of
    files as part of this PR.
    
    We also decide to get away from proper JSON-RPC 2.0 semantics, so we
    also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which
    is basically the same `JSONRPCMessage` type defined in `mcp-types`
    except with all of the `"jsonrpc": "2.0"` removed.
    
    Getting rid of `"jsonrpc": "2.0"` makes our serialization logic
    considerably simpler, as we can lean heavier on serde to serialize
    directly into the wire format that we use now.
  • fix: use macros to ensure request/response symmetry (#4529)
    Manually curating `protocol-ts/src/lib.rs` was error-prone, as expected.
    I finally asked Codex to write some Rust macros so we can ensure that:
    
    - For every variant of `ClientRequest` and `ServerRequest`, there is an
    associated `params` and `response` type.
    - All response types are included automatically in the output of `codex
    generate-ts`.
  • Add cloud tasks (#3197)
    Adds a TUI for managing, applying, and creating cloud tasks
  • fix: separate codex mcp into codex mcp-server and codex app-server (#4471)
    This is a very large PR with some non-backwards-compatible changes.
    
    Historically, `codex mcp` (or `codex mcp serve`) started a JSON-RPC-ish
    server that had two overlapping responsibilities:
    
    - Running an MCP server, providing some basic tool calls.
    - Running the app server used to power experiences such as the VS Code
    extension.
    
    This PR aims to separate these into distinct concepts:
    
    - `codex mcp-server` for the MCP server
    - `codex app-server` for the "application server"
    
    Note `codex mcp` still exists because it already has its own subcommands
    for MCP management (`list`, `add`, etc.)
    
    The MCP logic continues to live in `codex-rs/mcp-server` whereas the
    refactored app server logic is in the new `codex-rs/app-server` folder.
    Note that most of the existing integration tests in
    `codex-rs/mcp-server/tests/suite` were actually for the app server, so
    all the tests have been moved with the exception of
    `codex-rs/mcp-server/tests/suite/mod.rs`.
    
    Because this is already a large diff, I tried not to change more than I
    had to, so `codex-rs/app-server/tests/common/mcp_process.rs` still uses
    the name `McpProcess` for now, but I will do some mechanical renamings
    to things like `AppServer` in subsequent PRs.
    
    While `mcp-server` and `app-server` share some overlapping functionality
    (like reading streams of JSONL and dispatching based on message types)
    and some differences (completely different message types), I ended up
    doing a bit of copypasta between the two crates, as both have somewhat
    similar `message_processor.rs` and `outgoing_message.rs` files for now,
    though I expect them to diverge more in the near future.
    
    One material change is that of the initialize handshake for `codex
    app-server`, as we no longer use the MCP types for that handshake.
    Instead, we update `codex-rs/protocol/src/mcp_protocol.rs` to add an
    `Initialize` variant to `ClientRequest`, which takes the `ClientInfo`
    object we need to update the `USER_AGENT_SUFFIX` in
    `codex-rs/app-server/src/message_processor.rs`.
    
    One other material change is in
    `codex-rs/app-server/src/codex_message_processor.rs` where I eliminated
    a use of the `send_event_as_notification()` method I am generally trying
    to deprecate (because it blindly maps an `EventMsg` into a
    `JSONNotification`) in favor of `send_server_notification()`, which
    takes a `ServerNotification`, as that is intended to be a custom enum of
    all notification types supported by the app server. So to make this
    update, I had to introduce a new variant of `ServerNotification`,
    `SessionConfigured`, which is a non-backwards compatible change with the
    old `codex mcp`, and clients will have to be updated after the next
    release that contains this PR. Note that
    `codex-rs/app-server/tests/suite/list_resume.rs` also had to be update
    to reflect this change.
    
    I introduced `codex-rs/utils/json-to-toml/src/lib.rs` as a small utility
    crate to avoid some of the copying between `mcp-server` and
    `app-server`.
  • OpenTelemetry events (#2103)
    ### Title
    
    ## otel
    
    Codex can emit [OpenTelemetry](https://opentelemetry.io/) **log events**
    that
    describe each run: outbound API requests, streamed responses, user
    input,
    tool-approval decisions, and the result of every tool invocation. Export
    is
    **disabled by default** so local runs remain self-contained. Opt in by
    adding an
    `[otel]` table and choosing an exporter.
    
    ```toml
    [otel]
    environment = "staging"   # defaults to "dev"
    exporter = "none"          # defaults to "none"; set to otlp-http or otlp-grpc to send events
    log_user_prompt = false    # defaults to false; redact prompt text unless explicitly enabled
    ```
    
    Codex tags every exported event with `service.name = "codex-cli"`, the
    CLI
    version, and an `env` attribute so downstream collectors can distinguish
    dev/staging/prod traffic. Only telemetry produced inside the
    `codex_otel`
    crate—the events listed below—is forwarded to the exporter.
    
    ### Event catalog
    
    Every event shares a common set of metadata fields: `event.timestamp`,
    `conversation.id`, `app.version`, `auth_mode` (when available),
    `user.account_id` (when available), `terminal.type`, `model`, and
    `slug`.
    
    With OTEL enabled Codex emits the following event types (in addition to
    the
    metadata above):
    
    - `codex.api_request`
      - `cf_ray` (optional)
      - `attempt`
      - `duration_ms`
      - `http.response.status_code` (optional)
      - `error.message` (failures)
    - `codex.sse_event`
      - `event.kind`
      - `duration_ms`
      - `error.message` (failures)
      - `input_token_count` (completion only)
      - `output_token_count` (completion only)
      - `cached_token_count` (completion only, optional)
      - `reasoning_token_count` (completion only, optional)
      - `tool_token_count` (completion only)
    - `codex.user_prompt`
      - `prompt_length`
      - `prompt` (redacted unless `log_user_prompt = true`)
    - `codex.tool_decision`
      - `tool_name`
      - `call_id`
    - `decision` (`approved`, `approved_for_session`, `denied`, or `abort`)
      - `source` (`config` or `user`)
    - `codex.tool_result`
      - `tool_name`
      - `call_id`
      - `arguments`
      - `duration_ms` (execution time for the tool)
      - `success` (`"true"` or `"false"`)
      - `output`
    
    ### Choosing an exporter
    
    Set `otel.exporter` to control where events go:
    
    - `none` – leaves instrumentation active but skips exporting. This is
    the
      default.
    - `otlp-http` – posts OTLP log records to an OTLP/HTTP collector.
    Specify the
      endpoint, protocol, and headers your collector expects:
    
      ```toml
      [otel]
      exporter = { otlp-http = {
        endpoint = "https://otel.example.com/v1/logs",
        protocol = "binary",
        headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
      }}
      ```
    
    - `otlp-grpc` – streams OTLP log records over gRPC. Provide the endpoint
    and any
      metadata headers:
    
      ```toml
      [otel]
      exporter = { otlp-grpc = {
        endpoint = "https://otel.example.com:4317",
        headers = { "x-otlp-meta" = "abc123" }
      }}
      ```
    
    If the exporter is `none` nothing is written anywhere; otherwise you
    must run or point to your
    own collector. All exporters run on a background batch worker that is
    flushed on
    shutdown.
    
    If you build Codex from source the OTEL crate is still behind an `otel`
    feature
    flag; the official prebuilt binaries ship with the feature enabled. When
    the
    feature is disabled the telemetry hooks become no-ops so the CLI
    continues to
    function without the extra dependencies.
    
    ---------
    
    Co-authored-by: Anton Panasenko <apanasenko@openai.com>
  • chore: remove responses-api-proxy from the multitool (#4404)
    This removes the `codex responses-api-proxy` subcommand in favor of
    running it as a standalone CLI.
    
    As part of this change, we:
    
    - remove the dependency on `tokio`/`async/await` as well as `codex_arg0`
    - introduce the use of `pre_main_hardening()` so `CODEX_SECURE_MODE=1`
    is not required
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/4404).
    * #4406
    * __->__ #4404
    * #4403
  • [MCP] Introduce an experimental official rust sdk based mcp client (#4252)
    The [official Rust
    SDK](https://github.com/modelcontextprotocol/rust-sdk/tree/57fc428c578a1a3fe851ee0838bf068bda120eb3)
    has come a long way since we first started our mcp client implementation
    5 months ago and, today, it is much more complete than our own
    stdio-only implementation.
    
    This PR introduces a new config flag `experimental_use_rmcp_client`
    which will use a new mcp client powered by the sdk instead of our own.
    
    To keep this PR simple, I've only implemented the same stdio MCP
    functionality that we had but will expand on it with future PRs.
    
    ---------
    
    Co-authored-by: pakrym-oai <pakrym@openai.com>
  • feat: introduce responses-api-proxy (#4246)
    Details are in `responses-api-proxy/README.md`, but the key contribution
    of this PR is a new subcommand, `codex responses-api-proxy`, which reads
    the auth token for use with the OpenAI Responses API from `stdin` at
    startup and then proxies `POST` requests to `/v1/responses` over to
    `https://api.openai.com/v1/responses`, injecting the auth token as part
    of the `Authorization` header.
    
    The expectation is that `codex responses-api-proxy` is launched by a
    privileged user who has access to the auth token so that it can be used
    by unprivileged users of the Codex CLI on the same host.
    
    If the client only has one user account with `sudo`, one option is to:
    
    - run `sudo codex responses-api-proxy --http-shutdown --server-info
    /tmp/server-info.json` to start the server
    - record the port written to `/tmp/server-info.json`
    - relinquish their `sudo` privileges (which is irreversible!) like so:
    
    ```
    sudo deluser $USER sudo || sudo gpasswd -d $USER sudo || true
    ```
    
    - use `codex` with the proxy (see `README.md`)
    - when done, make a `GET` request to the server using the `PORT` from
    `server-info.json` to shut it down:
    
    ```shell
    curl --fail --silent --show-error "http://127.0.0.1:$PORT/shutdown"
    ```
    
    To protect the auth token, we:
    
    - allocate a 1024 byte buffer on the stack and write `"Bearer "` into it
    to start
    - we then read from `stdin`, copying to the contents into the buffer
    after the prefix
    - after verifying the input looks good, we create a `String` from that
    buffer (so the data is now on the heap)
    - we zero out the stack-allocated buffer using
    https://crates.io/crates/zeroize so it is not optimized away by the
    compiler
    - we invoke `.leak()` on the `String` so we can treat its contents as a
    `&'static str`, as it will live for the rest of the processs
    - on UNIX, we `mlock(2)` the memory backing the `&'static str`
    - when using the `&'static str` when building an HTTP request, we use
    `HeaderValue::from_static()` to avoid copying the `&str`
    - we also invoke `.set_sensitive(true)` on the `HeaderValue`, which in
    theory indicates to other parts of the HTTP stack that the header should
    be treated with "special care" to avoid leakage:
    
    
    https://github.com/hyperium/http/blob/439d1c50d71e3be3204b6c4a1bf2255ed78e1f93/src/header/value.rs#L346-L376
  • ref: state - 2 (#4229)
    Extracting tasks in a module and start abstraction behind a Trait (more
    to come on this but each task will be tackled in a dedicated PR)
    The goal was to drop the ActiveTask and to have a (potentially) set of
    tasks during each turn
  • feat: add support for CODEX_SECURE_MODE=1 to restrict process observability (#4220)
    Because the `codex` process could contain sensitive information in
    memory, such as API keys, we add logic so that when
    `CODEX_SECURE_MODE=1` is specified, we avail ourselves of whatever the
    operating system provides to restrict observability/tampering, which
    includes:
    
    - disabling `ptrace(2)`, so it is not possible to attach to the process
    with a debugger, such as `gdb`
    - disabling core dumps
    
    Admittedly, a user with root privileges can defeat these safeguards.
    
    For now, we only add support for this in the `codex` multitool, but we
    may ultimately want to support this in some of the smaller CLIs that are
    buildable out of our Cargo workspace.
  • chore(deps): bump chrono from 0.4.41 to 0.4.42 in /codex-rs (#4028)
    Bumps [chrono](https://github.com/chronotope/chrono) from 0.4.41 to
    0.4.42.
    <details>
    <summary>Release notes</summary>
    <p><em>Sourced from <a
    href="https://github.com/chronotope/chrono/releases">chrono's
    releases</a>.</em></p>
    <blockquote>
    <h2>0.4.42</h2>
    <h2>What's Changed</h2>
    <ul>
    <li>Add fuzzer for DateTime::parse_from_str by <a
    href="https://github.com/tyler92"><code>@​tyler92</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1700">chronotope/chrono#1700</a></li>
    <li>Fix wrong amount of micro/milliseconds by <a
    href="https://github.com/nmlt"><code>@​nmlt</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1703">chronotope/chrono#1703</a></li>
    <li>Add warning about MappedLocalTime and wasm by <a
    href="https://github.com/lutzky"><code>@​lutzky</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1702">chronotope/chrono#1702</a></li>
    <li>Fix incorrect parsing of fixed-length second fractions by <a
    href="https://github.com/chris-leach"><code>@​chris-leach</code></a> in
    <a
    href="https://redirect.github.com/chronotope/chrono/pull/1705">chronotope/chrono#1705</a></li>
    <li>Fix cfgs for <code>wasm32-linux</code> support by <a
    href="https://github.com/arjunr2"><code>@​arjunr2</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1707">chronotope/chrono#1707</a></li>
    <li>Fix OpenHarmony's <code>tzdata</code> parsing by <a
    href="https://github.com/ldm0"><code>@​ldm0</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1679">chronotope/chrono#1679</a></li>
    <li>Convert NaiveDate to/from days since unix epoch by <a
    href="https://github.com/findepi"><code>@​findepi</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1715">chronotope/chrono#1715</a></li>
    <li>Add <code>?Sized</code> bound to related methods of
    <code>DelayedFormat::write_to</code> by <a
    href="https://github.com/Huliiiiii"><code>@​Huliiiiii</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1721">chronotope/chrono#1721</a></li>
    <li>Add <code>from_timestamp_secs</code> method to <code>DateTime</code>
    by <a href="https://github.com/jasonaowen"><code>@​jasonaowen</code></a>
    in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1719">chronotope/chrono#1719</a></li>
    <li>Migrate to core::error::Error by <a
    href="https://github.com/benbrittain"><code>@​benbrittain</code></a> in
    <a
    href="https://redirect.github.com/chronotope/chrono/pull/1704">chronotope/chrono#1704</a></li>
    <li>Upgrade to windows-bindgen 0.63 by <a
    href="https://github.com/djc"><code>@​djc</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1730">chronotope/chrono#1730</a></li>
    <li>strftime: simplify error handling by <a
    href="https://github.com/djc"><code>@​djc</code></a> in <a
    href="https://redirect.github.com/chronotope/chrono/pull/1731">chronotope/chrono#1731</a></li>
    </ul>
    </blockquote>
    </details>
    <details>
    <summary>Commits</summary>
    <ul>
    <li><a
    href="https://github.com/chronotope/chrono/commit/f3fd15f976c8c8e56d97eda6237af4d485ba2297"><code>f3fd15f</code></a>
    Bump version to 0.4.42</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/5cf56035007f291b1b8f457fa3bfc79fb367419a"><code>5cf5603</code></a>
    strftime: add regression test case</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/a6231701ee934cbbeb595fe71328fcbbf1b584d5"><code>a623170</code></a>
    strftime: simplify error handling</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/36fbfb1221da05b1482eb9dd18254e6bd736cb31"><code>36fbfb1</code></a>
    strftime: move specifier handling out of match to reduce rightward
    drift</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/7f413c363b74e293d495dc6109335c02dda9d629"><code>7f413c3</code></a>
    strftime: yield None early</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/9d5dfe164098186bfff8af7d5eecbb05d7712d4d"><code>9d5dfe1</code></a>
    strftime: outline constants</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/e5f6be7db4a0c2756cad0a7c8186a5a180873f7a"><code>e5f6be7</code></a>
    strftime: move error() method below caller</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/d516c2764d74e467fa37e25e8e88d5633478bafa"><code>d516c27</code></a>
    strftime: merge impl blocks</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/0ee2172fb92df4e0be4cf7a733c860226eec37a0"><code>0ee2172</code></a>
    strftime: re-order items to keep impls together</li>
    <li><a
    href="https://github.com/chronotope/chrono/commit/757a8b0226e9c0a23b5334c7dc0986f1e487b8ac"><code>757a8b0</code></a>
    Upgrade to windows-bindgen 0.63</li>
    <li>Additional commits viewable in <a
    href="https://github.com/chronotope/chrono/compare/v0.4.41...v0.4.42">compare
    view</a></li>
    </ul>
    </details>
    <br />
    
    
    [![Dependabot compatibility
    score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=chrono&package-manager=cargo&previous-version=0.4.41&new-version=0.4.42)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
    
    Dependabot will resolve any conflicts with this PR as long as you don't
    alter it yourself. You can also trigger a rebase manually by commenting
    `@dependabot rebase`.
    
    [//]: # (dependabot-automerge-start)
    [//]: # (dependabot-automerge-end)
    
    ---
    
    <details>
    <summary>Dependabot commands and options</summary>
    <br />
    
    You can trigger Dependabot actions by commenting on this PR:
    - `@dependabot rebase` will rebase this PR
    - `@dependabot recreate` will recreate this PR, overwriting any edits
    that have been made to it
    - `@dependabot merge` will merge this PR after your CI passes on it
    - `@dependabot squash and merge` will squash and merge this PR after
    your CI passes on it
    - `@dependabot cancel merge` will cancel a previously requested merge
    and block automerging
    - `@dependabot reopen` will reopen this PR if it is closed
    - `@dependabot close` will close this PR and stop Dependabot recreating
    it. You can achieve the same result by closing it manually
    - `@dependabot show <dependency name> ignore conditions` will show all
    of the ignore conditions of the specified dependency
    - `@dependabot ignore this major version` will close this PR and stop
    Dependabot creating any more for this major version (unless you reopen
    the PR or upgrade to it yourself)
    - `@dependabot ignore this minor version` will close this PR and stop
    Dependabot creating any more for this minor version (unless you reopen
    the PR or upgrade to it yourself)
    - `@dependabot ignore this dependency` will close this PR and stop
    Dependabot creating any more for this dependency (unless you reopen the
    PR or upgrade to it yourself)
    
    
    </details>
    
    Signed-off-by: dependabot[bot] <support@github.com>
    Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  • chore(deps): bump unicode-width from 0.1.14 to 0.2.1 in /codex-rs (#2156)
    Bumps [unicode-width](https://github.com/unicode-rs/unicode-width) from
    0.1.14 to 0.2.1.
    <details>
    <summary>Commits</summary>
    <ul>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/0085e91db72ae9a4498e62030d9651f1c1d09b4f"><code>0085e91</code></a>
    Publish 0.2.1</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/6db0c14cbde54b1343335be38c7fdcb6451efb25"><code>6db0c14</code></a>
    Remove <code>compiler-builtins</code> from <code>rustc-dep-of-std</code>
    dependencies (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/77">#77</a>)</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/0bccd3f1b55b15e7796a5f591a9f24ef28889b1b"><code>0bccd3f</code></a>
    update copyright year (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/76">#76</a>)</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/7a7fcdc8134a67e0b8deaac7deb4f12559550eaf"><code>7a7fcdc</code></a>
    Support Unicode 16 (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/74">#74</a>)</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/82d7136b494ded1fe83a269e673fd85dfc4a92a6"><code>82d7136</code></a>
    Advertise and enforce MSRV (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/73">#73</a>)</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/e77b2929bc863841147786ef573b297581f94fe4"><code>e77b292</code></a>
    Make characters with <code>Line_Break=Ambiguous</code> ambiguous (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/61">#61</a>)</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/5a7fced663028d86d603cffbddcabedfdf7c7199"><code>5a7fced</code></a>
    Update version number in Readme (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/70">#70</a>)</li>
    <li><a
    href="https://github.com/unicode-rs/unicode-width/commit/79eab0d9fc2060783b43046f9611648dcd35172f"><code>79eab0d</code></a>
    Publish 0.2.0 with newlines treated as width 1 (<a
    href="https://redirect.github.com/unicode-rs/unicode-width/issues/68">#68</a>)</li>
    <li>See full diff in <a
    href="https://github.com/unicode-rs/unicode-width/compare/v0.1.14...v0.2.1">compare
    view</a></li>
    </ul>
    </details>
    <br />
    
    
    [![Dependabot compatibility
    score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=unicode-width&package-manager=cargo&previous-version=0.1.14&new-version=0.2.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
    
    You can trigger a rebase of this PR by commenting `@dependabot rebase`.
    
    [//]: # (dependabot-automerge-start)
    [//]: # (dependabot-automerge-end)
    
    ---
    
    <details>
    <summary>Dependabot commands and options</summary>
    <br />
    
    You can trigger Dependabot actions by commenting on this PR:
    - `@dependabot rebase` will rebase this PR
    - `@dependabot recreate` will recreate this PR, overwriting any edits
    that have been made to it
    - `@dependabot merge` will merge this PR after your CI passes on it
    - `@dependabot squash and merge` will squash and merge this PR after
    your CI passes on it
    - `@dependabot cancel merge` will cancel a previously requested merge
    and block automerging
    - `@dependabot reopen` will reopen this PR if it is closed
    - `@dependabot close` will close this PR and stop Dependabot recreating
    it. You can achieve the same result by closing it manually
    - `@dependabot show <dependency name> ignore conditions` will show all
    of the ignore conditions of the specified dependency
    - `@dependabot ignore this major version` will close this PR and stop
    Dependabot creating any more for this major version (unless you reopen
    the PR or upgrade to it yourself)
    - `@dependabot ignore this minor version` will close this PR and stop
    Dependabot creating any more for this minor version (unless you reopen
    the PR or upgrade to it yourself)
    - `@dependabot ignore this dependency` will close this PR and stop
    Dependabot creating any more for this dependency (unless you reopen the
    PR or upgrade to it yourself)
    
    
    </details>
    
    > **Note**
    > Automatic rebases have been disabled on this pull request as it has
    been open for over 30 days.
    
    Signed-off-by: dependabot[bot] <support@github.com>
    Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  • chore: remove once_cell dependency from multiple crates (#4154)
    This commit removes the `once_cell` dependency from `Cargo.toml` files
    in the `codex-rs` and `apply-patch` directories, replacing its usage
    with `std::sync::LazyLock` and `std::sync::OnceLock` where applicable.
    This change simplifies the dependency tree and utilizes standard library
    features for lazy initialization.
    
    # External (non-OpenAI) Pull Request Requirements
    
    Before opening this Pull Request, please read the dedicated
    "Contributing" markdown file or your PR may be closed:
    https://github.com/openai/codex/blob/main/docs/contributing.md
    
    If your PR conforms to our contribution guidelines, replace this text
    with a detailed and high quality description of your changes.
  • chore: extract readiness in a dedicated utils crate (#4140)
    Create an `utils` directory for the small utils crates
  • chore(deps): bump tempfile from 3.20.0 to 3.22.0 in /codex-rs (#4030)
    Bumps [tempfile](https://github.com/Stebalien/tempfile) from 3.20.0 to
    3.22.0.
    <details>
    <summary>Changelog</summary>
    <p><em>Sourced from <a
    href="https://github.com/Stebalien/tempfile/blob/master/CHANGELOG.md">tempfile's
    changelog</a>.</em></p>
    <blockquote>
    <h2>3.22.0</h2>
    <ul>
    <li>Updated <code>windows-sys</code> requirement to allow version
    0.61.x</li>
    <li>Remove <code>unstable-windows-keep-open-tempfile</code>
    feature.</li>
    </ul>
    <h2>3.21.0</h2>
    <ul>
    <li>Updated <code>windows-sys</code> requirement to allow version
    0.60.x</li>
    </ul>
    </blockquote>
    </details>
    <details>
    <summary>Commits</summary>
    <ul>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/f720dbe098f847f3899d83305f565a5c46bb818d"><code>f720dbe</code></a>
    chore: release 3.22.0</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/55d742cb5d37d51c5ee107ae6c3898deeb0cc592"><code>55d742c</code></a>
    chore: remove deprecated unstable feature flag</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/bc41a0b586ec52da28971763378162e96d96be8a"><code>bc41a0b</code></a>
    build(deps): update windows-sys requirement from &gt;=0.52, &lt;0.61 to
    &gt;=0.52, &lt;0....</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/3c55387edee0d79041092f5abfbe899de4fbc8db"><code>3c55387</code></a>
    test: make sure we don't drop tempdirs early (<a
    href="https://redirect.github.com/Stebalien/tempfile/issues/373">#373</a>)</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/17bf644406959b75bf83d44fcfbd1dfa63d86730"><code>17bf644</code></a>
    doc(builder): clarify permissions (<a
    href="https://redirect.github.com/Stebalien/tempfile/issues/372">#372</a>)</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/c7423f1761f569c60c504ffed0ef6e124430b162"><code>c7423f1</code></a>
    doc(env): document the alternative to setting the tempdir (<a
    href="https://redirect.github.com/Stebalien/tempfile/issues/371">#371</a>)</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/5af60ca9e3ca42c5135cd41df3e8a2bd5341b9fc"><code>5af60ca</code></a>
    test(wasi): run a few tests that shouldn't have been disabled (<a
    href="https://redirect.github.com/Stebalien/tempfile/issues/370">#370</a>)</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/6c0c56198a274de88b877303fa28e6ad96699fa5"><code>6c0c561</code></a>
    fix(doc): temp_dir doesn't check if writable</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/48bff5f54c71a880ea7a9efb19e48be7b2eeb3d9"><code>48bff5f</code></a>
    test(tempdir): configure tempdir on wasi</li>
    <li><a
    href="https://github.com/Stebalien/tempfile/commit/704a1d27520735e8922c58e84cd193365ceaedaf"><code>704a1d2</code></a>
    test(tempdir): cleanup tempdir tests and run more tests on wasi</li>
    <li>Additional commits viewable in <a
    href="https://github.com/Stebalien/tempfile/compare/v3.20.0...v3.22.0">compare
    view</a></li>
    </ul>
    </details>
    <br />
    
    
    [![Dependabot compatibility
    score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=tempfile&package-manager=cargo&previous-version=3.20.0&new-version=3.22.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
    
    Dependabot will resolve any conflicts with this PR as long as you don't
    alter it yourself. You can also trigger a rebase manually by commenting
    `@dependabot rebase`.
    
    [//]: # (dependabot-automerge-start)
    [//]: # (dependabot-automerge-end)
    
    ---
    
    <details>
    <summary>Dependabot commands and options</summary>
    <br />
    
    You can trigger Dependabot actions by commenting on this PR:
    - `@dependabot rebase` will rebase this PR
    - `@dependabot recreate` will recreate this PR, overwriting any edits
    that have been made to it
    - `@dependabot merge` will merge this PR after your CI passes on it
    - `@dependabot squash and merge` will squash and merge this PR after
    your CI passes on it
    - `@dependabot cancel merge` will cancel a previously requested merge
    and block automerging
    - `@dependabot reopen` will reopen this PR if it is closed
    - `@dependabot close` will close this PR and stop Dependabot recreating
    it. You can achieve the same result by closing it manually
    - `@dependabot show <dependency name> ignore conditions` will show all
    of the ignore conditions of the specified dependency
    - `@dependabot ignore this major version` will close this PR and stop
    Dependabot creating any more for this major version (unless you reopen
    the PR or upgrade to it yourself)
    - `@dependabot ignore this minor version` will close this PR and stop
    Dependabot creating any more for this minor version (unless you reopen
    the PR or upgrade to it yourself)
    - `@dependabot ignore this dependency` will close this PR and stop
    Dependabot creating any more for this dependency (unless you reopen the
    PR or upgrade to it yourself)
    
    
    </details>
    
    Signed-off-by: dependabot[bot] <support@github.com>
    Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  • feat: readiness tool (#4090)
    Readiness flag with token-based subscription and async wait function
    that waits for all the subscribers to be ready
  • feat: git tooling for undo (#3914)
    ## Summary
    Introduces a “ghost commit” workflow that snapshots the tree without
    touching refs.
    1. git commit-tree writes an unreferenced commit object from the current
    index, optionally pointing to the current HEAD as its parent.
    2. We then stash that commit id and use git restore --source <ghost> to
    roll the worktree (and index) back to the recorded snapshot later on.
    
    ## Details
    - Ghost commits live only as loose objects—we never update branches or
    tags—so the repo history stays untouched while still giving us a full
    tree snapshot.
    - Force-included paths let us stage otherwise ignored files before
    capturing the tree.
    - Restoration rehydrates both tracked and force-included files while
    leaving untracked/ignored files alone.
  • chore: clippy on redundant closure (#4058)
    Add redundant closure clippy rules and let Codex fix it by minimising
    FQP
  • chore: more clippy rules 2 (#4057)
    The only file to watch is the cargo.toml
    All the others come from just fix + a few manual small fix
    
    The set of rules have been taken from the list of clippy rules
    arbitrarily while trying to optimise the learning and style of the code
    while limiting the loss of productivity
  • chore: unify cargo versions (#4044)
    Unify cargo versions at root
  • chore: enable clippy::redundant_clone (#3489)
    Created this PR by:
    
    - adding `redundant_clone` to `[workspace.lints.clippy]` in
    `cargo-rs/Cargol.toml`
    - running `cargo clippy --tests --fix`
    - running `just fmt`
    
    Though I had to clean up one instance of the following that resulted:
    
    ```rust
    let codex = codex;
    ```
  • chore: require uninlined_format_args from clippy (#2845)
    - added `uninlined_format_args` to `[workspace.lints.clippy]` in the
    `Cargo.toml` for the workspace
    - ran `cargo clippy --tests --fix`
    - ran `just fmt`
  • Introduce --oss flag to use gpt-oss models (#1848)
    This adds support for easily running Codex backed by a local Ollama
    instance running our new open source models. See
    https://github.com/openai/gpt-oss for details.
    
    If you pass in `--oss` you'll be prompted to install/launch ollama, and
    it will automatically download the 20b model and attempt to use it.
    
    We'll likely want to expand this with some options later to make the
    experience smoother for users who can't run the 20b or want to run the
    120b.
    
    Co-authored-by: Michael Bolin <mbolin@openai.com>
  • Auto format toml (#1745)
    Add recommended extension and configure it to auto format prompt.
  • fix: correctly wrap history items (#1685)
    The overall idea here is: skip ratatui for writing into scrollback,
    because its primitives are wrong. We want to render full lines of text,
    that will be wrapped natively by the terminal, and which we never plan
    to update using ratatui (so the `Buffer` struct is overhead and in fact
    an inhibition).
    
    Instead, we use ANSI scrolling regions (link reference doc to come).
    Essentially, we:
    1. Define a scrolling region that extends from the top of the prompt
    area all the way to the top of scrollback
    2. Scroll that region up by N < (screen_height - viewport_height) lines,
    in this PR N=1
    3. Put our cursor at the top of the newly empty region
    4. Print out our new text like normal
    
    The terminal interactions here (write_spans and its dependencies) are
    mostly extracted from ratatui.
  • feat: standalone file search CLI (#1386)
    Standalone fuzzy filename search library that should be helpful in
    addressing https://github.com/openai/codex/issues/1261.
  • feat: add support for login with ChatGPT (#1212)
    This does not implement the full Login with ChatGPT experience, but it
    should unblock people.
    
    **What works**
    
    * The `codex` multitool now has a `login` subcommand, so you can run
    `codex login`, which should write `CODEX_HOME/auth.json` if you complete
    the flow successfully. The TUI will now read the `OPENAI_API_KEY` from
    `auth.json`.
    * The TUI should refresh the token if it has expired and the necessary
    information is in `auth.json`.
    * There is a `LoginScreen` in the TUI that tells you to run `codex
    login` if both (1) your model provider expects to use `OPENAI_API_KEY`
    as its env var, and (2) `OPENAI_API_KEY` is not set.
    
    **What does not work**
    
    * The `LoginScreen` does not support the login flow from within the TUI.
    Instead, it tells you to quit, run `codex login`, and then run `codex`
    again.
    * `codex exec` does read from `auth.json` yet, nor does it direct the
    user to go through the login flow if `OPENAI_API_KEY` is not be found.
    * The `maybeRedeemCredits()` function from `get-api-key.tsx` has not
    been ported from TypeScript to `login_with_chatgpt.py` yet:
    
    
    https://github.com/openai/codex/blob/a67a67f3258fc21e147b6786a143fe3e15e6d5ba/codex-cli/src/utils/get-api-key.tsx#L84-L89
    
    **Implementation**
    
    Currently, the OAuth flow requires running a local webserver on
    `127.0.0.1:1455`. It seemed wasteful to incur the additional binary cost
    of a webserver dependency in the Rust CLI just to support login, so
    instead we implement this logic in Python, as Python has a `http.server`
    module as part of its standard library. Specifically, we bundle the
    contents of a single Python file as a string in the Rust CLI and then
    use it to spawn a subprocess as `python3 -c
    {{SOURCE_FOR_PYTHON_SERVER}}`.
    
    As such, the most significant files in this PR are:
    
    ```
    codex-rs/login/src/login_with_chatgpt.py
    codex-rs/login/src/lib.rs
    ```
    
    Now that the CLI may load `OPENAI_API_KEY` from the environment _or_
    `CODEX_HOME/auth.json`, we need a new abstraction for reading/writing
    this variable, so we introduce:
    
    ```
    codex-rs/core/src/openai_api_key.rs
    ```
    
    Note that `std::env::set_var()` is [rightfully] `unsafe` in Rust 2024,
    so we use a LazyLock<RwLock<Option<String>>> to store `OPENAI_API_KEY`
    so it is read in a thread-safe manner.
    
    Ultimately, it should be possible to go through the entire login flow
    from the TUI. This PR introduces a placeholder `LoginScreen` UI for that
    right now, though the new `codex login` subcommand introduced in this PR
    should be a viable workaround until the UI is ready.
    
    **Testing**
    
    Because the login flow is currently implemented in a standalone Python
    file, you can test it without building any Rust code as follows:
    
    ```
    rm -rf /tmp/codex_home && mkdir /tmp/codex_home
    CODEX_HOME=/tmp/codex_home python3 codex-rs/login/src/login_with_chatgpt.py
    ```
    
    For reference:
    
    * the original TypeScript implementation was introduced in
    https://github.com/openai/codex/pull/963
    * support for redeeming credits was later added in
    https://github.com/openai/codex/pull/974
  • fix: overhaul how we spawn commands under seccomp/landlock on Linux (#1086)
    Historically, we spawned the Seatbelt and Landlock sandboxes in
    substantially different ways:
    
    For **Seatbelt**, we would run `/usr/bin/sandbox-exec` with our policy
    specified as an arg followed by the original command:
    
    
    https://github.com/openai/codex/blob/d1de7bb383552e8fadd94be79d65d188e00fd562/codex-rs/core/src/exec.rs#L147-L219
    
    For **Landlock/Seccomp**, we would do
    `tokio::runtime::Builder::new_current_thread()`, _invoke
    Landlock/Seccomp APIs to modify the permissions of that new thread_, and
    then spawn the command:
    
    
    https://github.com/openai/codex/blob/d1de7bb383552e8fadd94be79d65d188e00fd562/codex-rs/core/src/exec_linux.rs#L28-L49
    
    While it is neat that Landlock/Seccomp supports applying a policy to
    only one thread without having to apply it to the entire process, it
    requires us to maintain two different codepaths and is a bit harder to
    reason about. The tipping point was
    https://github.com/openai/codex/pull/1061, in which we had to start
    building up the `env` in an unexpected way for the existing
    Landlock/Seccomp approach to continue to work.
    
    This PR overhauls things so that we do similar things for Mac and Linux.
    It turned out that we were already building our own "helper binary"
    comparable to Mac's `sandbox-exec` as part of the `cli` crate:
    
    
    https://github.com/openai/codex/blob/d1de7bb383552e8fadd94be79d65d188e00fd562/codex-rs/cli/Cargo.toml#L10-L12
    
    We originally created this to build a small binary to include with the
    Node.js version of the Codex CLI to provide support for Linux
    sandboxing.
    
    Though the sticky bit is that, at this point, we still want to deploy
    the Rust version of Codex as a single, standalone binary rather than a
    CLI and a supporting sandboxing binary. To satisfy this goal, we use
    "the arg0 trick," in which we:
    
    * use `std::env::current_exe()` to get the path to the CLI that is
    currently running
    * use the CLI as the `program` for the `Command`
    * set `"codex-linux-sandbox"` as arg0 for the `Command`
    
    A CLI that supports sandboxing should check arg0 at the start of the
    program. If it is `"codex-linux-sandbox"`, it must invoke
    `codex_linux_sandbox::run_main()`, which runs the CLI as if it were
    `codex-linux-sandbox`. When acting as `codex-linux-sandbox`, we make the
    appropriate Landlock/Seccomp API calls and then use `execvp(3)` to spawn
    the original command, so do _replace_ the process rather than spawn a
    subprocess. Incidentally, we do this before starting the Tokio runtime,
    so the process should only have one thread when `execvp(3)` is called.
    
    Because the `core` crate that needs to spawn the Linux sandboxing is not
    a CLI in its own right, this means that every CLI that includes `core`
    and relies on this behavior has to (1) implement it and (2) provide the
    path to the sandboxing executable. While the path is almost always
    `std::env::current_exe()`, we needed to make this configurable for
    integration tests, so `Config` now has a `codex_linux_sandbox_exe:
    Option<PathBuf>` property to facilitate threading this through,
    introduced in https://github.com/openai/codex/pull/1089.
    
    This common pattern is now captured in
    `codex_linux_sandbox::run_with_sandbox()` and all of the `main.rs`
    functions that should use it have been updated as part of this PR.
    
    The `codex-linux-sandbox` crate added to the Cargo workspace as part of
    this PR now has the bulk of the Landlock/Seccomp logic, which makes
    `core` a bit simpler. Indeed, `core/src/exec_linux.rs` and
    `core/src/landlock.rs` were removed/ported as part of this PR. I also
    moved the unit tests for this code into an integration test,
    `linux-sandbox/tests/landlock.rs`, in which I use
    `env!("CARGO_BIN_EXE_codex-linux-sandbox")` as the value for
    `codex_linux_sandbox_exe` since `std::env::current_exe()` is not
    appropriate in that case.
  • Disallow expect via lints (#865)
    Adds `expect()` as a denied lint. Same deal applies with `unwrap()`
    where we now need to put `#[expect(...` on ones that we legit want. Took
    care to enable `expect()` in test contexts.
    
    # Tests
    
    ```
    cargo fmt
    cargo clippy --all-features --all-targets --no-deps -- -D warnings
    cargo test
    ```
  • Workspace lints and disallow unwrap (#855)
    Sets submodules to use workspace lints. Added denying unwrap as a
    workspace level lint, which found a couple of cases where we could have
    propagated errors. Also manually labeled ones that were fine by my eye.
  • Update cargo to 2024 edition (#842)
    Some effects of this change:
    - New formatting changes across many files. No functionality changes
    should occur from that.
    - Calls to `set_env` are considered unsafe, since this only happens in
    tests we wrap them in `unsafe` blocks
  • chore: introduce codex-common crate (#843)
    I started this PR because I wanted to share the `format_duration()`
    utility function in `codex-rs/exec/src/event_processor.rs` with the TUI.
    The question was: where to put it?
    
    `core` should have as few dependencies as possible, so moving it there
    would introduce a dependency on `chrono`, which seemed undesirable.
    `core` already had this `cli` feature to deal with a similar situation
    around sharing common utility functions, so I decided to:
    
    * make `core` feature-free
    * introduce `common`
    * `common` can have as many "special interest" features as it needs,
    each of which can declare their own deps
    * the first two features of common are `cli` and `elapsed`
    
    In practice, this meant updating a number of `Cargo.toml` files,
    replacing this line:
    
    ```toml
    codex-core = { path = "../core", features = ["cli"] }
    ```
    
    with these:
    
    ```toml
    codex-core = { path = "../core" }
    codex-common = { path = "../common", features = ["cli"] }
    ```
    
    Moving `format_duration()` into its own file gave it some "breathing
    room" to add a unit test, so I had Codex generate some tests and new
    support for durations over 1 minute.
  • feat: initial McpClient for Rust (#822)
    This PR introduces an initial `McpClient` that we will use to give Codex
    itself programmatic access to foreign MCPs. This does not wire it up in
    Codex itself yet, but the new `mcp-client` crate includes a `main.rs`
    for basic testing for now.
    
    Manually tested by sending a `tools/list` request to Codex's own MCP
    server:
    
    ```
    codex-rs$ cargo build
    codex-rs$ cargo run --bin codex-mcp-client ./target/debug/codex-mcp-server
    {
      "tools": [
        {
          "description": "Run a Codex session. Accepts configuration parameters matching the Codex Config struct.",
          "inputSchema": {
            "properties": {
              "approval-policy": {
                "description": "Execution approval policy expressed as the kebab-case variant name (`unless-allow-listed`, `auto-edit`, `on-failure`, `never`).",
                "enum": [
                  "auto-edit",
                  "unless-allow-listed",
                  "on-failure",
                  "never"
                ],
                "type": "string"
              },
              "cwd": {
                "description": "Working directory for the session. If relative, it is resolved against the server process's current working directory.",
                "type": "string"
              },
              "disable-response-storage": {
                "description": "Disable server-side response storage.",
                "type": "boolean"
              },
              "model": {
                "description": "Optional override for the model name (e.g. \"o3\", \"o4-mini\")",
                "type": "string"
              },
              "prompt": {
                "description": "The *initial user prompt* to start the Codex conversation.",
                "type": "string"
              },
              "sandbox-permissions": {
                "description": "Sandbox permissions using the same string values accepted by the CLI (e.g. \"disk-write-cwd\", \"network-full-access\").",
                "items": {
                  "enum": [
                    "disk-full-read-access",
                    "disk-write-cwd",
                    "disk-write-platform-user-temp-folder",
                    "disk-write-platform-global-temp-folder",
                    "disk-full-write-access",
                    "network-full-access"
                  ],
                  "type": "string"
                },
                "type": "array"
              }
            },
            "required": [
              "prompt"
            ],
            "type": "object"
          },
          "name": "codex"
        }
      ]
    }
    ```
  • feat: introduce mcp-server crate (#792)
    This introduces the `mcp-server` crate, which contains a barebones MCP
    server that provides an `echo` tool that echoes the user's request back
    to them.
    
    To test it out, I launched
    [modelcontextprotocol/inspector](https://github.com/modelcontextprotocol/inspector)
    like so:
    
    ```
    mcp-server$ npx @modelcontextprotocol/inspector cargo run --
    ```
    
    and opened up `http://127.0.0.1:6274` in my browser:
    
    
    ![image](https://github.com/user-attachments/assets/83fc55d4-25c2-4497-80cd-e9702283ff93)
    
    I also had to make a small fix to `mcp-types`, adding
    `#[serde(untagged)]` to a number of `enum`s.
  • feat: introduce mcp-types crate (#787)
    This adds our own `mcp-types` crate to our Cargo workspace. We vendor in
    the
    [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json)
    from the MCP repo and introduce a `generate_mcp_types.py` script to
    codegen the `lib.rs` from the JSON schema.
    
    Test coverage is currently light, but I plan to refine things as we
    start making use of this crate.
    
    And yes, I am aware that
    https://github.com/modelcontextprotocol/rust-sdk exists, though the
    published https://crates.io/crates/rmcp appears to be a competing
    effort. While things are up in the air, it seems better for us to
    control our own version of this code.
    
    Incidentally, Codex did a lot of the work for this PR. I told it to
    never edit `lib.rs` directly and instead to update
    `generate_mcp_types.py` and then re-run it to update `lib.rs`. It
    followed these instructions and once things were working end-to-end, I
    iteratively asked for changes to the tests until the API looked
    reasonable (and the code worked). Codex was responsible for figuring out
    what to do to `generate_mcp_types.py` to achieve the requested test/API
    changes.
  • chore: script to create a Rust release (#759)
    For now, keep things simple such that we never update the `version` in
    the `Cargo.toml` for the workspace root on the `main` branch. Instead,
    create a new branch for a release, push one commit that updates the
    `version`, and then tag that branch to kick off a release.
    
    To test, I ran this script and created this release job:
    
    https://github.com/openai/codex/actions/runs/14762580641
  • chore: Rust release, set prerelease:false and version=0.0.2504301132 (#755)
    The generated DotSlash file has URLs that refer to
    `https://github.com/openai/codex/releases/`, so let's set
    `prerelease:false` (but keep `draft:true` for now) so those URLs should
    work.
    
    Also updated `version` in Cargo workspace so I will kick off a build
    once this lands.
  • chore: remove the REPL crate/subcommand (#754)
    @oai-ragona and I discussed it, and we feel the REPL crate has served
    its purpose, so we're going to delete the code and future archaeologists
    can find it in Git history.